Chances are that with the upcoming release of the Web Content Accessibility Guidelines (WCAG) 2.2, 4.1.1 Parsing (A) will be removed. However, that’s not to say that parsing and validation are no longer relevant. In this post, we’ll cover why they remain important as a fundamental step for good development practices.
4.1.1 Parsing actually covers very little
The parsing guideline, requires that:
In content 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…
The impact of these issues is relatively limited. In my experience, they typically surface when an id attribute has been duplicated, leading to the incorrect label or description being linked to a form element.
When checking for these issues using HTML validators and conformance checkers, it’s only a very small number of issues that fail against this success criterion (SC). As Steve Faulkner says, parsing is a PITA:
… the errors that need fixing for accessibility purposes can often be needles in a haystack
Patrick Lauke, summarises the fundamental problems with this SC concisely in the following post:
Misinterpretation of this SC is where I have found myself struggling previously. It can be tempting to include a load of other validation or conformance fails under this SC, but at that point, you’re no longer assessing against the WCAG standard.
This is frustrating.
It can feel like by not reporting problems, you’re letting people down, and allowing inaccessible websites/products to pass. However, Eric Bailey provides really helpful insight as to why sticking to the SCs is important:
By scoping your work to the actual, objectively demonstrable problems in an inaccessible digital experience you are able to help facilitate a trusted remediation process.
It’s a small stepping stone in the right direction.
Validation can still allow us to find problems
With all of that said, you’re probably not fussed about the removal of 4.1.1 Parsing (depending on whether you were a staunch supporter of it before). However, validation can still play a really important part in web development.
You can use the W3C’s HTML validator to identify problems such as:
- Missing
altattributes, for when images do not have a text alternative for people using assistive technologies - You’ve used an element that doesn’t exist, maybe due to misspelling it
- You’ve referenced a non-existent
idattribute, so elements may not be related as intended
I’ve also encountered problems in the past as a web developer where there’s been odd behaviour, which has been resolved by fixing validation errors.
Additionally, there’s a benefit to using the W3C’s validator due to it being easy to access. Having worked in the UK’s Civil Service, I know that some devices are tightly locked down to prevent additional downloads and software from being added. Being able to take a large web page and validate it to quickly check for missing alt attributes is really handy for getting an overview of problems.
Furthermore, while it’s not always the case, a massive list of validation errors can be symptomatic of larger development problems, such as a bloated, developer-focused, JavaScript framework, which may introduce other accessibility problems.
Of course, there are other solutions that can help address the issues I’ve raised here. Browser extensions can be used to find both validation issues, as well as colour contrast, role, ARIA, and a whole host of other issues. There are also automated tools such as pa11y which can be used during development to identify similar issues.
This post is a long winded way of saying proofread or check your work
In short, validating your HTML helps to ensure that your website is going to work as expected for everyone. It’s not the secret sauce to help you catch lots of accessibility issues that prevent people from using your website, but it can help make sure that your websites do the basics right.
Check your code like you give a crap.
Related posts
- The 411 on 4.1.1 by Adrian Roselli - this post further details other 4.1.1 issues and how they can be caught by other SC
- These aren’t the SC you’re looking for… by Patrick Lauke - this is a really fantastic presentation that helps anyone working with WCAG to stick to the standard and feel more confident in checking for the right criteria
- Accessibility Testing with pa11y by Ire Aderinokun - this guide is a great introduction to using pa11y and identifying problems
Changes to this post
- Updated 24th September to include Patrick's fantastic post summarising the issues with the 4.1.1 Parsing SC