The Authoring Tool Accessibility Guidelines (ATAG) 2.0 have been fairly easy for me to read, so far. Having spent a significant amount of time studying WCAG, I’m noticing the similarities in principle, guidelines, and success criteria. All the more, it seems reasonable to expect web developers to assimilate ATAG into their mindset and workflow.
Things I accomplished
- Read Part A of ATAG.
- Added Part A’s principles, guidelines, success criteria, and conformance level to my study spreadsheet.
What I learned today
- Part A has 4 principles, 13 guidelines, and 31 success criteria to follow.
- If I’m using WCAG as a guide in all things web development, then following Part A of ATAG shouldn’t prove much harder. (“POU” out of “POUR” is literally present) More proof that digital accessibility is a mindset and not a checklist.
- SC A.2.2.1 (Status Indicators) really opened my eyes to just how many visual indicators I have when creating a blog post! For instance, a red dotted underline to indicate a typo, a “Saved” text status in gray, or a number in a bubble next to my blog’s name to indicate that a draft is awaiting publication. So many things that could be missed if not made perceivable to assistive technology, like a screen reader.
Accessibility Pro Certified: To Be or Not To Be (24 Accessibility) is a timely article by Glenda Sims that answers the questions of “what is an accessibility professional?” and “how do I become one?” Perfect timing for me, as I’ve been wrestling with these questions myself, which pushed me to create this site and challenge. I could’ve used this insight a year ago when I did my first 100 Days of A11y challenge, which involved a more loose direction than I have now.