aria-describedby: Zusätzliche Beschreibungen barrierefrei verknüpfen

Viele Formularfelder und interaktive Elemente benötigen mehr als nur einen Namen – sie brauchen zusätzliche Erklärungen, Hinweise oder Fehlermeldungen. <code>aria-describedby</code> stellt diese Verbindung her, indem es auf die ID eines Elements verweist, das die zusätzliche Beschreibung enthält. Im Gegensatz zu <code>aria-labelledby</code>, das den Namen eines Elements definiert, liefert <code>aria-describedby</code> ergänzende Informationen. Diese Unterscheidung ist für die korrekte BFSG-Umsetzung gemäß EN 301 549 Abschnitt 11.1.3.1 entscheidend.

aria-describedby vs. aria-labelledby – der zentrale Unterschied

Beide Attribute verweisen per ID auf andere Elemente, erfüllen aber unterschiedliche Rollen: aria-labelledby definiert den zugänglichen Namen (Accessible Name) eines Elements. Er wird als Erstes vorgelesen und identifiziert das Element. Beispiel: Ein Eingabefeld heißt „E-Mail-Adresse". aria-describedby liefert die zugängliche Beschreibung (Accessible Description). Sie wird nach dem Namen und der Rolle vorgelesen und gibt zusätzlichen Kontext. Beispiel: „Format: name@domain.de". Reihenfolge der Screenreader-Ausgabe: Name → Rolle → Zustand → Beschreibung. Also: „E-Mail-Adresse, Eingabefeld, erforderlich, Format: name@domain.de". aria-labelledby überschreibt andere Namensquellen (<label>, aria-label). aria-describedby ergänzt sie. Beide können auf mehrere IDs verweisen: aria-describedby="hint-1 error-1" – die Texte werden in der angegebenen Reihenfolge verkettet.

Formular-Fehlermeldungen verknüpfen

Der häufigste und wichtigste Anwendungsfall für aria-describedby sind Formular-Fehlermeldungen. WCAG 3.3.1 (Fehlererkennung) verlangt, dass Fehler identifiziert und dem Nutzer in Textform beschrieben werden. Mit aria-describedby wird die Fehlermeldung programmatisch mit dem fehlerhaften Feld verknüpft: <label for="email">E-Mail</label><input id="email" type="email" aria-describedby="email-error" aria-invalid="true"><div id="email-error" role="alert">Bitte geben Sie eine gültige E-Mail-Adresse ein.</div>. Wichtig: aria-invalid="true" markiert das Feld als fehlerhaft, aria-describedby verweist auf die Erklärung. Dynamische Fehler: Wenn die Fehlermeldung erst nach dem Absenden erscheint, sollte der Container bereits im DOM existieren (leer) und erst dann befüllt werden. Zusätzlich role="alert" für sofortige Screenreader-Ankündigung. WCAG 3.3.3 empfiehlt darüber hinaus Korrekturvorschläge.

Hilfetexte, Passwort-Anforderungen und Tooltips

Hilfetexte: Erklärungen unter Formularfeldern werden häufig mit aria-describedby verknüpft: <input id="phone" aria-describedby="phone-hint"><small id="phone-hint">Format: +49 123 456789</small>. Passwort-Anforderungen: Listen mit Passwortregeln sind ideale Kandidaten: <input type="password" aria-describedby="pw-rules"><ul id="pw-rules"><li>Mindestens 8 Zeichen</li><li>Groß- und Kleinbuchstaben</li></ul>. Der Screenreader liest die gesamte Liste als Beschreibung vor. Tooltips: Für Tooltip-Inhalte eignet sich aria-describedby gut: <button aria-describedby="tooltip-1">Hilfe</button><div id="tooltip-1" role="tooltip" hidden>Weitere Informationen...</div>. Beachten Sie: Der Tooltip sollte mit role="tooltip" versehen sein und beim Hover/Fokus eingeblendet werden (WCAG 1.4.13 – Inhalt bei Hover oder Fokus). EN 301 549 Abschnitt 11.3.3.2 übernimmt die WCAG-Anforderung an Labels und Anweisungen.

Mehrere Beschreibungen und Reihenfolge

aria-describedby akzeptiert eine leerzeichengetrennte Liste von IDs: aria-describedby="hint-text error-msg format-info". Die Texte der referenzierten Elemente werden in der angegebenen Reihenfolge zu einem einzigen String verkettet. Praxisbeispiel: Ein Feld hat sowohl einen Hilfetext als auch eine Fehlermeldung: <input aria-describedby="email-hint email-error"><span id="email-hint">Ihre geschäftliche E-Mail-Adresse.</span><span id="email-error">Dieses Feld ist erforderlich.</span>. Der Screenreader liest: „Ihre geschäftliche E-Mail-Adresse. Dieses Feld ist erforderlich." Best Practice: Ordnen Sie die IDs so an, dass der dauerhaft sichtbare Hilfetext zuerst kommt und die dynamische Fehlermeldung danach. Achtung bei versteckten Elementen: Texte in Elementen mit display: none oder hidden werden von den meisten Screenreadern trotzdem als Beschreibung vorgelesen, wenn sie per aria-describedby referenziert werden. Dies kann gewollt sein, sollte aber bewusst eingesetzt werden.

Häufige Fehler und Validierung

1. Fehlende oder falsche ID-Referenz: aria-describedby="error-msg" ohne ein Element mit id="error-msg" im DOM ist wirkungslos und ein WCAG-Verstoß. 2. Verwechslung mit aria-labelledby: aria-labelledby für Hilfetexte zu verwenden überschreibt den eigentlichen Feldnamen. 3. Zu lange Beschreibungen: Ein ganzer Absatz als Beschreibung überfordert Screenreader-Nutzer. Halten Sie Beschreibungen kurz und prägnant. 4. Doppelte Informationen: Wenn das <label> bereits „E-Mail-Adresse (Pflichtfeld)" sagt, muss aria-describedby nicht noch einmal „Pflichtfeld" enthalten. 5. Fehlende Live-Ankündigung: Dynamisch eingefügte Fehlermeldungen werden nicht automatisch vorgelesen, nur weil sie per aria-describedby verknüpft sind. Ergänzen Sie role="alert" oder aria-live="assertive" für sofortige Ankündigung. Automatisierte Tools wie bf-check können defekte ID-Referenzen und fehlende Beschreibungen erkennen.