This post marks the beginning of my five part series diving into more developer-focused WCAG success criteria that might for designers who don't code to follow.
The purpose of success criteria 4.1.1 Parsing is to ensure browsers and assistive technologies can render content reliably, without creating any accessibility barriers for users. The W3C definition is as follows:
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.
If you're like me and your eyes glazed over after seeing the words "markup language" here are the four areas of focus in this success criteria, which we'll dig into each individually:
Luckily, all of these requirements can be caught by an automated testing plugin so there is no need to comb through a thousand lines of code. However, it is helpful to know exactly what is happening with each of these callouts so you can work with your developers on remediation efforts.
First, a little background on web page development:
This requirement is calling out that tags are required at the start of an element as well as at the end, which shouldn't come as a surprise to a web developer as tags usually travel in pairs anyway. For example, to indicate that a section of text is a paragraph, the developer would open the paragraph with a <p> tag and close it with a closing paragraph tag, which looks like </p>. An opening tag and closing tag must appear for all elements on a web page.
Continuing our tag conversation... Tags can be nested within each other. For example: <div><p>This paragraph is nested inside a division</p></div>
The order of nested tags is important. A common mistake when nesting is to close the parent element before the element it contains (its child) has been closed. For example: <p>This word is <strong>bold</p></strong>
This would result in an incorrect overlapping of elements that might cause rendering problems for browsers or assistive technology.
Attributes are qualities that describe an element, like an images alternative text or a video players height. If the same attribute is used more than once on an element, the browser or assistive technology may not be able to render it correctly.
It is possible that this success criteria becomes obsolete when WCAG 2.2 releases. The reason behind this is because modern parsers are smart enough to recognize these errors and fix them based on the surrounding structure. If errors remain after the parser, many accessibility specialists believe violations should instead be tied to 1.3.1 Info and Relationships, which I've conveniently already written about here.
Introduction to my most recent accessibility side project