There aren’t many resources out there about ATAG. Here are the ones I have found and occasionally come back to.

Why do we need this?

I often hear people question whether ATAG really is applicable to <insert name of tool>. In my experience the answer has so far always been “yes”. Here’s a quick step by step:

1. Does the tool allow creating content for the web? (any editing of content visible on a website)
2. That content needs to be accessible.
3. So the tool needs to make it possible to create accessible content.

It’s as simple as that, regardless of whether the “tool” is a CMS, a text editor, an admin panel, or just a form with a few plain-text fields.

Mitchell Evan also summarizes the need for ATAG in his excellent talk If it’s true it ain’t bragging! Choosing a CMS for accessibility:

Authoring Tool Accessibility Guidelines (ATAG): Who needs them?

• Nobody — because no law or regulation directly requires ATAG.
• Everybody — because ATAG reduces your risk of an inaccessible website.

So – yes, there is no compliance requirement. But it’s no less relevant of a standard, and it is the de-facto goalpost for all authoring tools who care about accessibility out there. Oh and it will likely be part of WCAG 3.0, which will likely be a compliance requirement in the future.

Official resources

There are very few unfortunately.

• ATAG report tool is the official ATAG report generator.
• WAI Authoring Tools is a very promising way to explore how different tools comply with ATAG, unfortunately the project seems to have stalled halfway through.
  • In particular, this project has a list of accessibility features in authoring tools which makes for a very good introduction to ATAG.
• WAI Guide is a W3C project co-funded by the EU’s Horizon 2020 program, that might produce more resources in the future.

Research

There are a few research teams working on authoring tools’ accessibility. Here is the work that stood out the most for me.

• Accessibility Cluster is another EU research project currently under way to look at accessibility in CMSes. There are interesting resources available from the project pilot, unfortunately doesn’t go very far beyond what ATAG already states:
  • Workshops results
  • Guidelines for stakeholders
  • Report for CMS tools in particular (but could apply to any kind of web publishing): Guidelines for authoring tools producers
• Method for accessibility assessment of online content editors (preprint) covers which WCAG guidelines should likely be considered when evaluating ATAG for a CMS.

Drupal and WordPress

In the CMS world, Drupal and WordPress have the most established resources when it comes to accessibility, and ATAG in particular.

Drupal:

• Accessibility in Drupal
• Drupal - Track progress in ATAG 2.0 conformance
  • Out of date but still interesting: Drupal compliance overview of ATAG 2.0
• Web Accessibility, ATAG & Drupal 8
• Talk: Why We Should Get Excited About ATAG 2.0

WordPress:

• WP Accessibility Day
  • Your CMS is an Accessibility Assistant, video
• WPCampus releases results of the Gutenberg accessibility audit

Other platforms

There are a few other authoring tools that have some accessibility / ATAG-relevant resources:

• Wix accessibility tools & guides
• Accessibility at SurveyMonkey
• One I put together for Wagtail: Wagtail accessibility considerations

ATAG examples

To round off this list, here are practical examples of checkers that can help meet ATAG’s Principle B.3: Authors are supported in improving the accessibility of existing content.

• TinyMCE’s accessibility checker
• Tota11y, particularly relevant for content management systems.
  • And its Wagtail implementation, wagtail-accessibility
• Microsoft Office 365 accessibility checker