What does WCAG 4.1.1 require about IDs?

The original Success Criterion 4.1.1 (Parsing) required that IDs be unique and that elements be nested and closed correctly. Although WCAG 2.2 retired the broader parsing criterion as obsolete, unique IDs remain essential because aria-labelledby, aria-describedby, and label-for associations resolve to the first element with a given ID — duplicates silently break them.

Why is a duplicate ID a real problem if the page still renders?

The page renders fine, but ID references resolve to the first matching element only. If a second element shares that ID and an ARIA attribute or label points at it, the reference quietly targets the wrong element, so a screen reader announces the wrong label or none at all. It is a silent accessibility bug.

How does the browser parser help detect issues?

When the browser parses HTML it applies the standard error-recovery rules, closing unclosed tags and re-parenting misnested elements. By comparing the parsed structure against your raw input the tool can surface IDs that collapsed together or elements that moved, which often signal the malformed markup the old criterion targeted.

Does an empty id cause problems?

An id of empty string is invalid and cannot be referenced by any IDREF attribute, so any aria-labelledby pointing at it fails. The tool flags empty IDs separately because they are usually a templating mistake, such as an unfilled placeholder variable.

Is my HTML uploaded anywhere?

No. The check runs entirely in your browser using its native HTML parser. Nothing you paste leaves the page.

HTML Parsing & ID Uniqueness Checker (WCAG 4.1.1)

ID uniqueness is the part of the old WCAG 4.1.1 (Parsing) criterion that still bites in practice. Duplicate IDs do not break rendering, so they survive manual testing, but they silently break every ARIA reference and label association that points at the duplicated value. This tool parses your HTML the way the browser does and reports the collisions that matter.

How it works

The tool feeds your pasted HTML to the browser’s native parser, which applies the same error-recovery rules used when rendering a real page. It then analyses the resulting document:

Collect every id. It counts how many elements carry each id value.
Flag duplicates. Any value used more than once is a collision. Because IDREF attributes resolve to the first match, the rest are unreachable.
Flag empty IDs. An id="" cannot be referenced and is almost always a templating bug.
Cross-reference ARIA usage. For each duplicated ID, the tool checks whether any aria-labelledby, aria-describedby, aria-controls, or for attribute points at it. A duplicated ID that is actually referenced is escalated to high severity, because it is producing a wrong or missing announcement right now.

Because the browser repairs malformed markup during parsing, two elements that you intended to be separate can collapse or re-parent; comparing the parsed tree to your raw input helps surface those cases too.

Example

Given:

<label for="qty">Quantity</label>
<input id="qty" />
<input id="qty" />

Both inputs share id="qty". The for="qty" label associates only with the first input; the second input has no programmatic label at all. The checker reports qty as a duplicate used twice and escalates it because a for reference targets it.

Tips and notes

Generate IDs from a stable unique key (a record ID, a slug) rather than a hard-coded literal that a loop can repeat.
Audit list and table templates first — repeated rows are the most common source of duplicate IDs.
Pair this with an aria-describedby validator: unique IDs plus resolving references together guarantee your labels reach assistive technology.
All parsing is local to your browser; nothing you paste is transmitted.