Unterschiede und Einsatz für Screenreader-Nutzer
Wer aria-labelledby und aria-describedby verwechselt, sorgt dafür, dass Screenreader Buttons ohne Namen ankündigen oder Fehlermeldungen komplett verschlucken. Dieser Artikel erklärt den Unterschied zwischen dem zugänglichen Namen und der zugänglichen Beschreibung, zeigt die Namensberechnung nach WAI-ARIA, das Referenzieren mehrerer IDs und die häufigsten Verwechslungen anhand echter Formular- und Dialogbeispiele.
Inhaltsverzeichnis
- 1. Zugänglicher Name vs. zugängliche Beschreibung
- 2. aria-labelledby: Wie Screenreader den Namen berechnen
- 3. aria-describedby: Zusatzkontext nach dem Namen
- 4. Mehrere IDs referenzieren: Reihenfolge und Leerzeichen
- 5. Praxisbeispiel: Formularfelder mit Label und Fehlermeldung
- 6. Praxisbeispiel: Dialoge und benannte Regionen
- 7. Namensberechnung: Priorität der Attribute
- 8. Typische Verwechslungen und ihre Folgen
- 9. aria-labelledby vs. aria-describedby im Vergleich
- 10. Zusammenfassung
- 11. FAQ
1. Zugänglicher Name vs. zugängliche Beschreibung
Jedes interaktive Element im Accessibility-Tree besitzt zwei getrennte Textquellen: den zugänglichen Namen (accessible name) und die zugängliche Beschreibung (accessible description). Der Name beantwortet die Frage, was ein Element ist oder tut, etwa "Suche starten" bei einem Button. Die Beschreibung liefert zusätzlichen Kontext, der nach dem Namen und der Rolle vorgelesen wird, etwa "Öffnet die erweiterte Suche in einem neuen Bereich". Screenreader kündigen Elemente in einer festen Reihenfolge an: zuerst der Name, dann die Rolle, dann der Zustand, optional zuletzt die Beschreibung.
aria-labelledby steuert den Namen, aria-describedby steuert die Beschreibung. Beide Attribute referenzieren IDs anderer Elemente im Dokument und übernehmen deren Textinhalt, statt eigenen Text im Attributwert zu tragen. Wer diese beiden Rollen vertauscht, produziert für sehende Nutzer unsichtbare Fehler: Der Button sieht korrekt beschriftet aus, aber der Screenreader liest an der falschen Stelle vor oder überspringt den Namen komplett. Genau diese Verwechslung ist einer der häufigsten Barrierefreiheitsfehler in individuell gebauten Formularen und Komponenten.
2. aria-labelledby: Wie Screenreader den Namen berechnen
aria-labelledby hat in der Namensberechnung die höchste Priorität und überschreibt sowohl aria-label als auch ein natives <label>-Element sowie den sichtbaren Textinhalt. Der Attributwert ist eine durch Leerzeichen getrennte Liste von IDs. Der Browser sammelt den Textinhalt jedes referenzierten Elements, verkettet ihn in der angegebenen Reihenfolge und stellt das Ergebnis dem Accessibility-Tree als Namen zur Verfügung. Das funktioniert auch dann, wenn das referenzierte Element selbst kein interaktives Element ist, etwa eine Überschrift oder ein einfacher Span.
Ein häufiger Einsatzzweck ist die Wiederverwendung bereits sichtbaren Textes als Name für ein zusätzliches Steuerelement, etwa einen Icon-Button neben einer Produktkarte. Statt den Kartentitel als redundanten aria-label-String zu duplizieren, referenziert der Button die ID der Überschrift direkt. Ändert sich der Titel später dynamisch per JavaScript, bleibt der Name automatisch synchron, weil beide Quellen auf denselben Textknoten zeigen. Wichtig: Ein per display:none verstecktes Referenzelement wird für die Namensberechnung trotzdem ausgewertet, solange aria-labelledby explizit darauf zeigt, das ist ein bewusst spezifiziertes Verhalten der Namensberechnung.