Was ist aria-describedby? - Zusätzliche Beschreibungen für Barrierefreiheit
Informationen zum Artikel
Autor: Dmitry Dugarev
Als Webentwickler willst Du sicherstellen, dass Deine Interfaces nicht nur gut aussehen, sondern für jeden verständlich sind. Manchmal braucht ein Element – wie ein komplexes Formularfeld oder ein Button mit unklarem Kontext – eine zusätzliche Erklärung. Genau hier kommt das WAI-ARIA Attribut aria-describedby ins Spiel. Es ist Dein Werkzeug, um eine Brücke zwischen einem UI-Element und seiner ausführlicheren Beschreibung zu schlagen, ohne das visuelle Design zu überladen. Es liefert assistiven Technologien wie Screenreadern den nötigen Kontext, den sehende Nutzer oft aus dem Layout ableiten können.
Was ist aria-describedby?
Die offizielle WAI-ARIA Spezifikation definiert aria-describedby wie folgt:
Identifies the element (or elements) that describes the object. [1]
Das bedeutet, aria-describedby stellt eine programmatische Verbindung zwischen einem Element und einem oder mehreren anderen Elementen her, die es beschreiben.
Ausführliche Erklärung
Stell Dir aria-describedby als eine Art erweitertes Tooltip für assistive Technologien vor. Während ein Label (<label> oder aria-labelledby) den Namen eines Elements angibt (das "Was"), liefert die Beschreibung (via aria-describedby) zusätzliche, kontextbezogene Informationen (das "Wie" oder "Warum").
Der Wert des Attributs ist eine durch Leerzeichen getrennte Liste von id-Attributen. Diese ids müssen auf Elemente verweisen, die irgendwo im selben Dokument existieren. Der Inhalt dieser referenzierten Elemente wird dann von Screenreadern als Beschreibung für das ursprüngliche Element vorgelesen.
Ein entscheidender Unterschied zu einem Label ist die Art und Weise, wie die Information präsentiert wird. Ein Label wird in der Regel direkt zusammen mit der Rolle des Elements vorgelesen (z.B. "Benutzername, Eingabefeld"). Die durch aria-describedby referenzierte Beschreibung wird oft nach einer kurzen Pause oder auf eine explizite Nutzeraktion hin angekündigt. Dies signalisiert dem Nutzer, dass es sich um ergänzende, nicht um essenzielle Informationen handelt.
Textbeschreibung für das Schema "Ablauf der Ausgabe durch einen Screenreader bei Verwendung von aria-describedby."
Das Flussdiagramm beginnt, wenn ein Nutzer ein Element fokussiert. Das System prüft, ob das Element ein aria-describedby-Attribut hat.
- Wenn ja, liest der Screenreader zuerst die Rolle und den Namen des Elements vor. Nach einer kurzen Pause wird dann der Inhalt des Elements vorgelesen, auf das
aria-describedbyverweist. - Wenn nein, liest der Screenreader nur die Rolle und den Namen des Elements vor.
In beiden Fällen ist der Prozess danach beendet.
Wofür wird es eingesetzt?
Du setzt aria-describedby immer dann ein, wenn ein Element zusätzliche Erklärungen benötigt, die über den einfachen Namen hinausgehen. Typische Anwendungsfälle sind:
- Formular-Anweisungen: Du kannst damit Anforderungen an ein Passwortfeld (z. B. "Muss mindestens 8 Zeichen lang sein") oder das Format für eine Datumseingabe beschreiben. Mehr dazu in unserer Anleitung zu barrierefreien Formularen.
- Fehlermeldungen: Wenn ein Formularfeld ungültig ausgefüllt wurde, kannst Du die Fehlermeldung per
aria-describedbymit deminput-Feld verknüpfen. So erfährt der Nutzer direkt beim Fokussieren des Feldes, was falsch gelaufen ist. - Zusatzinformationen für Links und Buttons: Ein Link mit dem Text "Mehr erfahren" ist oft nicht aussagekräftig genug.
aria-describedbykann auf einen benachbarten Satz verweisen, der den Kontext liefert, z.B. "Mehr erfahren über unsere neuen Datenschutzrichtlinien". - Komplexe Widgets: Bei einem Schieberegler (slider) kann
aria-describedbyverwendet werden, um den aktuellen Wert oder die Funktion des Reglers zu beschreiben.
Beispiele aus der Praxis
- Gutes Beispiel
- Schlechtes Beispiel
<div>
<label for="password">Passwort:</label>
<input type="password" id="password" aria-describedby="password-hint" />
<p id="password-hint">
Muss mindestens 12 Zeichen, einen Großbuchstaben und eine Zahl enthalten.
</p>
</div>
Erklärung: Hier wird das input-Feld durch das aria-describedby Attribut korrekt mit dem Absatz (<p>) verbunden, der die Passwortanforderungen enthält. Ein Screenreader würde etwa Folgendes ausgeben: "Passwort, Eingabefeld. Muss mindestens 12 Zeichen, einen Großbuchstaben und eine Zahl enthalten."
<div>
<label for="password">Passwort:</label>
<input type="password" id="password" />
<!-- Die Verknüpfung fehlt! -->
<p>
Muss mindestens 12 Zeichen, einen Großbuchstaben und eine Zahl enthalten.
</p>
</div>
Erklärung: Obwohl die Beschreibung visuell vorhanden und in der Nähe des Feldes ist, fehlt die programmatische Verknüpfung durch aria-describedby. Ein Screenreader-Nutzer, der durch die Formularfelder tabbt, würde diese wichtige Information wahrscheinlich übersehen, da sie nicht im Kontext des input-Elements vorgelesen wird.
Best Practices & Empfehlungen
Nutze sichtbare Beschreibungen
Die Inhalte, auf die Du mit aria-describedby verweist, sollten in der Regel auch für sehende Nutzer sichtbar sein. Anweisungen oder Fehlermeldungen sind für alle hilfreich. Das Verstecken von Beschreibungstexten (display: none; oder visibility: hidden;) kann zu einer inkonsistenten User Experience führen und wird von manchen Screenreadern ignoriert. Dies unterstützt das WCAG-Erfolgskriterium, dass Anweisungen zur Verfügung gestellt werden müssen. [2]
Stelle eine korrekte Namensgebung sicher
Der zugängliche Name (Accessible Name) eines Elements sollte immer zuerst definiert werden, am besten mit einem <label for="...">. aria-describedby liefert die Beschreibung, nicht den Namen. Eine klare Trennung zwischen diesen beiden ist entscheidend für die Verständlichkeit. [3] [4]
Referenziere nur relevante und prägnante Inhalte
Verweise nicht auf einen riesigen Textblock. Die Beschreibung sollte kurz und auf den Punkt gebracht sein. Lange Erklärungen können für Screenreader-Nutzer sehr mühsam sein, da sie diese nicht einfach überfliegen können. Fasse die wichtigste Information prägnant zusammen.
Sei vorsichtig mit aria-live
Wenn der Beschreibungstext dynamisch erscheint (z.B. eine Fehlermeldung), musst Du möglicherweise aria-live-Regionen verwenden, um Screenreader sofort zu benachrichtigen. Die Kombination von aria-describedby und aria-live kann jedoch komplex sein. Eine gängige Technik ist es, die Fehlermeldung in einem aria-live-Container zu platzieren und gleichzeitig per aria-describedby mit dem Eingabefeld zu verknüpfen. [5]
Häufige Missverständnisse
aria-describedby ist ein Ersatz für <label>
Das ist falsch. aria-describedby ergänzt ein Label, es ersetzt es nicht. Jedes interaktive Element wie ein input oder button benötigt einen zugänglichen Namen. Dieser wird durch <label>, aria-labelledby oder aria-label bereitgestellt. Die Beschreibung ist eine optionale, zusätzliche Information.
Der Inhalt wird immer sofort nach dem Label vorgelesen
Nicht unbedingt. Die meisten Screenreader machen eine kurze Pause zwischen dem Namen und der Beschreibung, um dem Nutzer zu signalisieren, dass es sich um Zusatzinformationen handelt. Manche Konfigurationen lesen die Beschreibung auch erst auf Anfrage vor. Verlasse Dich also nicht darauf, dass die Beschreibung nahtlos als Teil des Labels wahrgenommen wird.
aria-describedby kann auf ein title-Attribut verweisen
Nein. aria-describedby verweist immer auf den Inhalt eines Elements über dessen id. Es kann nicht den Wert eines anderen Attributs wie title oder placeholder auslesen.
Verwandte Begriffe
- aria-labelledby
- aria-label
- Accessible Name
- Screenreader
- Label
Häufig gestellte Fragen
Was ist der Unterschied zwischen aria-describedby und aria-labelledby?
aria-labelledby definiert den Namen (Accessible Name) eines Elements, indem es auf ein oder mehrere andere Elemente verweist. Es ersetzt den eigenen Inhalt des Elements für die Namensgebung. aria-describedby stellt eine Beschreibung (Accessible Description) bereit, die den Namen ergänzt, ihn aber nicht ersetzt. Kurz: labelledby ist für das "Was", describedby für das "Mehr dazu".
Kann ich aria-describedby auf mehrere Elemente verweisen lassen?
Ja, absolut. Der Wert des Attributs ist eine durch Leerzeichen getrennte Liste von ids. Der Screenreader wird die Inhalte der referenzierten Elemente in der Reihenfolge vorlesen, in der sie im Attribut aufgeführt sind.
Beispiel: aria-describedby="hint-1 hint-2".
Funktioniert aria-describedby auch mit versteckten Elementen?
Technisch ja, aber es ist keine gute Praxis. Wenn Du auf ein Element verweist, das mit display: none oder visibility: hidden versteckt ist, wird es von den meisten Screenreadern trotzdem vorgelesen. Das Problem ist, dass Du damit eine Diskrepanz zwischen dem schaffst, was sehende Nutzer wahrnehmen und was Screenreader-Nutzer hören. Wenn die Information wichtig ist, sollte sie für alle zugänglich sein.
Sollte ich aria-describedby für Fehlermeldungen verwenden?
Ja, das ist einer der besten Anwendungsfälle! Wenn ein Nutzer einen Fehler macht, verknüpfe die Fehlermeldung per aria-describedby mit dem fehlerhaften input-Feld. Setze außerdem aria-invalid="true" auf das Feld. So wird der Nutzer beim erneuten Fokussieren des Feldes direkt über den Fehler und dessen Beschreibung informiert.
Hinweis
Die in diesem Artikel enthaltenen Informationen, insbesondere in Bezug auf Gesetze und Richtlinien wie die WCAG, dienen ausschließlich zu Informationszwecken und stellen keine Rechtsberatung dar. Bei spezifischen rechtlichen Fragen zur digitalen Barrierefreiheit solltest Du immer einen qualifizierten Anwalt konsultieren.
Über den Autor