Back to reviews and guides

ATAG 2.0 Explained: Understanding the Authoring Tool Accessibility Guidelines

ATAG 2.0 explains requirements for authoring tools to be accessible and to help authors create WCAG-compliant content. This guide shows the two parts of ATAG, practical implementation steps, testing checks and common pitfalls.

Understanding the Authoring Tool Accessibility Guidelines (ATAG) 2.0

Understanding the Authoring Tool Accessibility Guidelines (ATAG) 2.0 sets requirements for software that creates web content. It covers two goals: make the authoring tool itself accessible, and help authors create content that meets WCAG.

Who should follow ATAG 2.0 and why it matters

ATAG is aimed at developers of content management systems, editors, web builders, learning management systems and publishing tools. It reduces barriers for authors with disabilities and raises the baseline quality of published content.

How ATAG 2.0 fits with WCAG and other standards

ATAG works alongside WCAG, not instead of it. WCAG defines how published content must behave. ATAG requires the tool and its workflows to support producing that content. Authoring tools should also respect WAI-ARIA, and be testable under the same assistive technologies used for WCAG testing.

Structure and the two parts of ATAG 2.0

ATAG 2.0 is organised into two main parts. Each part has requirements and support techniques.

Part A — Make the authoring tool user interface accessible

  • Keyboard access and logical focus order for dialogs and editors
  • Readable labels, programmatic names and ARIA support where necessary
  • Contrast and colour settings, scalable text and user preferences
  • Accessible documentation and help for features

Part B — Help authors produce accessible content

  • Templates and semantic components that enforce good structure
  • Prompts and required fields for alt text, captions and headings
  • Built-in content checkers and repair suggestions tied to WCAG issues
  • Export and import that preserve semantics and metadata

Conformance and what a claim means

Conformance to ATAG is declared per part and requires documented evidence. That evidence typically shows which requirements are met, test procedures used, and examples of fixes. A conformance claim should be precise about the product version and the parts covered.

Step-by-step: implementing ATAG 2.0 in a CMS or editor

  1. Audit current behaviour: map where authors work, where content is transformed, and which UI controls are inaccessible.
  2. Prioritise quick wins: add alt-text enforcement in image upload, install accessible templates, fix keyboard traps.
  3. Build content-assist features: inline accessibility checks, contextual guidance, and one-click fixes where possible.
  4. Preserve semantics through workflows: ensure copy-paste, import and export keep headings, lists and tables intact.
  5. Integrate automated and manual tests: run static checkers for markup and manual tests with a screen reader and keyboard only.
  6. User test with authors who use assistive tech: observe real tasks like inserting images, adding captions and publishing.
  7. Document and train: update help pages, add inline tips and run short staff training for authors.
  8. Monitor and iterate: track support tickets related to accessibility and review tool output periodically.

Practical examples of ATAG-friendly features

  • A media uploader that requires or suggests descriptive alt text and stores it in metadata
  • Heading and list controls that insert semantic HTML rather than styling text
  • Accessibility check that flags low contrast and offers alternative colour swatches that meet contrast ratios
  • Template library with tested, accessible page layouts for common content types

Common mistakes to avoid

  • Relying only on automated checkers and ignoring keyboard or screen reader testing
  • Providing visual hints without programmatic labels or ARIA roles
  • Stripping semantic markup during paste or import, leaving only styled text
  • Making accessibility a one-off project rather than part of the release cycle

Testing checklist for authoring tool teams

Use both automated tools and human tests. Focus on these checks.

  • Keyboard navigation across the entire UI, including dialogs and editors
  • Focus order and visible focus indicators
  • Screen reader compatibility with main editing flows
  • Labels, instructions and error messages that are programmatically available
  • Contrast ratios for text and UI controls (refer to WCAG contrast thresholds)
  • That content exported by the tool meets the organisation’s chosen WCAG baseline
  • Author workflow tests: image upload, table creation, headings, links and captions

Measuring success and business outcomes

Success measures include fewer accessibility-related support tickets, faster authoring times with accessible templates, and higher compliance rates for published pages. Over time, the publisher benefits from broader reach and fewer retrofits.

Further resources

Find the official ATAG specification and implementation techniques on the W3C WAI site and use WCAG resources for content conformance targets. Also test with common assistive technologies your authors use.