In one paragraph
IDs used in ARIA and labels must be unique means referenced targets need unambiguous identity within their applicable document or tree scope. Duplicate IDs can connect a control to the wrong label, help text, or owned content. Repair the component's ID generation and every corresponding reference together. The supplied WebAuditOS configuration omits this rule's review results, so no finding does not establish uniqueness.
Why it matters
Label and ARIA relationships commonly identify other elements by ID. Reusing card-title or email in every component instance can leave users receiving another instance's text. Resolution behaviour depends on the relationship and document model; do not assume every consumer recovers duplicates identically.
WCAG 2.2 removed the old Parsing criterion. That does not make broken names or relationships acceptable, and ordinary HTML still has ID-uniqueness rules. Evaluate actual consequences under applicable requirements rather than calling every duplicate an automatic standalone WCAG 2.2 Parsing failure.
Different documents can legitimately use the same ID. Shadow-tree boundaries and explicit relationships also need appropriate understanding. A top-level query does not validate all embedded documents or every component tree.
How WebAuditOS evaluates this finding
The supplied duplicate-id-aria rule focuses on IDs used by relevant labels and ARIA references, including the documented hidden-target and tree-scope handling. Unreferenced duplicates are outside this particular focus.
The source states that duplicate candidates are review outcomes and excluded from its violations report. Its nominal critical impact is not a reported high-severity finding here. A wrong but non-empty computed name can also escape neighbouring missing-name tests.
How to fix it
- Inventory actual ID definitions and their references in rendered repeated components. Include labels, descriptions, control relationships, error messages, and heading references, not just a search for repeated input IDs.
- Give each necessary instance a unique stable ID and update the matching references. For example:
<label for="delivery-email">Delivery contact email</label>
<input id="delivery-email" name="deliveryEmail" type="email">
<label for="billing-email">Billing contact email</label>
<input id="billing-email" name="billingEmail" type="email">Use a reliable instance scheme when more than one address form can appear on the page.
- Prefer your framework's suitable stable-ID mechanism where available, especially across server rendering and hydration. Generating unrelated random IDs independently on client and server can create a different mismatch.
- Keep form submission names and application data identity separate from DOM IDs. A repair should not silently change backend contracts or use a private user identifier as public markup.
- Update all IDREF and IDREF-list attributes together. Removing the duplicate while leaving stale aria-describedby or for values can replace ambiguity with a missing relationship.
- Test repeated dialogs, hidden responsive forms, conditional errors, and dynamic insertion. Two alternatives still in the DOM may conflict even when only one is visually displayed.
- Inspect computed names and descriptions, click-to-focus, keyboard behaviour, and intended ownership. A unique but incorrect target is not a successful repair.
- Record manual or tool-based review of duplicates and re-run related name and reference checks. The supplied report's silence on review-only candidates cannot certify the repaired graph.
What the fix can break
ID changes can affect CSS selectors, fragment links, automation, and application queries. Keep a deliberate migration for dependencies rather than renaming targets in isolation.
An ID derived solely from list position may change when items reorder, connecting stale references to the wrong content. Use a stable instance design appropriate to the component.
Do not hide duplicate content to avoid testing it while references still cross into it. Correct identities and lifecycle management instead.
Questions
Did WCAG 2.2 remove the need for usable relationships?
No. Parsing was removed, but names, states, and structural relationships still need to meet applicable criteria.
Can two separate documents use the same ID?
Yes. Uniqueness and reference scope are not a single global namespace across every frame and page.
Does a non-empty announced name prove the reference is right?
No. It can be another control's name. Verify meaning as well as presence.
Which related checks help?
Review form labels, select names, and the automation limits guide.
What severity does this get in the report?
None, in practice. An axe finding takes its severity from the impact axe reports, mapped critical and serious to high, moderate to medium, minor to low, and this rule is declared critical - but axe reports its failures as "needs review", not as violations, so it does not reach our report. That is why the panel above states a conformance level rather than a severity.