Mehrdeutige IDs: Harmloser Mitleser oder Katastrophenkönigin?
Ein paar Hintergrundinformationen
Doppelte IDs gehören zu den häufigsten Verstößen gegen WCAG 4.1.1, die von automatisierten Barrierefreiheits-Testtools wie „axe“ gemeldet werden, und können für Ihre Nutzer eine ganze Reihe von Problemen verursachen. Dies tritt auf, wenn mehr als ein Element auf der Webseite dasselbe ID-Attribut aufweist. Ich werde oft gefragt, wie diese scheinbar harmlosen, mehrdeutigen IDs so viele Probleme verursachen können.
Die einfache Antwort: Wie bei so vielen Fragen der Barrierefreiheit und Benutzerfreundlichkeit hängt es wirklich von der jeweiligen Situation ab und davon, wie ID-Attribute verwendet werden. Manchmal kann die Verwendung nicht eindeutiger ID-Attribute katastrophale Folgen haben – und zwar nicht nur für die Barrierefreiheit, sondern auch für die Benutzerfreundlichkeit. In diesem Beispiel zeige ich Ihnen, wie das funktioniert.
Beispiel 1 – Alter, welche Kreditkarte habe ich benutzt?
Die folgende Situation hat sich nicht ereignet: Vor langer, langer Zeit, in einer weit, weit entfernten Galaxis. Es geschah auf einer echten Webseite eines echten Unternehmens.
Klicken Sie mit der Maus auf die zweite oder dritte Beschriftung im Formular („Karte, die auf 9892 endet“ oder „Karte, die auf 2388 endet“):
F: Welches Kontrollkästchen wurde angekreuzt?
A: Höchstwahrscheinlich das erste Kontrollkästchen („Karte, die auf 4499 endet“).
Moment mal. Was ist denn passiert?
In diesem Formular sind die Beschriftungen explizit ihren Kontrollkästchen zugeordnet (der Wert des Attributs der Beschriftung stimmt mit der ID des Kontrollkästchens überein). Bei korrekter Umsetzung sorgt dies sowohl für Barrierefreiheit als auch für eine einfache Bedienbarkeit. Wenn eine Beschriftung eindeutig einem Formularfeld zugeordnet ist, können Nutzer mit der Maus auf die Beschriftung klicken, um mit dem Formularfeld zu interagieren. So können sie beispielsweise ein Kontrollkästchen oder einen Optionsschalter aktivieren oder deaktivieren oder den Fokus auf ein Texteingabefeld setzen. Der vergrößerte anklickbare Bereich kommt vielen Nutzern zugute, beispielsweise älteren Menschen mit Sehschwäche oder Menschen mit eingeschränkter Feinmotorik. Er ist aber auch für den ganz normalen Otto (oder die ganz normale Anna) hilfreich, ganz einfach, weil er besser zu erkennen und zu bedienen ist.
In unserem Beispiel hatten jedoch alle Kontrollkästchen dieselbe ID. Dies ist ungültiges HTML, und der Browser muss sein Bestes tun, um dies auszugleichen. Die meisten Browser suchen nach dem ersten Element im DOM, dessen ID mit der im „for“-Attribut des Label-Elements angegebenen ID übereinstimmt. Dann wird das Label diesem Element zugeordnet.
Und so kam es, dass alle drei Beschriftungen dem ersten Kontrollkästchen zugeordnet wurden. Die anderen Kontrollkästchen blieben außen vor, leer und namenlos.
Aber wenn ich direkt auf das Kontrollkästchen klicke oder es mit der Leertaste aktiviere, funktioniert alles einwandfrei!
Wenn Sie direkt mit dem Steuerelement interagieren, muss der Browser nicht erraten, welches Kontrollkästchen Sie ausgewählt haben.
Ich sehe darin ein Problem der Benutzerfreundlichkeit. Aber warum ist das ein Problem der Barrierefreiheit?
Man sagt oft, Barrierefreiheit sei sozusagen die „Extremform“ der Benutzerfreundlichkeit. Und das hat folgenden Grund:
Nutzer von assistiven Technologien wie Bildschirmleseprogrammen sind in weitaus größerem Maße auf programmatische Zuordnungen angewiesen als normale Nutzer. Da sie den Bildschirm nicht sehen können, sind die visuelle Anordnung, die Nähe zu anderen Elementen und visuelle Hinweise für sie kaum von Nutzen.
Wenn ein Nutzer eines Screenreaders den Fokus auf ein Formularfeld verschiebt, muss der Screenreader den barrierefreien Namen des Feldes ansagen. Der Screenreader sucht nach der dem Formularfeld zugeordneten Beschriftung und gibt den Textinhalt dieser Beschriftung als barrierefreien Namen des Formularfeldes an.
In meinem Beispiel ist der Screenreader überfordert. Wenn der Nutzer den Fokus auf das erste Kontrollkästchen verschiebt, findet er nicht nur eine, sondern drei damit verknüpfte Beschriftungen. Die meisten Screenreader fügen deren Textinhalte zu einer einzigen Zeichenfolge zusammen und geben diese Zeichenfolge als barrierefreien Namen des Kontrollkästchens an.
Ich habe dieses Beispiel mit NVDA 2023.1 und Jaws 2023 unter Chrome 116.0.5845.97 getestet.
Das erste Kontrollkästchen wird von beiden Bildschirmleseprogrammen wie folgt angesagt:„Karte, die auf 4499 endet – Karte, die auf 9892 endet – Karte, die auf 2388 endet – Kontrollkästchen nicht aktiviert“.
Bei den Kontrollkästchen 2 und 3 wird die Situation noch verwirrender. JAWS und NVDA geben keinen barrierefreien Namen für diese Kontrollkästchen an. Dem Nutzer eines Screenreaders bleibt keine andere zuverlässige Möglichkeit, als ein Kontrollkästchen nach dem Zufallsprinzip auszuwählen, in der Hoffnung, dass die Informationen zur Karte im weiteren Verlauf des Vorgangs angezeigt werden.
Wie ernst ist dieses Problem also?
Wenn Ihr Kunde versehentlich die falsche Kreditkarte zur Begleichung einer Rechnung auswählt, führt dies dazu, dass er eine Transaktion tätigt, die er gar nicht beabsichtigt hat, was letztendlich die Kundenbeziehung beeinträchtigen könnte.
Natürlich können Sie das potenzielle Problem teilweise beheben, indem Sie das WCAG-Erfolgskriterium 3.3.4 einhalten, wodurch der Kunde die Möglichkeit erhält, seine Daten zu bestätigen oder zu korrigieren. Letztendlich wäre es jedoch besser, solche Pannen von vornherein zu vermeiden.
Beispiel 2 – Screenreader, die Unsinn erzählen.
Manchmal erfordert die Barrierefreiheit, dass Entwickler die Beziehung zwischen Elementen auf einer Webseite programmgesteuert für assistive Technologien sichtbar machen. Ein häufiges Szenario ist, wenn Anweisungen mit einem Formularfeld verknüpft sind. Visuell wird dies erreicht, indem das Element mit dem Anleitungstext auf dem Bildschirm in der Nähe des Formularfelds platziert wird oder indem der Anleitungstext als Tooltip angezeigt wird, wenn der Nutzer mit der Maus über das Formularfeld fährt oder den Fokus darauf setzt. Bildschirmleseprogramme sind jedoch ohne zusätzliche Markups nicht in der Lage, diese Informationen zu vermitteln.
Kein Grund zur Sorge! Wir können die erforderliche Markierung ganz einfach mithilfe des Attributs „aria-describedby“ vornehmen. Das Attribut wird dem Formularfeld zugewiesen, und sein Wert ist die ID (oder eine durch Leerzeichen getrennte Liste von IDs) des Elements bzw. der Elemente, die Screenreader ansagen sollen, wenn der Nutzer den Fokus auf das Formularfeld setzt.
Und so kommen wir wieder auf die ID-Attribute zurück. Was soll der Screenreader tun, wenn der Wert des Attributs „aria-describedby“ auf eine ID verweist, die von mehr als einem Element verwendet wird?
Fehler bei den Hinweisen für Screenreader.
Hier habe ich hilfreiche Tooltips für beide Formularfelder bereitgestellt, die für Nutzer von Screenreadern jedoch nicht verständlich sind.
- The <span> elements containing the hints have the same ID attribute:
id="hint". - Beide Formularfelder verweisen mithilfe von
aria-describedby="hint".
Dies ist zwar ungültiger HTML-Code, wird aber wahrscheinlich nur Nutzer von assistiven Technologien betreffen.
Wie werden die Bildschirmleseprogramme mit diesem Durcheinander zurechtkommen?
Ich habe mit derselben Kombination wie im ersten Beispiel getestet und mich dabei auf das Eingabefeld für die Telefonnummer konzentriert. Ratet mal, was ich gehört habe?
- JAWS: „Bitte gib deine Telefonnummer ein, Bearbeiten. Du darfst nur Buchstaben und Leerzeichen verwenden, bitte keine Zahlen …“
- NVDA: „Bitte gib deine Telefonnummer ein, bearbeiten. Du darfst nur Buchstaben und Leerzeichen verwenden, bitte keine Zahlen.“
Oh je. Beide Screenreader suchen nach der ersten Instanz der angegebenen ID und geben den Textinhalt dieses Elements vor.
Und so kam es, dass alle Nutzer von Bildschirmleseprogrammen im ganzen Land aufgefordert wurden, ihre Telefonnummern ausschließlich mit Buchstaben oder Leerzeichen einzugeben.
Wie gravierend ist das Problem nicht eindeutiger IDs also?
Fassen wir noch einmal zusammen.
Wenn die IDs auf Ihrer Webseite weder in Attributen noch in Skripten verwendet werden, ist es unwahrscheinlich, dass sie die Barrierefreiheit Ihrer Webseite beeinträchtigen. Sobald jedoch ein ID-Attribut verwendet wird, um programmatische Beziehungen auf Ihrer Webseite herzustellen, hat dies Auswirkungen auf Ihre Nutzer.
Es gibt viele Situationen, in denen IDs zur Bereitstellung von Funktionen auf Webseiten verwendet werden. Ich habe hier nur zwei der häufigsten aufgeführt.
Neben der Bereitstellung eines programmatischen Kontexts, wie hier gezeigt, können ID-Attribute als Ziele für JavaScript- oder CSS-Selektoren verwendet werden. Lassen Sie Ihrer Fantasie freien Lauf und überlegen Sie sich die unzähligen Szenarien, die auftreten können, wenn Ihre Selektoren nicht so funktionieren, wie Sie es erwartet haben.
Ich habe das Problem anhand des Beispiels eines Screenreader-Nutzers veranschaulicht, doch auch viele andere assistive Technologien, wie beispielsweise Spracherkennungssoftware und Bildschirmvergrößerungsprogramme, nutzen programmatische Beziehungen zwischen Webseitenelementen. Da assistive Technologien zunehmend zum Mainstream werden (beispielsweise in Form von sprachgesteuerten Lösungen zum Surfen im Internet in Autos), ist davon auszugehen, dass die Zahl der Nutzer, die sich auf die Eindeutigkeit Ihrer ID-Attribute verlassen, steigen wird.
Was soll ich tun?
Denken Sie daran: Ein Webseitelement hat bestimmte unveräußerliche Rechte; eine eindeutige ID zu besitzen, ist eines davon.
Verhindern Sie den Identitätsdiebstahl bei HTML-Elementen, indem Sie sicherstellen, dass jedes Element auf Ihrer Webseite, das eine ID benötigt, eine eindeutige ID erhält.
Das erspart Ihren Nutzern eine Menge Ärger und verringert die Gefahr, dass Ihre Kundendienstmitarbeiter verwirrt werden. Außerdem wird dadurch die Frustration der Entwickler gemindert und – in schweren Fällen – auch Schäden an Büromöbeln vermieden. 🙂
*Ein besonderer Dank geht an Birkir Gunnarson für seine bisherigen Beiträge zu diesem Artikel.
