The A11y Path

WCAG's last principle, Robust, ensures that web platforms are built in a way that different technologies (like browsers and Assistive technologies), now and in the future, can understand it clearly.

Your website may look fine visually, however, it might not be semantically acurate so Assistive Technologies (AT) might not interpret it well.

Robustness is important because it ensures that your website is future-proof and can be used by everyone, regardless of the technology they use.

4.1 Compatible

This guideline ensures that your web platform works well with AT (like screen readers, voice control, or magnifiers), now and in the future. To do this your your code needs to be:

• well structured
• standardized, using HTML, ARIA, and APIs the way they're meant to be used
• predictable and clear, so that technologies can understand it without guessing (and other developers who maintain or build on your content later can easily understand it)

4.1.1 Parsing (Level A)(Obsolete and removed in 2.2)

This Success Criterion (SC) ensured that AT could understand and present web content correctly, without getting confused by broken or messy code.

This SC was added because assistive technologies (like screen readers) used to parse HTML and a missing closing tag for example, might make the AT misinterpret the content or fail to read the content. It was removed in WCAG 2.2 because AT now rely on the browser to parse HTML and modern browsers have gotten smarter and they can fix bad markup pretty reliably. So WCAG 2.2 cleaned it up by removing the outdated SC since it no longer served a useful purpose.

While 4.1.1 is no longer required in WCAG 2.2, it is still nice to use valid, semantic HTML for a lot of other reasons like making a code readable for other developers.

4.1.2 Name, Role, Value (Level A)

This SC makes sure that every user interface component (like buttons, links, form fields, sliders, etc.) clearly exposes:

• its name (label or accessible name)
• its role (what it is — a button, a checkbox, a link, etc.)
• its state, properties, and values (for example, expanded, selected)

...to assistive technologies like screen readers.

Assistive technologies can't guess what your custom components are supposed to do. If you build a custom toggle switch with <div> and style it to look like one, screen readers will not know it's a toggle unless you tell them using semantic HTML or ARIA.

To meet this SC you should use semantic HTML like <button>, <input>, <a> with href, they already expose the name, role, and value to AT. If you need to build a custom component, you can use ARIA roles and attributes to expose the name, role, and value to AT.

This SC helps screen reader users, switch input users, and people with cognitive disabilities

4.1.3 Status Messages (Level AA)

This SC ensures that when a user interacts with a component (like a form field, a button, or a slider), the status of the component is clearly announced to assistive technologies especially when those messages do not move focus.

For example, if a user submits a form and there's an error, the screen reader should announce the error message. Or if a user opens a dropdown, the screen reader should announce that the dropdown is open.

This SC only applies to brief, non-intrusive messages that Inform the user of the result of an action, or communicate errors or status. These messages do not need to take focus. If they do (like a modal dialog), screen readers already pick them up, so they're not covered by this SC.

This SC helps screen reader users, switch input users, and people with cognitive disabilities.

Conclusion

This has been a fun ride! I've learned so much along the way, and I hope you have too. I also put together a Google Sheet. that breaks down all the layers of WCAG 2.2.

While reading 100 Days of A11y,I saw that Amy Carney (the creator of the project) made a helpful sheet that covers WCAG 2.1. So, I decided to make an updated version that includes WCAG 2.2.

I've also been studying the Techniques for WCAG 2.2 and the Common Failures

According to the IAAP's Body of Knowledge (BoK) a Web Accessibility Specialist (WAS) is expected to understand the history of WCAG versions, from WCAG 2.0 in 2008, to WCAG 2.1 in 2018, and WCAG 2.2 in 2023 and be able to explain the changes introduced in each update, To help with that, I created a table listing the new Success Criteria added in WCAG 2.1 and 2.2. You can find it on the second tab of the Google Sheet (titled “WCAG 2.1 and 2.2”).

Next Steps

I'll be studying the Authoring Tool Accessibility Guidelines (ATAG) 2.0 next. I'm not very familar with this but I'm really excited for what I'll learn!

Resources

• Understanding Guideline 4.1: Compatible