4.1.1 Parsing (Obsolete and removed)

1. What is the goal of this criterion?

In the early days of the web, code quality was a real sticking point – like a badly written recipe that every cook interprets differently. Websites with faulty HTML meant that browsers and assistive technologies produced completely different results.

The original goal of Success Criterion 4.1.1 was to ensure that markup languages were written correctly enough for all user agents – from browsers to screen readers – to interpret the content reliably. Today, the criterion is history: WCAG 2.2 classed it as obsolete and removed it, because assistive technologies no longer parse HTML themselves.

2. What exactly did it require?

The former Success Criterion 4.1.1 (Level A in WCAG 2.0 and 2.1) required the following for markup languages, mainly HTML:

• Complete start and end tags: every element had to be opened and closed correctly
• Correct nesting: elements couldn’t overlap or be nested incorrectly
• No duplicate attributes: an element couldn’t contain the same attribute more than once
• Unique IDs: each ID could only be used once per page

Exceptions only applied where the specification of the technology explicitly allowed these deviations.

Why is it obsolete today? Since HTML5, it’s precisely defined how browsers handle even faulty markup – all modern browsers build the same document model from it. Assistive technologies no longer read the HTML themselves; they use the accessibility tree provided by the browser. The problems 4.1.1 was meant to address either no longer exist or are covered by other criteria.

3. Why did it originally matter for accessibility?

Imagine giving two cooks the same incomplete recipe – and they make completely different dishes. That’s what used to happen when people’s assistive technology ran into faulty HTML.

The criterion originally supported accessibility because it was meant to:

• promote consistent rendering across different browsers and assistive technologies
• prevent crashes and misinterpretation by screen readers that could occur with badly structured code
• enable reliable references, because IDs and element structures were unambiguous
• ensure predictable behaviour, regardless of the assistive technology used

Today, the browser handles errors according to fixed rules. Whatever can still go wrong is checked directly by other criteria, based on the result.

4. How you would have met the criterion – and what still applies

Even though the criterion is obsolete, the earlier recommendations show what matters for HTML quality:

The key rules were:

• HTML validation: regular checks with the W3C Markup Validator
• Correct tag structure: <div><p>Text</p></div> instead of <div><p>Text</div></p>
• Unique IDs: never <div id="content"> twice on the same page
• Clean attributes: no duplicate attributes on one element
• Systematic code reviews: automated tests for common structural errors

What still matters in practice:

• Duplicate IDs can break associations: if <label for="email"> or aria-labelledby points to an ID used twice, the label may end up on the wrong element. That’s then a failure of Info and Relationships or Name, Role, Value.
• Incorrect nesting can cause lists, tables or controls to arrive in the accessibility tree differently than intended – that’s also covered by 1.3.1 or 4.1.2.
• Validation remains a good tool for catching such errors early – it just isn’t a test criterion of its own anymore.

Tools that are still useful:

• The W3C Markup Validation Service for HTML validation
• Browser developer tools, including the accessibility tree view
• Automated HTML linters in build pipelines
• Accessibility testing tools that flag duplicate IDs in references

Today: faulty markup in itself is no longer an accessibility failure. Clean code is still good practice, though – and wherever errors change meaning or operability, the other criteria apply.

5. Why this criterion mattered for businesses

Even though 4.1.1 is obsolete today, it’s a good example of how web standards evolve – and why businesses should stay up to date.

1. Standards evolve

The removal of 4.1.1 shows that accessibility is a living process. What was critical yesterday may be redundant today. Keeping your testing processes current saves you unnecessary work.

2. Less effort in audits

Audit reports no longer need to list pure validation errors that don’t affect users at all. That makes audits more focused.

3. Focus on real user needs

Instead of chasing technical trivia, teams can focus on criteria that genuinely improve the experience – such as the new WCAG 2.2 criteria on cognitive disabilities, like Accessible Authentication (Minimum).

On the legal side: the W3C has also added a note to WCAG 2.0 and 2.1 stating that 4.1.1 should be considered always satisfied for content using HTML or XML. However, the harmonised standard EN 301 549 – which the European Accessibility Act and its German implementation, the Barrierefreiheitsstärkungsgesetz (BFSG), rely on – refers to WCAG 2.1 and still lists this check in its current version. How auditors deal with it can vary from case to case, so clean markup without duplicate IDs keeps you on the safe side. This section is general information, not legal advice.

6. The success criterion in the W3C’s words

Success Criterion 4.1.1 Parsing (Obsolete and removed)

Note: This criterion was originally adopted to address problems that assistive technology had directly parsing HTML. Assistive technology no longer has any need to directly parse HTML. Consequently, these problems either no longer exist or are addressed by other criteria. This criterion no longer has utility and is removed.

In short: the criterion was removed because assistive technologies no longer parse HTML themselves – the old problems either no longer exist or are covered by other criteria.