4.1.1 Parsing is gone. WCAG 2.2 removed it, which had never happened to a success criterion before, and both versions that still carry it have since been corrected to say it should be considered always satisfied for any content using HTML or XML, one in the standard's own text and one on its errata page. So a report telling you that duplicate IDs or unclosed tags fail 4.1.1 is telling you something W3C no longer says, whichever version of the standard you are working to.
The findings underneath are not always worthless, which is the part that makes this confusing. A duplicate ID can still break a real thing. What has changed is which rule it fails, and W3C names the replacements directly, which is that issues of this kind are covered by different success criteria and should be reported under those criteria rather than as issues with 4.1.1.
The Four Positions W3C Holds at Once
Every one of these is current, published and reachable today. Read any one on its own and it sounds like the whole answer, which is why the same argument keeps happening.
| Where | What it says | What that means for you |
|---|---|---|
| WCAG 2.0, at its dated URL | The criterion in full, exactly as written in 2008, with no qualifying note in the document itself | A regulation that points at the 2008 text points at a criterion that is still stated there. The errata page carries the always-satisfied wording, and the Recommendation does not |
| WCAG 2.1, as published today | The criterion, plus a note saying it should be considered always satisfied for HTML or XML, and a second note saying the underlying issues belong to other criteria | Nothing to prove. The note arrived in a 2023 update, so a law naming the dated 2018 version does not include it |
| WCAG 2.2 | The criterion is not in the document at all | There are 55 rules at A and AA, and this is not one of them. Any checklist that still lists it predates October 2023 |
| The Understanding page for 4.1.1 | Still published, titled Parsing (Obsolete and removed), and still carrying a Test Rules section that names two test rules | This is where your tool got its authority. A removed criterion with a live page naming test rules for it |
Follow those two test rules and the picture gets stranger rather than clearer. Both open with a deprecation banner explaining that the criterion was removed in WCAG 2.2 and should be considered always satisfied in 2.1 and 2.0. Both then state, further down the same page, that they are required for conformance to WCAG 2.0 and later at Level A and higher. And neither appears in W3C's index of test rules, whose Guideline 4.1 section lists Name, Role, Value and Status Messages and stops there.
The techniques behind them have been retired more cleanly. The three that used to satisfy 4.1.1, covering unique IDs, duplicate attributes and matching start and end tags, are all still online with [Obsolete] in front of their titles and a banner explaining why. They are not in the current technique library, which is why they are absent from our own fix guides as well.
Where a Duplicate ID Finding Actually Belongs
This is the useful half, and it is the sentence to send back to whoever produced the report. Most issues that used to fail 4.1.1 now fail Info and Relationships or Name, Role, Value instead, and the rest are excepted by the except where the specifications allow these features clause the criterion always carried.
The mechanism is worth understanding, because it tells you which duplicate IDs matter. Both aria-labelledby and a label's for attribute find their target by ID, and both stop at the first match. So a duplicate ID that sits on an element something points at can silently redirect a label to the wrong control, and the control ends up with the wrong name or none at all. That is a naming failure with a real consequence, and it gets filed under Name, Role, Value.
A duplicate ID that nothing references is a different animal. It is untidy, it will bite somebody eventually, and it fails no success criterion. The honest report says so, and the difference between those two cases is a question a tool cannot answer, because answering it means following every reference on the page.
| What the scan reported | Whether it still fails something | Under which rule |
|---|---|---|
Duplicate ID referenced by aria-labelledby or a label's for | Yes, if the association breaks or resolves to the wrong element | 4.1.2 Name, Role, Value, and often 1.3.1 as well |
| Duplicate ID nothing points at | No | None. Fix it as hygiene, not as compliance |
| Unclosed or badly nested elements | Only where the recovered markup loses a role or a relationship | 1.3.1 Info and Relationships, or 4.1.2 where a control loses its role |
| Duplicate attributes on one element | Rarely. Browsers are required to handle it consistently | None on its own |
| Invalid or unknown attributes | Never did fail this rule | None. The criterion covered four specific things and this was not one of them |
Why It Was Removed, and the Reason Most People Give Is Half of It
The usual explanation is that browsers got better at recovering from broken markup. True, and second in W3C's own order. The reason they lead with is different, which is that assistive technology used to parse HTML itself and no longer does. It reads the tree the browser has already built, so the browser's recovery is the only parsing that happens and the criterion had nothing left to protect.
The second half of the reasoning is a technicality that swallowed the rule. The criterion always ended with except where the specifications allow these features, and the HTML Living Standard has since adopted specific requirements for how user agents must handle incomplete tags, incorrect nesting, duplicate attributes and non-unique IDs. Those cases are still non-conforming for authors, and they are now handled consistently by every browser, which W3C treats as the specification allowing them for the purposes of this criterion. The exception grew until it covered the rule.
The Cases Where 4.1.1 Still Binds You
Laws do not point at WCAG 2.1. They point at a specific published version at a specific URL, and that text is frozen on the day the regulation names it. The always-satisfied note arrived in the September 2023 update to WCAG 2.1. The version the US Department of Justice incorporated into its Title II rule is the one published on 5 June 2018, which does not carry the note.
So for a US state or local government working to that rule, 4.1.1 stands as written in 2018 and a conformance claim has to address it. The same logic reaches any obligation naming a dated version, and it is the reason a compliance record should name the dated version rather than just the version number.
Section 508 sits in the same awkward position from the other end, because it names WCAG 2.0, and the 2008 Recommendation still states the criterion in full. The always-satisfied wording for 2.0 lives on the errata page rather than in the standard's own text, which is a real distinction and one worth raising with an assessor before they write the report rather than after. Ask which document they tested against.
The other place it surfaces is paperwork. W3C's own backwards-compatibility statement, which is that content conforming to 2.2 also conforms to 2.1 and 2.0, comes with one asterisk attached to this criterion. Authors required by policy to conform to 2.0 or 2.1 may need to continue to test and report 4.1.1, because a page built to 2.2 has never been tested against a criterion 2.2 does not contain. That is a reporting step rather than an accessibility gap, and it belongs in a VPAT written against an older version.
What to Say to a Vendor Who Sends You a Parsing Report
- Ask which version of WCAG the report was run against. If the answer is 2.2, the criterion is not in it and the finding has no rule behind it. If the answer is 2.1 or 2.0, ask for the publication date of the text they used.
- Ask which findings have a downstream consequence. For each duplicate ID, is anything pointing at it. For each nesting error, did the recovered markup lose a role or a relationship. That is the work, and it is not automatic.
- Ask for the surviving findings to be refiled. Under 1.3.1 or 4.1.2, with the broken association named. A finding without a criterion is not a finding, it is a lint warning wearing a compliance badge.
- Keep the lint warnings anyway. Valid markup is cheap to maintain and expensive to retrofit, and the errors that do break something arrive through exactly this door. Just stop counting them as accessibility failures.
The short version for a checklist
If your checklist still lists 4.1.1, it predates WCAG 2.2 and is probably out of date in other ways too, because 2.2 also added six rules at A and AA. Our version history has the full comparison, and the versions guide covers which one your obligation actually names.