Before a website goes live it gets audited: contrast, keyboard operation, screen reader output, and a report with findings and priorities at the end. What gets audited is the result. The tool that recreates that result every single day is rarely part of the scope. Yet the editing interface decides, with every news item, every product description and every new landing page, whether the audited quality holds or quietly erodes. There is a separate set of guidelines for exactly this gap: the Authoring Tool Accessibility Guidelines, ATAG 2.0 for short, a W3C Recommendation since 24 September 2015 (W3C). They ask two questions of a content management system, and both belong on the table before EN 301 549 raises them in a public tender.
Key takeaways
- A WCAG audit assesses the page that ships. The content management system that refills it every day usually stays outside the scope.
- ATAG 2.0 consists of two parts with 8 principles in total (W3C): Part A covers the operability of the editing interface, Part B covers support for accessible output.
- Part A is a workplace matter. An employer filling an editorial role owes an accessible workstation including equipment under section 164 paragraph 4, as far as that is reasonable for the employer (SGB IX).
- Part B is a quality matter: alternative text as a required field instead of free text, guided heading levels, a contrast warning in the colour picker, a table assistant with header cells.
- EN 301 549 covers authoring tools in clause 11.8 with five requirements from 11.8.1 to 11.8.5 (EN 301 549), which carries the idea into the European standard.
- Some guardrails can be retrofitted through extensions, the rest sits in the core of the system. That is why the question belongs in the selection process rather than in later repair work.
Everyone audits the website, few audit the tool
The starting point is well documented: 95.9 percent of the home pages surveyed in 2026 carried automatically detectable WCAG failures (WebAIM Million), and 96 percent of all failures found fell into just six categories (WebAIM Million) - low contrast text, missing alternative text, empty links, unlabelled form fields, empty buttons and missing document language. What stands out about that list is where the failures originate. Most of them are not architectural mistakes but decisions made inside an input field: an image without a description, a link labelled read more, a heading that merely looks bold.
A single audit run therefore falls short. A website that was clean in spring can carry barriers again after a few weeks of editorial work, without anyone on the team intending to do anything wrong. What applies to scope when auditing customer portals behind the login applies here to the time axis: the audit report describes a state, the content management system produces a trajectory. Bringing the two together means looking at the tool itself - its interface and the guardrails it offers the editorial team.
Two questions missing from most selection processes
ATAG 2.0: two parts, two responsibilities
ATAG 2.0 is structured like WCAG: principles, guidelines, success criteria and three conformance levels from A to AAA (W3C). The difference lies in the subject matter. WCAG describes content, ATAG describes the tool that content is made with - from the content management system to the shop backend, the newsletter editor, the form builder and the intranet wiki. An authoring tool is any software whose output is later read by other people on the web. That is a broad definition, and in most organisations it covers more systems than expected at first.
The two parts stand side by side and solve different problems. Part A comprises four principles and applies the familiar requirements to the interface of the tool itself: perceivable authoring interfaces, operable authoring interfaces, understandable authoring interfaces, and a user interface that follows the applicable guidelines (W3C). Part B also comprises four principles and has no counterpart in WCAG: automatic processes should produce accessible content, authors should be supported while creating it, existing content should be repairable, and the functions for all of this should sit visibly in the workflow rather than in a submenu (W3C).
| Question | ATAG Part A | ATAG Part B |
|---|---|---|
| What it targets | the interface of the tool | the result of the work |
| Who benefits | editors with disabilities | every visitor to the website |
| Typical finding | toolbar without keyboard access | alternative text as an optional free text field |
| Audit method | manual operation with keyboard and screen reader | create a test article and read the markup produced |
| Legal anchor | workplace design under SGB IX | EN 301 549, clause 11.8, and tender documents |
| Retrofit potential | limited, often sits in the core of the system | partly possible through custom extensions |
This separation helps day to day because it names different responsibilities. Part A concerns human resources, procurement and employee representation: it decides who can work in the editorial team at all. Part B concerns development, editorial management and quality assurance: it decides what ends up on the website. A system can score well on one part and weakly on the other, and both cases occur frequently. It is therefore worth auditing and rating the parts separately.
Part A: the editing interface is a workplace
People who maintain content spend hours a day doing so. For people with disabilities the content management system is therefore not a website you can leave again, it is the tool of their profession. At the end of 2023 around 7.9 million people with severe disabilities lived in Germany (Statistisches Bundesamt), an older estimate for the year 2002 puts the number of blind and partially sighted people at roughly 1.2 million (DBSV), and worldwide an estimated 1.3 billion people live with a significant disability (WHO). Some of them work in communications, marketing and administration, which is exactly where content management systems are used. Section 164 paragraph 4 obliges employers to equip workplaces including machinery and devices in a way that suits the disability, as far as that is reasonable for them (SGB IX). A system that is hard to operate without a mouse stands in the way of that duty.
The findings look similar across systems because editing interfaces use similar building blocks. What stands out is that the body text editor is rarely the sticking point. The hurdles sit at the edges: in the media library, in tree structures for page hierarchies, in preview panes and in the small messages that report the state of the work. Six places show up in audits with particular regularity.
Toolbar
Formatting, blocks and special characters often sit on buttons without keyboard access or in menus that only open while the mouse button is held down. Audit step: operate the entire editor once using nothing but tab and enter.
Media library
Uploading by drag and drop is convenient, but it must not be the only route. Without an alternative button and a properly labelled file list, image handling stays closed to keyboard users.
Tree navigation
Page trees need appropriate roles as well as states for expanded, collapsed and selected. Without them a screen reader announces a list of links with no hierarchy and no indication of position.
Preview pane
The live preview often sits in an embedded frame without a title. An unnamed frame is a room without a name for a screen reader, and moving into it goes unexplained.
Autosave
Messages such as draft saved appear visually and disappear again. Without a polite live region the notice stays silent for screen reader users, and the state of the work remains unclear.
Error dialogues
When saving with incomplete required fields, focus often jumps to the top of the page or stays behind the dialogue. The dialogue belongs in focus, the error belongs at the field concerned, and the way back must stay reachable.
These six points sound specialised, yet they can be checked within a few hours. The route there runs through keyboard navigation in practice, through correctly applied ARIA roles, states and live regions and through accessible error and status messages. Teams who master these three topics in the front end recognise them again in the back end: the building blocks are the same, only the expectation differs, because this is a place for working rather than reading.
The interface decides who can fill the role
Part B: guardrails instead of good intentions
Part B starts from a sober assumption: an editorial team is not an audit body. It writes, trims, illustrates and publishes under time pressure. If the most convenient route through the tool leads to an accessible result, accessible content appears even when attention is elsewhere. If the most convenient route bypasses the requirement, even good training helps only so much, because it has to work against the interface. The numbers support that assumption: 83.9 percent of home pages contained text with insufficient contrast (WebAIM Million), and 16.2 percent of all images surveyed had no alternative text (WebAIM Million).
Alternative text illustrates the point well. An optional free text field without explanation produces three outcomes: empty fields, file names, and descriptions that miss the purpose of the image. A required field with a deliberate decision beside it - descriptive or decorative - produces a different practice. Choosing decorative yields an empty alt attribute in the markup rather than a makeshift phrase, and at that spot this is exactly right. What a workable alternative text looks like is covered in the article on accessible images and alt text; the tool only has to demand the decision and explain it.
- Alternative text as a required field, with a deliberate choice for decorative images beside it instead of a silently empty box
- Heading levels that cannot be skipped: after an H2 the tool offers H3 and flags jumps in the outline
- Style templates instead of visually bolded pseudo headings, so that structure comes from markup rather than font size
- A warning for link texts such as here or read more, combined with a suggestion to name the destination of the link
- A contrast warning in the colour picker that shows the ratio directly while text and background colours are chosen
- A table assistant that requires header cells and associates cells, instead of laying out a grid of empty boxes
- Templates and blocks that emit accessible markup only, from the accordion to the image gallery
- Language markup for passages in another language, so that the screen reader does not stay in the wrong pronunciation
The second to last line of that list is the most effective one. When the blocks inside the tool come from an audited accessible design system, a large part of the work is done before the editorial team starts. The same applies to the colour palette: if the picker only offers combinations that meet the requirements for colour contrast, an entire class of failure disappears from daily work. Complex building blocks such as data tables belong in an assistant too, because associating header cells by hand rarely succeeds.
From ATAG to EN 301 549 and the BFSG
ATAG 2.0 itself is a recommendation without direct legal force. The route into binding obligation runs through the European standard. EN 301 549 addresses web content in clause 9, documents in clause 10 and software in clause 11; within it, clause 11.8 forms a dedicated section for authoring tools with five requirements (EN 301 549): 11.8.1 on the technology used, 11.8.2 on creating accessible content, 11.8.3 on preserving accessibility information during transformations, 11.8.4 on repair assistance and 11.8.5 on templates. The idea behind ATAG Part B thus appears in the very standard that German law refers to.
In practice this creates two routes into obligation. The first runs through public procurement: anyone supplying software to public sector clients meets EN 301 549 again in the tender documents, and clause 11.8 applies along with it. The second runs through the German Accessibility Strengthening Act, in force since 28 June 2025, which transposes the European Accessibility Act into German law (EU-Richtlinie 2019/882). Anyone shipping a content management system to customers is also shipping the basis for their compliance. Which offerings are affected in detail is set out in the overview of the BFSG requirements; micro-enterprises with fewer than 10 employees and no more than 2 million euros in annual turnover are exempt for services (BFSG).
How closely tool and result are linked also shows in accessible e-learning platforms: course authors work with the authoring tool of the platform, and every course inherits its limits. The same inheritance applies to shop backends, newsletter editors and form builders. Auditing the tool therefore means auditing not one system but everything that will be produced with it.
Two roles, two duties
An audit grid for selection and retrofitting
A reliable picture emerges within a few hours. Create a test article containing everything your editorial team typically needs: headings across two levels, an image, a table, a link, a quotation and an embedded video. Operate the system once using only the keyboard and once with a screen reader. Then read the markup it produced. Ten steps are enough for a basis of decision that also holds up in a tender.
- Operate login, dashboard and editor using nothing but tab and enter
- Check whether keyboard focus stays visible and no trap appears that can only be left with the mouse
- Upload an image without dragging it into the drop area with the mouse
- Expand and collapse the page tree with a screen reader and listen for roles as well as states
- Trigger a required field error and observe where focus lands and whether the message is announced
- Skip a heading level in the test article and check whether the system flags it
- Save an image without alternative text and see whether the tool asks or silently agrees
- Create a link labelled read more and watch for a warning
- Set a weak combination in the colour picker and observe the contrast indicator
- Read the markup produced: heading levels, lists, table headers, language markup and empty alt attributes
The findings lead to the real question: what can be retrofitted, and what sits so deep in the system that switching would be the more honest answer? As a rule of thumb: everything that happens between input and saving can often be retrofitted through extensions, custom field configurations and custom blocks. Everything that concerns the basic structure of the interface belongs to the vendor and turns into a requirement for them.
| Work item | Through custom extensions | Located with the vendor |
|---|---|---|
| Alternative text as a required field | usually solvable via field configuration | rarely required |
| Style templates and blocks | implementable via custom templates | rarely required |
| Contrast warning in the colour picker | solvable via a restricted palette | only for free colour choice |
| Keyboard operation of the toolbar | hardly worth rebuilding | requirement or system change |
| Roles and states in the page tree | partly possible through adjustments | mostly with the vendor |
| Focus handling in dialogues | implementable in custom dialogues | with the vendor for standard dialogues |
This classification changes conversations with vendors. Instead of a general question about accessibility, a list of verifiable criteria lies on the table, and the answer turns into a date. In accessible web development we build the retrofittable items into the existing system as guardrails, rather than writing them into a policy that sits on a shared drive waiting to be read.
From one clean-up to continuous checking
A content management system with guardrails lowers the error rate, but it does not replace verification. New content, new templates and system updates keep shifting the state. Accessibility monitoring therefore does not check once but at fixed intervals, and it checks what has newly appeared first. This shifts effort away from large clean-up campaigns towards small, plannable corrections that fit into editorial routine.
The second building block is the division of roles. The editorial team needs answers to questions of content: when is an image decorative, how do you describe a chart, how do you phrase a link? That is what our training for editorial and development teams and the article on training the editorial team are for. Development needs something else: reliable blocks, audited templates and an interface that makes the correct route the convenient one. ATAG separates these two responsibilities cleanly, and that is precisely what makes the guideline useful in project work.
An editing interface that makes the correct route the most convenient one produces more accessibility than any policy on the intranet.
Getting started is manageable. An audit of the editing interface is a project of its own with a clear scope: login, editor, media library, page tree, dialogues and preview for Part A, plus a test article and the markup it produces for Part B. The result is a prioritised list stating what can be solved inside the project and what belongs with the vendor. How such an audit runs is set out in the overview of our services - and anyone who already holds an audit report for the website can bring the interface up to the same level with the same method.
Sources and Studies