When the World Wide Web Consortium (W3C) officially announced version 2.2 of the Web Content Accessibility Guidelines (WCAG), those of us in the digital accessibility space noticed something unusual: WCAG 2.2 actually removed one requirement from the previous version of the guidelines.
That was a big deal. WCAG 2 is generally backward-compatible, which means that each version of the document contains every single requirement (or success criterion) from previous versions.
And the removed criterion seemed — well, fairly important. Here’s the full text of Success Criterion 4.1.1, “Parsing,” which does not appear in WCAG 2.2.
In content implemented using markup languages, elements have complete start and end tags, elements are nested according to their specifications, elements do not contain duplicate attributes, and any IDs are unique, except where the specifications allow these features.
So, why isn’t HTML parsing important for accessibility anymore?
In short, it is important, but for reasons that are addressed in other WCAG criteria. Below, we’ll explain how WCAG changed and why HTML validation still plays an important role in accessibility testing.
The language of WCAG 4.1.1 is purposely specific, and as a result, it covers a fairly narrow range of HTML mistakes. Let’s break the requirements out into a (correctly marked-up) list:
It’s still important for IDs to be unique and accurate — but that’s also addressed within other WCAG requirements. For example, if a page has duplicate id attributes that cause problems for assistive technology users, that would probably be a failure under WCAG Success Criterion 1.3.1, “Info and Relationships.”
But as the authors note, the other requirements of “Parsing" aren’t relevant to modern technologies. Web browsers can make adjustments for common HTML errors.
“Since this criterion was written, the HTML Standard has adopted specific requirements governing how user agents must handle incomplete tags, incorrect element nesting, duplicate attributes, and non-unique IDs,” the authors note. "...In practice, this criterion no longer provides any benefit to people with disabilities in itself.”
That does not mean that developers can ignore HTML validation entirely. If you care about digital accessibility — or search engine optimization (SEO), or the user experience (UX) — validation should still be a part of your strategy.
Related: WCAG 2.2 Is Here (Finally): 4 Takeaways
There are still a few good reasons to validate your HTML (and no, “my coding academy told me to" is not one of them). First and foremost, it’s not especially difficult; the W3C provides a Markup Validation Service along with links to other validators.
Here, it’s also worth noting that the W3C’s Markup Validation Service has improved significantly in recent years. If earlier versions of the tool flagged your (properly marked up content) for syntax issues, it’s worth trying again.
Second, validation helps you find issues that are likely to have an impact on users with disabilities. HTML validators can identify:
Of course, dedicated accessibility testing tools may be more effective at finding these issues — but for developers, the output from HTML validators may be more practically helpful (or at least, more readily available).
Note that HTML validation is not the same thing as a dedicated web accessibility audit. Your digital accessibility strategy should include regular automated and manual testing, ideally performed by experts who have experience with assistive technology.
And while developers have an important role, web designers and content authors should share the work of WCAG conformance — to create truly accessible content, every member of your team needs an accessible mindset.
To learn more, send us a message to connect with an expert or start your accessibility journey with a free automated WCAG 2.2 AA compliance analysis.