The 411 on 4.1.1
There is a non-zero chance that WCAG Success Criterion 4.1.1 Parsing will go away in WCAG 2.2. This isn’t a problem for users, regardless of the problems it may pose for the WCAG process, ACT rules, automated testing tools, or ossified testing processes.
For quick background, this started when one of the authors of 4.1.1 filed an issue in June 2022 (or 13½ years after 4.1.1 was released with WCAG 2) to clarify the language: #2525 Proposal to Rephrase Success Criterion 4.1.1
The resulting conversation made it clear that the original intent was narrower than the language and current interpretation reflects. The outcome was that 4.1.1 no longer serves a purpose today because:
- nesting, closing elements, and duplicated attributes are now handled by browsers in a predictable way owing to documented parsing rules;
idvalues on a page that result in accessibility barriers are generally caught in other Success Criteria.
Today there are roughly three schools of thought on flagging 4.1.1 issues in a web review. The first is to only flag them when they impact users. The second is to log everything without defining the impact on users. The third is to move user-impacting issues under other Success Criteria that are a better fit (which is my approach). This post builds on the third approach.
Mapping to Other SCs
First, the language of 4.1.1 Parsing with its clauses broken up and links to the related content below:
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.
Now for the mappings to other Success Criteria…
1. Complete Start and End Tags
Modern parsers handle this. They will account for elements with required end tags, with rules on when to close an element based on the structure that surrounds and follows it. This includes malformed start and end tags, which is effectively the same.
When those rules result in broken content, you are generally looking at a 1.3.1 Info and Relationships issue because the structure and relationships are no longer being conveyed as intended.
It can also map to other Success Criteria depending on how the DOM is constructed. If the resulting content is so broken that everyone is affected, then it falls outside the scope of WCAG.
2. Improper Nesting
Owing to the vagueness of the language, this has been interpreted to reference the content model of HTML, not syntax. The (non-normative) Understanding Success Criterion 4.1.1: Parsing document clarifies the intent a bit by pointing out it is concerned with cases where
content cannot be parsed into a data structure.
A link in a button can be parsed into a data structure, but it happens to be the wrong content model for HTML. As such, it would pass this Success Criterion. A button wrapping a heading would also pass 4.1.1 even though the content model of HTML dictates only flow content can be in buttons.
Nesting interactive elements would instead fall under 1.3.1 Info and Relationships and likely under 4.1.2 Name, Role, Value since the accessible name and programmatic aspects of one or both controls will be broken. There may also be a 2.1.1 Keyboard and 2.4.3 Focus Order risk depending on why that construct was chosen. 4.1.1 is not needed to flag those cases.
The button wrapping a heading could also fall under 1.3.1 Info and Relationships if the heading is not exposed as a heading. Especially since the point of using
<h#> should be to add to the heading structure of the content.
Parsers will fix basic nesting errors, such as
<a href><strong> (closing a
<strong> after the
<a> within which it opened). Those will have no impact on users and so do not fail WCAG under 4.1.1 or any other Success Criteria.
For elements that have required ancestors and/or descendants, such as lists or tables, those would be caught under 1.3.1 Info and Relationships. For example, wrapping a
<td> around a
<td><tr>) affects the programmatic relationships of the data. The parser may restructure it, but that does not mean the result is what you wanted.
3. Duplicated Attributes
Modern parsers handle this. They will choose one, typically the first one, and run with it.
When the chosen attribute (again, typically the first one) results in broken content, you are generally looking at a 1.3.1 Info and Relationships issue, though it can map to other SCs or be so broken that it falls outside the scope of WCAG because everyone is affected.
For example, if you have two
alt attributes on the same non-decorative image but the first one is blank, you are looking at a 1.1.1 Non-text Content issue. Providing two different
src values on a
<track> could result in a missing or incorrect caption file, leaving you with a 1.2.2 Captions (Prerecorded) issue. And so on.
This is arguably the most complex, given how often
id programmatically connects disparate nodes and contributes to complex widgets. It can also manifest a few different ways, so these examples are not exhaustive.
4a. When Referenced for an Accessible Name
id is used in conjunction with a
<label> element, you have a 4.1.2 Name, Role, Value (for accessible name) and 1.3.1 Info and Relationships (for incorrect relationship) issue. If paired with an ARIA construct as well, then both 4.1.2 Name, Role, Value and 1.3.1 Info and Relationships still apply. It may also fall into 2.5.3 Label in Name territory, such as when paired with
If used with a strictly ARIA construct, you almost certainly have a 4.1.2 Name, Role, Value issue to start.
If your duplicate
id is used for a link reference (not destination), now you have a 2.4.4 Link Purpose (In Context) issue. This can happen when paired with
4b. When Referenced in ARIA Widgets
aria-controls, though not exposed by screen readers by default, a duplicate
id value is a broken relationship, so it falls under 1.3.1 Info and Relationships.
aria-flowto we are looking at more incorrect relationships, so also 1.3.1 Info and Relationships. Depending on implementation and intent these can also impact 1.3.2 Meaningful Sequence and 2.4.3 Focus Order.
4c. When Referenced in Tables
id value is used with the
headers attribute to associate a cell with a specific header (typically when at least one spans a row or column). This is a structural relationship issue and falls under 1.3.1 Info and Relationships. Granted, support for the
headers attribute is poor today anyway.
4d. When Referenced as a Link Target / Destination
If you are using nodes with duplicated
ids as a link destination, and that destination does not match what the link text (and context) is conveying, you may have a 2.4.4 Link Purpose (In Context) issue. As an example, consider a “Skip to main content” link where the first instance of the duplicated
id brings the user to the header instead of the main content.
In the case of ambiguous link text, you have a bug that likely affects all users and is outside the scope of WCAG. As with most bugs, it will have a disproportionate impact on disabled users but it is still a general bug. Using the previous example, if the link text is “Skip” and it brings the user to the header then there is no WCAG issue.
4e. When Not Referenced by Anything
This has no impact on users and can be ignored.
I anticipate the W3C will come out with a clearer and better considered mapping for former 4.1.1 issues. Until then, if you have edge cases you think are absolutely not covered by other Success Criteria then share them in the comments. I have already had a few conversations on the socials and look forward to helping find gaps.
One thing I want folks to keep in mind is that WCAG is the bare minimum of accessibility and, as such, is far narrower than most practitioners (let alone users) would like. Patrick Lauke has a great talk that wades into some of the limitations of WCAG Success Criteria that I encourage folks to watch, particularly if the removal of 4.1.1 fills you with anger:
Thanks to Scott O’Hara (corrections), Eric Bailey (adjustments), Sarah Higley (tweaks), and Devon Persing (moral support) for ruining their Sunday by reading my drafts. Anything that is wrong in this post is my fault.
The title is a reference to the phone number 411 in the U.S. and Canada used to get to directory assistance (information), which is also slang for getting the scoop or details on something.
Thanks again Adrian.
Use of inline SVG that has invalid XML (for example missing end tag in XML) breaks rendering of HTML after the element. Total barrier.
I think that is a perfect 4.1.1.
What will it be in WCAG 2.2 in your opinion?
Thanks in advance
Since the broken rendering of HTML after the element implies the rest of the page is broken, then it affects all users. That means it is outside the scope of WCAG and is a good ol’ fashioned bug.
I audited some markup similar to this recently:
<label for="Date of birth">Date of birth</label>
<input type="text" id="Date of birth" placeholder="MM/DD/YYYY">
The id of the <input> contains white space,
– Chrome created the intended association between label and textbox.
– Firefox used the placeholder text as the textbox’s accessible name.
This was picked up by an automated testing tool as a 4.1.1, and may have slid under the radar for all other SCs. An auditor performing manual testing may have picked it up as a 2.4.6, depending on which browser they’re testing with.
How do the various browsers treat id values that contain white space, and how should we address these differences?
I agree flagging that example solely under 4.1.1 makes for an easier testing process, but it hides the actual impact on users.
Firefox more readily shows there are 2.4.6 Headings and Labels (confusing accName and visual label construct), 2.5.3 Label in Name (the visual label does not match the accName), and 3.3.2 Labels or Instructions (the accName text does not persist once a value is entered) issues. Chrome making its best guess does not mean they do not apply, nor does it mean the 1.3.1 Info and Relationships issue I cite in this post (for the broken relationship) goes away.
Whether or not you log all of those issues depends on your reporting process and maybe how hard you want to drive home the point that this is the outcome of sloppy code. But they are all issues no matter that one browser made a good guess; you can note that exception in your reporting.
This example highlights the importance of testing across browsers and AT while being careful about relying solely on automated checks. However, I expect automated tools to still flag these scenarios as warnings requiring further investigation. It seems unlikely they would dump their 4.1.1 rules versus simply reclassifying them as warnings.
As for the first part of your question (how do various browsers treat white space in IDs), I don’t know without testing and it may change over time anyway.