The Standard That Says Your CMS Owes You Something

WCAG is one of three. The other two cover the software you publish through and the browser people read in, and if your content management system will not let an editor add alt text, you are looking at the first of those rather than at a failure of your own. It is called ATAG, it is a full W3C Recommendation, and it carries a numbered requirement saying an authoring tool has to let authors edit the text alternatives it stores.

Neither of the other two is yours to meet, and that is exactly why they are useful to you. WCAG puts the obligation on the content, so whoever publishes carries it. ATAG puts an obligation on the tool they publish through. UAAG puts one on the browser. When your platform makes accessible output difficult, you are not failing through carelessness. You are absorbing a problem that W3C's own model places somewhere else, and now you have the name and the number for it.

The two are not equally weighty, and the difference is the most interesting thing about them. ATAG 2.0 is a W3C Recommendation, the same document status as WCAG itself. UAAG 2.0 never got that far. It is a Working Group Note, and the reason it stopped is not the one most people guess.

Three Standards, One Chain

WCAG says so about itself, in its own opening pages. Web accessibility depends not only on accessible content but on accessible browsers and other user agents, and authoring tools have an important role too. So the standard your site is measured against opens by saying it is one component of several.

W3C sets out the full model separately, and the useful part is the failure case rather than the diagram. Where one component is weak, the others sometimes compensate, and the example given is developers coding markup by hand instead of going through their tool. Then the sentence worth remembering. In most cases the work-arounds are not implemented and the result is still poor accessibility.

That is your situation described by the people who wrote the standard. An owner working around a bad editor is the compensation case, W3C names it, and W3C says out loud that the compensation usually does not happen. Which is a more sympathetic reading of most inaccessible websites than the industry normally offers.

Alt text is the worked example W3C uses, and it takes eight parties to deliver one attribute. HTML defines it. The guidelines say how each component should handle it. A person writes the wording. The authoring tool enables and encourages providing it. An evaluation tool checks it exists. The browser exposes it. The assistive technology presents it. And the reader knows how to get at it. Break any link and the chain fails, and only one of those eight links is the site owner.

ATAG Covers the Tool You Publish Through

ATAG 2.0 became a W3C Recommendation in September 2015. It splits into two parts, and they answer two different questions.

Part A asks whether a disabled person can use the tool at all. Its four groups mirror the shape of WCAG. Follow the applicable accessibility guidelines, make the editing views perceivable, make them operable, make them understandable. This is the part that decides whether a blind editor can run your CMS, and it is the reason ATAG exists as its own document rather than as a WCAG appendix.

Part B asks whether the tool helps anybody produce accessible content, disabled or not. Its four groups are that fully automatic processes produce accessible content, that authors are supported in producing it, that authors are supported in repairing what already exists, and that the tool promotes and integrates its own accessibility features rather than burying them.

Sixty-three testable criteria sit under those, thirty-one in Part A and thirty-two in Part B, and ATAG borrows WCAG's three levels of A, AA and AAA so the two can be used together without translation. Part B is the half most owners care about, because it is the half describing what the tool owes the person typing into it.

The Criterion for an Editor That Cannot Add Alt Text

One criterion is worth knowing by heart, because it converts a vague complaint into a checkable requirement. It is called Alternative Content is Editable, and it says that if the tool lets you add non-text content, then authors are able to modify the programmatically associated text alternatives for it. Its level rises with the level of WCAG you are trying to reach, so it applies from Level A upward.

There is one exception, and it is narrow. The tool may skip it where the non-text content is known to be decoration, formatting, invisible, or a CAPTCHA. That is a short list and it does not cover the product photograph your editor cannot describe.

Two neighbors sit alongside it and both have aged remarkably well. Automating Repair of Text Alternatives says that a tool either does not attempt to repair text alternatives at all, or three things are true. Generic strings such as image and irrelevant strings such as the file name or the file format are not used as text alternatives. Repairs made during an editing session are offered to the author to accept, modify or reject before anything is inserted. And repairs made after a session ends are flagged in later sessions with the same right of refusal.

Read that against the automatic alt text features shipping in every platform right now. It was written in 2015, it is a Level A requirement in a W3C Recommendation, and it says a tool must not silently insert generated descriptions you never approved. If your platform fills in alt text and gives you no way to see or change it, there is a standard that already said no to that, ten years before the feature arrived.

The third of the group, Save for Reuse, sits at Level AAA and asks that alternatives you have already written be saved and suggested when the same image is used again, and remain editable. It is the difference between describing your logo once and describing it four hundred times.

What Counts as an Authoring Tool, and What Does Not

The definition is broad on purpose. An authoring tool is any application, web-based or not, that authors can use alone or together to create or modify web content for use by other people. The last clause is what does most of the filtering.

Eleven kinds of software are named as included, and the list covers almost everything a normal team touches. Visual HTML editors. Source code editors. Save-as-HTML features in office applications. Development environments. Anything generating content from templates, scripts, command lines or wizards. Blogging, wiki and forum software. Software for generating or managing entire websites, with content management systems named directly. Email clients that send in web technologies. Multimedia authoring tools. And tools for building mobile web applications.

Three exclusions are named, and each one teaches where the boundary runs. A customizable personal portal is out, because the content being edited is only ever seen by its owner. An e-commerce order form is out, because its purpose is ordering a product rather than communicating with other people, even though the data does end up as web content. And a stand-alone accessibility checker is out, because a checker with no repair function does not modify content. Add repair to that checker, or fold it into a larger authoring process, and it becomes an authoring tool.

So the test is roughly this. Does it make or change content that other people will read, and can a person drive it. If both are yes, ATAG describes what it owes.

UAAG Covers Browsers, and It Never Finished

UAAG 2.0 describes what a browser, media player or other user agent owes its users. Five principles, twenty-six guidelines and a hundred and eleven criteria, at the same three levels. The first two principles are Perceivable and Operable and will feel familiar. The last two are where it earns its place.

Programmatic access is what a browser owes an assistive technology, and it is the mechanism every ARIA attribute you write depends on. Specifications and conventions is the browser's obligation to actually implement the accessibility features of the content specifications, which is what makes correct markup mean anything by the time it reaches somebody. Without those two, an author writing perfect HTML is talking to a wall.

Now the status, and it is worth getting right. UAAG 2.0 is a W3C Working Group Note from December 2015, and it never entered the phase where implementations get formally tested. The document says why. There were not enough resources for the testing, and the working group closed.

It did not fail on merit, and the record is specific about that. It completed Last Call in 2013 and the group published two further drafts answering the comments. It drew wide review, with 246 issues raised by 37 organizations and individuals including browser makers, media player makers and other W3C groups. Every issue was resolved and there were no outstanding objections. A partial test suite exists and candidate implementations were identified for ninety percent of the features. What was missing was people to run the tests, not agreement about the content.

The earlier version, UAAG 1.0, is a W3C Recommendation from December 2002, and it is still load-bearing inside WCAG. WCAG 2.2's own definition of a viewport carries a note saying it is based on the UAAG 1.0 glossary. So the older document is quietly doing work inside the standard you are measured against.

Why the Difference in Status Matters

The status line at the top of a W3C document tells you what it is for, and the two here say different things.

The practical read is that ATAG is the one you can lean on. It is a Recommendation, so naming a criterion in a support ticket is naming a published requirement rather than an opinion. UAAG is the one to understand rather than to cite, because it explains why certain problems are not yours and it does not carry the weight to force anybody's hand.

One age note in fairness to both. ATAG is pinned to WCAG 2.0, since that was the current version when it was written, and UAAG dates from the same year. Neither has been revised for WCAG 2.1 or 2.2. The requirements still describe the right behaviors, and the version numbers inside them are old, which is worth knowing before you quote one at a vendor who will notice.

What to Do When Your Platform Is the Problem

This is where the page pays for itself, because a support ticket that names a standard gets a different answer from one that does not.

1. 1Work out which half you have hit. If a disabled colleague cannot operate the editor, that is Part A. If the editor works fine and produces markup you cannot fix, that is Part B. Vendors handle those two complaints through completely different teams.
2. 2Name the behavior, not the feeling. The image dialog has no alt text field is checkable. Your accessibility is poor is not, and it gets filed accordingly.
3. 3Say the standard out loud. ATAG 2.0 is a W3C Recommendation covering authoring tools, and the alt text case is its Alternative Content is Editable criterion. Most support staff have never heard of it, which is precisely why writing it down moves the ticket.
4. 4Ask whether they publish a conformance claim. ATAG allows partial conformance for a component that needs other tools to complete the picture, so a plugin or a page builder can legitimately claim it. A vendor with no answer at all is telling you something.
5. 5Record it either way. A dated note saying the tool cannot do the thing, and that you asked, is the difference between an unfixed problem and an unfixed problem with a paper trail behind it.

It is worth knowing what ATAG does not blame the tool for, because a fair ticket lands better. Where an accessibility problem in the editing view is caused directly by the content being edited, such as an image in your own content that has no text alternative, ATAG says that is not a deficiency in the tool. Part A also covers only the interface as the developer shipped it, so third-party plugins and your own settings changes are outside it.

Where Any of This Becomes an Obligation

Now the honest part. ATAG binds nobody by itself. No law we cover names it as a duty on a site owner, and it could not sensibly do so, because the duties in it belong to software vendors rather than to publishers.

It reaches procurement by a different route. EN 301 549, the European standard that carries accessibility requirements into public sector buying, includes a clause on authoring tools inside its software chapter. So a European public body buying a content management system has a clause in the standard to name, which is more than a private buyer gets. What that clause requires in detail is not something this page will summarize, because we have not read it to that depth, and we would rather say so than guess.

For everybody else the value is different and still real. ATAG gives you the vocabulary, the criterion and the standing to make the request. It moves the conversation from a complaint about a product to a question about a published requirement, and it tells you plainly that the thing you are struggling with was somebody else's job first.