Robust Guideline 4.1 Compatible

4.1.1 Parsing

Removed in WCAG 2.2: it always passes now

Level A Removed in WCAG 2.2 Needs a person to check

What it asks for, in plain English

This criterion used to ask that HTML be well formed: elements properly nested and closed, no repeated attributes, every id unique. It was written when assistive technology parsed HTML itself and could break on bad markup. Browsers now repair broken markup before anything else sees it, so the criterion stopped measuring anything real.

WCAG 2.2 removed it. For WCAG 2.0 and 2.1, the W3C has said it should be treated as always satisfied. You do not need to fix anything to meet 4.1.1, and no tool should fail you on it.

That does not mean markup errors stopped mattering. A duplicate id on a form field breaks its label, which is a 1.3.1 and 3.3.2 problem. A duplicate id referenced by aria-labelledby or aria-describedby gives a control the wrong name or description, which is a 4.1.2 problem. The errors have moved to the criteria that describe their actual effect.

This is an independent explanation. The binding wording is the W3C Recommendation, and the W3C's own Understanding 4.1.1 page has the full intent, techniques and definitions.

Who it affects

A screen reader user is not affected by a stray unclosed tag, but is affected when two elements share an id and the label lands on the wrong one.

Someone using voice control says the visible label of a field and the software focuses a different element with the same id.

A developer reading an older audit may still see 4.1.1 failures listed; they can be moved under 4.1.2 or 1.3.1, or dropped if they have no effect on anyone.

Example

Broken
<label for="email">Email</label>
<input id="email" type="email">

<label for="email">Confirm email</label>
<input id="email" type="email">

Two fields share one id. Both labels point at the first field and the second has no label. That is a 1.3.1 and 4.1.2 failure, not a 4.1.1 one.

Fixed
<label for="email">Email</label>
<input id="email" type="email">

<label for="email-confirm">Confirm email</label>
<input id="email-confirm" type="email">

Unique ids, so each label reaches its own field.

How to check it

  1. Nothing is required for 4.1.1 itself. If an audit tool still reports it, treat the finding as informational.
  2. Do look for duplicate ids anyway. Run Websight or a validator and note any id that appears more than once.
  3. For each duplicate, check whether a label, aria-labelledby, aria-describedby or aria-controls points at it. If so, fix it and log the issue under 4.1.2 or 1.3.1.
  4. A duplicate id used only for styling or scripting is harmless to accessibility.

What Websight checks for 4.1.1

Websight has no automated check for this criterion. It lists it in the manual checklist that comes with every report, so it is not forgotten.

Websight does not fail pages on 4.1.1. It does flag duplicate ids that labels or ARIA attributes point at, and reports those under 4.1.2 and 1.3.1, because those are the criteria the bug actually breaks.

Practical tips

  • Keep ids unique anyway; it costs nothing and your JavaScript will thank you.
  • Component libraries that render the same widget twice on a page are the usual source of duplicates; generate ids per instance.
  • When updating an old audit, move 4.1.1 findings to the criterion they affect rather than deleting them.

Scan your page and see where 4.1.1 stands

Websight gives a score out of 100, explains each automated finding in plain English, and lists the checks a person still needs to do.

Add Websight to Chrome

Free scans, no account, nothing leaves your computer. Automated tools find only part of the problems; the extension says so on every report.