Remember the Authoring Tool Accessibility Guidelines (ATAG)
An increasing number of web developers are aware of the Web Content Accessibility Guidelines (WCAG) (though they don’t necessarily use them in their work). But another set of accessibility guidelines seem to be almost completely overlooked – the Authoring Tool Accessibility Guidelines (ATAG).
Where WCAG addresses the information and functionality of a website, ATAG addresses software that is used to create websites or manage the content of websites. There are two versions of ATAG; ATAG 1.0, which was made a recommendation on 3 February 2000 (yes, over ten years ago), and ATAG 2.0, which is currently in Working Draft status. Since a lot has happened on the Web in ten years, ATAG 2.0 is what I am basing the information in this article on.
provides guidelines for designing web content authoring tools that are both (1) more accessible for authors with disabilities and (2) designed to enable, support, and promote the production of accessible web content by all authors.
That quote contains what I think is the obvious reason for there being much less talk about ATAG. After all, most web developers don’t build their own authoring tools but rely on tools built by others to create websites, and content authors rarely build their own Content Management System (CMS) to create and manage content.
But for those who do build web authoring tools, ATAG is very relevant. Unfortunately, it is also pretty much ignored, by commercial and open source products alike. There are exceptions, but they are few. Most web based authoring tools I have used are quite horrible from an accessibility perspective.
The ATAG guidelines are broken down into two parts, each consisting of several principles:
- PART A: Make the authoring tool user interface accessible
- Principle A.1: Authoring tool user interfaces must follow applicable accessibility guidelines
- Principle A.2: Editing views must be perceivable
- Principle A.3: Editing views must be operable
- Principle A.4: Editing views must be understandable
- PART B: Support the production of accessible content.
- Principle B.1: Production of accessible content must be enabled
- Principle B.2: Authors must be supported in the production of accessible content
- Principle B.3: Accessibility solutions must be promoted and integrated
Make it accessible, and make it create accessible content
The executive summary of what ATAG tells creators of authoring tools is make it accessible, and make it create accessible content.
It is not ok to say “But it’s a CMS, so we don’t need to make the interface accessible.” Instead I encourage you to start improving the accessibility of your product now. You don’t have to do it perfectly and all at once, but do make a serious effort and improve it where you can. It is very likely that by doing so you will improve usability for all of your users.
- Previous post: How to respond to email messages that contain multiple questions
- Next post: CSS efficiency tip: use a single stylesheet file for multiple media