Authoring Tool Accessibility Guidelines (ATAG) – your editor tools should also be accessible

Note: This post is older than two years. It may still be totally valid, but things change and technology moves fast. Code based posts may be especially prone to changes...

(Read 876 times)

Beside content accessibility guidelines we must also be aware of authoring tool accessibility guidelines that your editor tools, for example content management system, should adhere to

I thought that Content Management Systems (CMS) should adhere to Web Content Accessibility Guidelines (WCAG) too, but when researching the subject I discovered a special set of guidelines just for the authoring tools – so called Authoring Tool Accessibility Guidelines (ATAG – link opens in new window).

But first – what are authoring tools? Only content management systems or?

Authoring tools in this context are actually all software and services that authors use to produce any kind of web content (be it static, dynamic, PDF etc.). The Web Accessibility Initiative made ATAG available to the public so that developers of authoring tools have the guidelines to create and improve accessibility of editorial tools too.

This means actually that a CMS should also be accessible, not only the content that is made with it.

How is ATAG organized?

ATAG in it’s current version, version 2.0, is organized in following layers;

  1. Principles – that provide a high level organization for the ATAG guidelines itself (just like POUR for Web Content Accessibility Guidelines),
  2. Guidelines – that provide the objectives and framework for last layer,
  3. Success criteria that are requirements for accessibility which can be tested (just like WCAG has A, AA and AAA levels)

What is WCAG to ATAG?

We can say that ATAG and WCAG are guidelines that make the whole web journey accessible. To just adhere to WCAG means that content is accessible but it does not define the tools that make content accessible. And there comes the ATAG in and fills the gaps that are unique just for the authoring tools.

So – if you use a What You See is What You Get (WYSIWYG) editor for an article that you then save as a webpage, then the tool itself must also be accessible, not just the final product – the article.

While at it we can also mention the User Agent Accessibility Guidelines (UAAG) that are the third part of the triangle. So to summarize: Accessible author tools make accessible content that is then presented in accessible user agents.

How to choose a CMS that is accessible

When you or your company has to select a (new) content management system you have a lot of content-oriented priorities, you have to think on migration from old CMS and maybe even do a risk assessment for change of vendor vs. upgrade of version when applicable.
Accessibility of the CMS itself is probably not the main priority and can even easily be overlooked, even if you are aware of the public-facing accessibility demands and requirements.

So I think that decision makers should consider accessible authoring tools too, and to invest some time into evaluating the new CMS also from accessibility perspective.

Some guidelines on evaluation procedures can be found here (from Web Accessibility Initiative group itself, opens in new window), and it should always be communicated with your vendor or in case of open source CMS with their main contributors/creators.

If you belong to so-called public sector you should know the rules in your country

In European Union – with it’s Web Accessibility Directive that is referring to harmonized standard (EN 301 549 V2.1.2 (2018-08) – PDF format, opens in new window), we can find the following under clause 11.8, Authoring tools shall conform to clauses 11.8.2 to 11.8.5;

  • 11.8.1 Content technology
  • 11.8.2 Accessible content creation
  • 11.8.3 Preservation of accessibility information in transformations
  • 11.8.4 Repair assistance
  • 11.8.5 Templates

Warning: I am not a legal expert on this matter, please check this with legal experts. It seems that WAD is not requiring that authoring tools are accessible per-se, they must just generate accessible content.

What are authoring tool vendors views on the subject

It is probably understandable that authoring tool vendors are primarily focusing on the accessibility of the generated content that is made with their tools due to different constrains (budget, time to market etc.), but the state of accessibility for the authoring tools is improving with the spreading of general accessibility awareness and with more and more developers being committed to make their products accessible and usable at the same time.

Some links to vendor based information on accessibility of their products that reflect the improvements made in the accessibility landscape;

Author: Bogdan Cerovac

I am IAAP certified Web Accessibility Specialist (from 2020) and was Google certified Mobile Web Specialist.

Work as digital agency co-owner web developer and accessibility lead.

Sole entrepreneur behind IDEA-lab Cerovac (Inclusion, Diversity, Equity and Accessibility lab) after work. Check out my Accessibility Services if you want me to help your with digital accessibility.

Also head of the expert council at Institute for Digital Accessibility A11Y.si (in Slovenian).

Living and working in Norway (🇳🇴), originally from Slovenia (🇸🇮), loves exploring the globe (🌐).

Nurturing the web from 1999, this blog from 2019.

More about me and how to contact me: