Parsing

In brief

This page is for teams that still work to EN 301 549 V3.2.1. Criterion 4.1.1 asked for clean markup: complete tags, correct nesting, no duplicate attributes and unique IDs. W3C marked it obsolete and removed it from WCAG 2.2, because browsers now parse markup in a consistent way that assistive technology relies on.

The underlying problems have not gone away. Broken markup can still break a label, an aria-labelledby reference or a control, and those cases are covered by 1.3.1 and 4.1.2 instead. Treat clean markup as good practice for every project.

What does it cover?

• The WCAG 2.1 requirement: 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.
• Complete tags: A tag missing a critical character, such as a closing angle bracket or a closing quotation mark on an attribute value, is not complete.
• Status in WCAG 2.2: The criterion is obsolete and was removed in WCAG 2.2, because assistive technology now relies on the browser to parse markup.
• Where it still matters: Many issues that would have failed 4.1.1 now fall under 1.3.1 Info and Relationships or 4.1.2 Name, Role, Value, for example a duplicate ID that breaks a label association.
• Standards: EN 301 549 V3.2.1 is based on WCAG 2.1 and contains the criterion. EN 301 549 V4.1.1 is based on WCAG 2.2, so check its text to see whether the clause was kept.
• Exceptions in the specification: Where a markup specification allows a feature, such as omitting certain end tags in HTML, it does not fail.

Who does it affect?

Users of assistive technology, whose software depends on a consistent structure. Users of browsers that recover from errors differently. Anyone who depends on labels, references and controls that clean markup keeps working.

In the EAA and EN 301 549

The European Accessibility Act (Directive (EU) 2019/882) applies to in-scope products and services placed on the market after 28 June 2025. Recital 47 names four principles for websites and mobile applications: perceivable, operable, understandable and robust. Robust markup is part of "robust".

The technical counterpart is the standard EN 301 549, which incorporates WCAG 4.1.1 by reference and turns it into separate clauses for each kind of ICT.

The standard's document and software clauses for this criterion should be checked in V3.2.1. Whether and how the criterion applies to non-web documents is stated in clause 10 of the standard. Clause numbers follow the "9. + WCAG number" pattern of EN 301 549. In V3.2.1 the software clause is divided into further subclauses for open and closed functionality. Check the exact numbers in the standard when you cite them.

Standard version: Criterion 4.1.1 appears in EN 301 549 V3.2.1, which is based on WCAG 2.1. It was removed from WCAG 2.2, on which EN 301 549 V4.1.1 (September 2026) is based, so check V4.1.1 to see whether the clause was kept. V4.1.1 has not yet been cited in the Official Journal of the European Union. If you work to V3.2.1, treat this criterion as part of it.

A note on EAA scope: Article 2(4) of the Directive excludes certain content from the requirements, for example office file formats published before 28 June 2025 and archives that are not updated after that date. Content you publish or change after that date is not covered by these exclusions.

Directive (EU) 2019/882, EUR-Lex, opens in a new tab

Code examples for the web

1. Duplicate IDs

A duplicate ID can make a label or an ARIA reference point at the wrong element.

<label for="name">Name</label>
<input id="name">
<input id="name"> <!-- duplicate -->

<label for="billing-name">Billing name</label>
<input id="billing-name">
<label for="shipping-name">Shipping name</label>
<input id="shipping-name">

2. A missing closing quotation mark

A missing closing quote can swallow the rest of the tag, and the next attributes with it.

<a href="/contact class="button">Contact</a>

<a href="/contact" class="button">Contact</a>

3. Incorrect nesting

Elements must be nested as their specification allows, for example no link inside a link.

<a href="/a">One <a href="/b">Two</a></a>

<a href="/a">One</a> <a href="/b">Two</a>

4. A duplicate attribute

When an attribute appears twice, browsers keep one and ignore the other.

<button class="primary" class="large" type="button">Save</button>

<button class="primary large" type="button">Save</button>

5. An unclosed element

An element that is never closed can change the structure of everything after it.

<a href="/a">Read more
<p>The next paragraph ends up inside the link.</p>

<a href="/a">Read more</a>
<p>The next paragraph is outside the link.</p>

6. Validate the markup

A validator catches most of these problems in seconds. Run it in the build process.

<!-- Markup is never validated -->

# in CI
npx html-validate "dist/**/*.html"

Code examples for mobile

This criterion is about markup languages. Native iOS and Android screens are not written in markup that a browser parses, so there is nothing to validate in the same way. Using standard components keeps the accessibility tree consistent.

iOS (SwiftUI)

import SwiftUI

struct Contact: View {
    var body: some View {
        // Standard components give the platform a reliable structure
        VStack {
            Text("Contact us").font(.headline)
            Button("Email us") { }
        }
    }
}

Android (Jetpack Compose)

import androidx.compose.foundation.layout.Column
import androidx.compose.material3.Button
import androidx.compose.material3.Text
import androidx.compose.runtime.Composable

@Composable
fun Contact() {
    // Standard components give the platform a reliable structure
    Column {
        Text("Contact us")
        Button(onClick = { }) { Text("Email us") }
    }
}

How to test

• Run an HTML validator: Use the W3C Nu HTML checker or a linter such as html-validate on rendered pages and templates.
• Check IDs: Look for duplicate id values, especially in components rendered several times on one page.
• Check labels and references: Do for, aria-labelledby and aria-describedby point to the right element?
• Check the rendered DOM: Look at the DOM in the developer tools, not only the source, because scripts can create duplicates.
• Check nesting: Look for interactive elements nested inside each other, and block elements inside inline ones where not allowed.
• Check generated content: Content from a CMS or an editor often contains broken tags.
• Use a checker as a starting point: Automated tools find duplicate IDs and attributes (the Understanding page references test rules for both). A person decides what matters for accessibility.

Common mistakes

• Duplicate IDs from repeated components: The same widget rendered twice with the same IDs.
• Duplicate IDs breaking labels: A label connected to the wrong field.
• Missing quotation marks or brackets: Tags that swallow what follows them.
• Invalid nesting: A link inside a link, or a button inside a link.
• Duplicate attributes: Two class or two aria-label attributes on the same element.
• Editor and CMS output: Content pasted from word processors with broken tags.
• Never validating: No linter and no validator in the build.
• Assuming it no longer matters: Browsers repair markup, but not always the way the author meant.

Sources

• Understanding SC 4.1.1: Parsing (Obsolete and removed) (W3C), opens in a new tab
• The W3C Nu HTML Checker, opens in a new tab
• Directive (EU) 2019/882, European Accessibility Act (EUR-Lex), opens in a new tab
• EN 301 549 V4.1.1 (ETSI), opens in a new tab
• The European accessibility standard EN 301 549 has been updated (AccessibleEU), opens in a new tab

Standard version: EN 301 549 V4.1.1 (2026-09), WCAG 2.2. This page is for informational purposes only and is not legal advice. For binding requirements, refer to the official texts of the European Accessibility Act (Directive (EU) 2019/882) and EN 301 549.