Doppelte IDs: Ein kleiner Markup-Fehler mit überproportionalen Folgen

Ein id-Attribut existiert, um ein Element auf einer Seite eindeutig zu identifizieren – nichts anderes soll es sich teilen. Wenn zwei Elemente dieselbe id teilen (oft aus einer kopierten Komponente, einer wiederholten Listenelement-Vorlage oder einem CMS, das denselben Block zweimal rendert), wird jeder Code oder jedes Markup, das auf diese id verweist, mehrdeutig: Browser und assistive Technologie lösen dies typischerweise zu welchem passenden Element auch immer zuerst im DOM erscheint auf, wobei der Rest stillschweigend ignoriert wird.

Dies ist WCAG-Erfolgskriterium 4.1.1 (Parsing) in WCAG 2.0/2.1 – erwähnenswert ist, dass 4.1.1 in WCAG 2.2 vollständig entfernt wurde, da die Fehlerbehebungs-Verarbeitung moderner Browser die meisten Fragen zur reinen Markup-Gültigkeit gegenstandslos macht. Doppelte IDs verursachen jedoch weiterhin echte funktionale Fehler unter 4.1.2 (Name, Rolle, Wert), wann immer sich tatsächlich auf die doppelte ID für eine Beschriftung, ARIA-Referenz oder einen Fragment-Link verlassen wird – die Streichung von 4.1.1 bedeutet nicht, dass doppelte IDs harmlos wurden, nur dass "das HTML validiert technisch nicht" aufgehört hat, der relevante Fehlermodus zu sein.

Wo dies tatsächlich Dinge zerstört

Ein <label for="...">, das einer doppelten id entspricht – die Beschriftung kann sich an das falsche Eingabefeld binden, oder an welches auch immer zuerst kommt, sodass das andere aus Sicht eines Screenreaders völlig unbeschriftet bleibt, obwohl das Markup auf den ersten Blick korrekt aussieht.

<!-- Zwei Formularfelder auf der Seite, beide id="email" aus einem kopierten Block -->
<label for="email">Rechnungs-E-Mail</label>
<input id="email" name="billing_email">

<label for="email">Versand-E-Mail</label>
<input id="email" name="shipping_email">
<!-- Beide Beschriftungen binden sich möglicherweise nur an das ERSTE Eingabefeld -->

ARIA-Attribute wie aria-labelledby oder aria-describedby, die auf eine id verweisen – ist diese id nicht eindeutig, löst sich die Referenz unvorhersehbar auf, und der barrierefreie Name oder die Beschreibung, die assistive Technologie ankündigt, stimmt möglicherweise nicht mit dem überein, was ein sehender Nutzer sieht.

Seiten-interne Anker-Links (<a href="#abschnitt-2">) – bei einer doppelten Ziel-id springt der Browser zur ersten Übereinstimmung, die möglicherweise nicht diejenige ist, die der sichtbare Linktext versprochen hat.

Wie man es behebt

Machen Sie jede id auf der gesamten Seite tatsächlich eindeutig, nicht nur innerhalb des lokalen Geltungsbereichs einer einzelnen Komponente. Meist bedeutet dies, Komponenten zu prüfen, die mehrfach auf einer Seite gerendert werden (eine in einer Liste wiederholte Karte, eine für mehrere verschiedene Dialoge wiederverwendete Modal-Vorlage), und von einer fest kodierten id zu einer zu wechseln, die etwas pro Instanz Eindeutiges einbezieht – den Datenbankschlüssel eines Elements oder ein von der Komponente erzeugtes eindeutiges Suffix.

<!-- Vorher: fest kodierte id, bricht, wenn sich die Komponente wiederholt -->
<div id="card-title">...</div>

<!-- Nachher: eindeutig pro Instanz -->
<div id={`card-title-${item.id}`}>...</div>

Dies ist eine mechanische Lösung, sobald gefunden, aber visuell leicht zu übersehen, da nichts auf dem Bildschirm falsch aussieht – es tritt nur als funktionaler Fehler zutage bei welcher assistive-Technologie-abhängigen Funktion auch immer, die auf die kaputte Referenz angewiesen ist.

Offizielle Referenzen

• Deque University: duplicate-id
• W3C Technique F77
• W3C Technique H93