Domain 1.5 - Authoring Tool Accessibility Guidelines (ATAG 2.0)
Published
I read this part of the BoK earlier in my study prep and I'm just now writing out the notes. ATAG is one of those guidelines that gets mentioned but not really explained, so I wanted to jot down what I understood from it.
Here's what I learned
What ATAG Is
ATAG stands for Authoring Tool Accessibility Guidelines, and i's for people who make authoring tools, like content management systems (CMSs), WYSIWYG editors, site builders, etc. Basically, anything that helps people create content for the web. It's not for web developers using the tools, it's for the people making the tools.
ATAG Has Two Parts
ATAG is divided into two main goals:
- Part A: Make the tool itself accessible Example: If a tool has a button bar or modal editor, that UI should be keyboard accessible and usable with a screen reader.
- Part B: Help the user create accessible content Example: The tool should guide users to write good alt text, use proper heading levels, or validate color contrast.
Examples That Helped Me
- A CMS like WordPress: The dashboard should be accessible (Part A), and the editor should encourage you to add headings, image alt text, etc. (Part B).
- A PDF generator: The tool should support tagging PDFs properly and give users prompts or guidance during export.
What I Noticed While Studying
- ATAG isn't as detailed or structured as WCAG, which kind of was took some getting used to coming from WCAG.
- ATAG references WCAG guidelines a lot
- Some of the wording overlaps with WCAG, especially in Part B, that's because Part B tries to push for accessible output that meets WCAG.
What I Found Helpful
- The Implementing ATAG 2.0, especially the breakdown of Part A and Part B
- Looking at familiar tools (like Notion, Google Docs, and WordPress) and comparing them with the guidelines
🧠 What I'm Still Checking out
- How to recognize when a tool supports Part B or not (especially when it's subtle)