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;
- duplicated
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 <tr> (<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.
4. Duplicated id Values
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
If the 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 aria-labelledby.
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 aria-labelledby.
4b. When Referenced in ARIA Widgets
For 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.
For aria-owns and 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
The 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.
That scenario may fail 2.4.1 Bypass Blocks if the user does not skip the expected repeated block of content. If that same link brings the user backward or somewhere else unexpected, there may be a 2.4.3 Focus Order issue.
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 forward to the header and still moves past the repeated content then there is no WCAG issue.
4e. When Not Referenced by Anything
This has no impact on users and can be ignored.
Wrap-up
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.
Update: 14 February 2023
The Troublesome Life and Lamentable Death of Success Criterion 4.1.1 discusses the history of SC 4.1.1. It is written by one of the original authors of SC 4.1.1, who filed the issue in June 2022 (or 13½ years after 4.1.1 was released with WCAG 2) that kicked off its removal from WCAG 2.2.
Because the author takes a swipe at Steve Faulkner’s 2015 post, WCAG 2.0 Parsing Criterion is a PITA, for using an abbreviation in the title as a violation of success criterion 3.1.4
(which is Level AAA), I don’t feel quite so bad pointing out that his post is hosted on Medium, a WCAG-failing (at Level AA) minefield of years-old accessibility barriers well known to the accessibility industry. As such, I encourage you to read it in your browser’s reader mode.
Overall, an interesting read of some selected interpretations of the SC going back 20 years.
Update: 6 June 2023
Added a paragraph to 4d. When Referenced as a Link Target / Destination. It explains how 2.4.1 Bypass Blocks and 2.4.3 Focus Order may apply.
Talk Reference (Added 7 July 2024)
This post was mentioned in a talk at WordCamp Verona 2023.
YouTube: WCAG 2.2: ci siamo! Cosa cambia per l’accessibilità? by Stefano Minoia.
12 Comments
Reply Thanks again Adrian.
Short question;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
In response to . Reply 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.
Reply 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?
In response to . Reply 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.
Reply
Because the author takes a swipe at Steve Faulkner’s 2015 post, WCAG 2.0 Parsing Criterion is a PITA …
The reference to Steve Faulkner’s post was not intended as a swipe to anyone or anything. The reference to SC 3.1.4 was just a joke (actually about my own post, not Faulkner’s), since I didn’t want to expand the abbreviation “PITA”.
In response to . Reply Then I clearly mis-read your intent; my mistake. As for use of “the author”, that was my hackneyed attempt to make this about the content of the post and less about the person behind it (in case there was any unwarranted hassle or pile-on).
Reply I mostly get the argument for removing 4.1.1, because of the browser heuristics, tools that test the DOM are not able to pick up many of the 4.1.1 issues anyway.
But now we are entering the world of accessibility Linters and that gives a new potential to detect issues in markup. Granted that linters can use the same approach and fail the specific issues under other SCs anyway, but this is going to require a lot of remapping.But the major advantage of 4.1.1 in my experience is how code specific the problem and remediation advice can be.
“Hey, you have multiple element with the same id attribute value, fix it, instead of, say, label in name, or 1.3.1 or the catch all 4.1.2 name, role, value, which requires the developer to have deeper understanding of the markup and its impact, something that is generally trending in the wrong direction.
I am not quite sure that a construct like nesting a button inside a link is actually going to fail a specific WCAG SC, depends how the browsers parse the code and expose it. If nothing else, manual testing is likely required to spot the problem.
I worry that we are handcuffing the automated testing tools and giving them a lot less issues to report with the same degree of simplicity and certainty. This will require more manual testing and interpretation which ultimately slows down the process of ensuring accessibility.
There is the counter argument of time wasted fixing duplicate ID attribute issues with no impact on accessibility. Axe does a good job of this separating those into 3 different rules with different severities.I may end up being wrong on this, I sure hope that is the case, but it is my initial reaction based on content and people I’ve worked with.
Revisiting an id attribute with a whitespace in it. This is invalid HTML (and id attribute value cannot have non-alphabetical characters or whitespace), so whether an automated accessibility checker should call this out or not seems to depend on the what the browser does with it. Maybe the browser makes it ok, so we don’t have to worry.
If we start assuming atht technology is smart enough to fill in the gaps, we could start removing some issues that screen readers or other assistive technologies get right, almost always.Examples:
An without an alt attribute is treated as decorative by most screen readers.
Unless the image is informational, we don’t really have a problem.Screen readers are beginning to guess the accessible name of a form control based on its adjacent label element, even if the two are not explicitly connected. If the two are adjacent visually this does not fail 1.3.1 (users who see the screen assume the connection from the visual proximity), and if the screen reader guesses it correctly the input has a descriptive accessible name.
This is a dilemma, maybe not a bad one, as technology continues to try to fill in the gaps where the humans did not provide enough info, but it makes me uneasy.
What I really am troubled about, and maybe my understanding is wrong, is the idea that this requirement should be dropped from all versions of WCAG retroactively. Drop it from WCAG 2.2 but don’t update older versions of WCAG.
Once a standard has been published officially it should not be altered, it should be superceeded by a new version.
In response to . Reply But now we are entering the world of accessibility Linters and that gives a new potential to detect issues in markup. Granted that linters can use the same approach and fail the specific issues under other SCs anyway, but this is going to require a lot of remapping.
I don’t expect a lot of remapping since invalid code is still invalid code (and linting happens before correction in the DOM). The specific WCAG checks would come from the library it imports.
But the major advantage of 4.1.1 in my experience is how code specific the problem and remediation advice can be.
I see no reason that would go away. A 4.1.1 checking rule gets shifted to a best practice check or another SC and the remediation advice stays the same.
I am not quite sure that a construct like nesting a button inside a link is actually going to fail a specific WCAG SC, depends how the browsers parse the code and expose it. If nothing else, manual testing is likely required to spot the problem.
I outline four possible Success Criteria in 2. Improper Nesting above. A manual tester would still need to explain the impact, of course.
I worry that we are handcuffing the automated testing tools and giving them a lot less issues to report with the same degree of simplicity and certainty. This will require more manual testing and interpretation which ultimately slows down the process of ensuring accessibility.
There is no reason for an automated testing tool to report fewer issues, let alone change the language of what it reports. To your assertion about more manual testing, if reviewers were failing every 4.1.1 issue that an automated testing tool reports then they are doing a disservice to users, clients, and the industry.
Revisiting an id attribute with a whitespace in it. This is invalid HTML (and id attribute value cannot have non-alphabetical characters or whitespace), so whether an automated accessibility checker should call this out or not seems to depend on the what the browser does with it. Maybe the browser makes it ok, so we don’t have to worry.
You can generally apply the rules I outline in 4. Duplicated id Values when an
idhas white space or other disallowed characters. Since the outcome can manifest across (at least) six different SCs this one seems pretty straightforward.If we start assuming atht technology is smart enough to fill in the gaps, we could start removing some issues that screen readers or other assistive technologies get right, almost always.
I don’t think that applies here. We know DOM parsing has rules. We also know that 4.1.1 was poorly scoped. All this does is shift some of the checks to more tangible user-impacting SCs. AT picking up some features does not moot the impact when those features are wrong or absent.
Examples:
An without an alt attribute is treated as decorative by most screen readers.
Unless the image is informational, we don’t really have a problem.But it is not treated as decorative by all screen readers (such as VoiceOver, notably not an edge case), so we do indeed have a problem. Never mind that users who ask their browser to get image descriptions for
alt-less images will hear something announced (and it is usually not helpful).Screen readers are beginning to guess the accessible name of a form control based on its adjacent label element, even if the two are not explicitly connected. If the two are adjacent visually this does not fail 1.3.1 (users who see the screen assume the connection from the visual proximity), and if the screen reader guesses it correctly the input has a descriptive accessible name.
Some screen readers have done this for years (so it is not new). It still fails 4.1.2 (no accName) and 1.3.1 (failure to associate it) because the programmatic relationship is not there. That can strand not just screen reader users but also be a challenge for voice users (it fails 2.5.3). Also, the visible presence of a label satisfies 3.3.2, not 1.3.1.
Reply Adding one note regarding duplicate id cases which maybe fits in your category: “when not referenced by anything”
People creating user styles and/or user scripts (either for their own use or for someone else’s) may rely on unique id values for their customizations of a site to work properly. Yes, there is all kinds of fragility with user scripts and user styles to begin with, but that predictability of unique ids is certainly important in that case.
In response to . Reply Derek, for anything that “may rely on unique id values”, 4e from my list above would not apply (because it is referenced by something). Reviewers would need to see if 4a through 4d applies in that scenario. If none of those apply but a thing is still broken, then that may be a bug that affects all users. Which makes it not WCAG. But overall, your point about external references that can cause additional issues is absolutely worth testing.
Reply Thanks Adrian for this great article.
I have a short question. I was wondering why I don’t see any mention of the attribute aria-describedby.
I thought that the text under an input field (helper text) should be linked to the field. If it doesn’t, is it a failure of 1.3.1 – Info and Relationships?
Leave a Comment or Response