EN 301 549 11.8 -- Authoring Tools
What It Is
EN 301 549 v3.2.1 clause 11.8 applies when the ICT under procurement is itself an authoring tool -- a CMS, page builder, rich-text editor embedded in a web app, email composer, design tool, document editor, video editor, or e-learning platform. The clause incorporates W3C Authoring Tool Accessibility Guidelines (ATAG) 2.0 by reference and splits the requirement in two: the authoring interface must be accessible to authors with disabilities (ATAG Part A), and the tool must support the production of accessible output and actively guide authors toward it (ATAG Part B)[1][2].
Why It Matters
Accessibility defects originate at authoring time, not at runtime. If the image-upload dialog in a CMS does not expose an alt-text field next to the file picker, the alt attribute ships empty. If the rich-text editor styles headings with font-size and bold rather than emitting <h2>/<h3> elements, the document outline collapses and screen-reader users lose the only structural landmarks on the page. If the design tool does not flag a 3.2:1 text-on-background ratio, the author will not notice the contrast failure before export. Clause 11.8 pushes the fix upstream: the tool builder owns the authoring UX, and an authoring UX that makes the accessible path the path of least resistance is the leverage point for everything the author ships afterwards[2].
How It Relates to WCAG
WCAG 2.2 governs the content a tool produces once it is deployed on the web. ATAG 2.0 governs the tool that produces that content. Part A of ATAG maps the authoring interface onto WCAG success criteria -- contrast, keyboard operation, accessible name, focus visibility -- so the editor itself is usable by a blind editor, a keyboard-only editor, or a low-vision editor. Part B has no WCAG equivalent: it covers authoring-specific behaviours like preserving accessibility information across save/export/publish, prompting the author when required metadata is missing, and shipping accessible templates[2]. Clause 11.8 is the procurement hook that makes both parts enforceable when a public body buys an authoring tool[1].
Practical Implications
- Image insertion dialogs require an alt-text field adjacent to the file picker, with a decorative-image opt-out that writes
alt=""rather than omitting the attribute. - Rich-text editors expose a heading-level picker that emits real
<h1>-<h6>elements, not font-size overrides. - Design tools and page builders surface a live contrast checker on text-on-background pairs and flag ratios below WCAG 2.2 thresholds at authoring time, not at audit time.
- Video editors prompt for captions and transcripts on publish and refuse to strip them on re-export.
- Templates, themes, and starter kits bundled with the tool ship with landmarks, skip links, a logical heading order, and language attributes already in place, so the default output is accessible before the author touches it.
- Accessibility information created by the author -- alt text, table headers, language attributes, ARIA -- survives round-tripping through save, export, import, and publish without silent loss.
- The authoring interface itself meets WCAG 2.2 Level AA: keyboard-operable toolbars, visible focus, sufficient contrast, accessible names on every control.