Any change in WCAG 2.1? Nope, 2.1 parsing criterion is still a PITA
The WCAG 2.0 Parsing Criterion is a Pain In The Ass (PITA) because the checking of it throws up lots of potential errors that if required to fix, may result in a lot of extra work (in some cases busy work) for developers. This is largely due to the lack of robust tools for producing a set of specific issues that require fixing.
I have discussed the parsing criterion previously in WCAG 2.0 parsing error bookmarklet also providing a bookmarklet that helps to filter out some HTML conformance checker errors that are definitely (maybe) not potential accessibility issues.
I am not saying here that checking and fixing HTML Conformance errors is not an important and useful part of web development process, only that fixing all HTML conformance errors is not a requirement for accessibility. There are good reasons to validate your HTML as part of the development process.
What the WCAG parsing criterion requires?
Is really, only, a very limited subset of the errors and warnings that may be produced when checking with the only available tools (i.e. HTML conformance checkers) for testing the WCAG parsing Criterion. You can use a HTML conformance checker to find such errors, but the errors that need fixing for accessibility purposes can often be needles in a haystack.
1. Complete start and end tags
note: but only when this is required by the specification
Examples of what happens:
Displays this on page:
<img src="HTML5_Logo.png" alt="HTML5" <p>test</p>
Produces this in DOM:
<img <p="" alt="HTML5" src="HTML5_Logo.png"> test <p></p>
i.e. unintended empty
p element with intended text not contained and a mutant attribute
<p="" sprouted on the
What this requirement does not mean
Adding end tags to every element:
<li>list item </li>
or self closing elements without end tags
<input /> <img />
There are rules in HTML detailing which elements require end tags and under what circumstances: Optional Tags. You can also find this information under Tag omission in text/html in the definition of each element in HTML.
Tag omission in text/html:
Neither tag is omissible
Good news is that most code errors of this type will be fairly obvious as they will show up as text strings in the rendered code or effect style/positioning of content and produce funky attributes in the DOM.
2. Malformed attribute and attribute values
<p class="poot pooter">some text about poot</p> <img alt="The Etiology of poot." src="poot.png">
//missing end quote on class attribute with multiple values: <p class="poot pooter>some text about poot</p> //no quotes on class attribute with multiple values: <p class=poot pooter>some text about poot</p> //missing start quote on alt attribute <img alt=The Etiology of poot." src="poot.png"> //no quotes on alt attribute <img alt=The Etiology of poot. src="poot.png">
Note: although some attributes do not require quoted values, the safest and sanest thing to do is quote all attributes.
Spaces between attributes
<p class="poot" id="pooter">some text about poot</p> <img alt="The Etiology of poot." src="poot.png">
//no space between class and id attributes: <p class="poot"id="pooter">some text about poot</p> //no space between alt and src attributes: <img alt="The Etiology of poot."src="poot.png">
Further reading on attributes: Failure of Success Criterion 4.1.1 due to incorrect use of start and end tags or attribute markup
3. Elements are nested according to their specifications
What this requirement means is that you cannot do something silly like having a list item
li without it having a
ol as a parent:
or multiple controls inside a label element:
<label> first name <input type="text">
Examples of what happens:
For “a list item
li without it having a
ol as a parent” depending on browser, the semantics of the list item including the role, list size and position of an item in the list, are lost. It also results in funky rendering across browsers.
For “multiple controls inside a label element” depending on the browser, the accessible name for each of the controls is a concatenation of the text inside the label, so in the example case, each control has an accessible name of “first name last name”. Also clicking, with the mouse, on either text label will move focus to the first control in the label element.
4. Elements do not contain duplicate attributes
Pretty simple, don’t do this:
<img alt="html5" alt="html6">
Note: although this is a requirement in the WCAG criteria and a HTML conformance requirement, it causes no harm accessibility wise unless the 2nd instance of the duplicate attribute is one that exposes required information, the usual processing behaviour for duplicate attributes is that the first instance is used, further instances are ignored.
5. Any IDs are unique
Again, pretty simple, don’t do this
<body> ... <p id="IAmUnique"> ... <div id="IAmUnique"> ... </body>
Note: although this is a requirement in the WCAG criteria and a HTML conformance requirement, it causes no harm accessibility wise unless the
id value is being referenced by a relationship attribute such as
Some further examples of HTML conformance errors that ARE NOT WCAG parsing criterion fails
- Unrecognized attributes:
eventnot allowed on element
aat this point.
- Unrecognized Elements:
pootnot allowed as child of element
bodyin this context.
- Bad attribute values:
Error: Bad value
- Missing attribute values:
metais missing one or more of the following attributes:
- Obsolete elements and attributes:
alignattribute on the
tdelement is obsolete.