Zum Hauptinhalt springen

Was ist aria-labelledby? - Visuelle Beschriftung von Elementen mit WAI-ARIA

Informationen zum Artikel

Porträtfoto von Dmitry Dugarev

Autor: Dmitry Dugarev

Berater für digitale Barrierefreiheit & IT-Compliance

Zuletzt aktualisiert am:

Das aria-labelledby-Attribut ist eines der mächtigsten Werkzeuge in Deinem WAI-ARIA-Werkzeugkasten. Es erlaubt Dir, die Beschriftung (den "Accessible Name") eines Elements aus dem Inhalt eines oder mehrerer anderer Elemente auf der Seite zu erstellen. Das ist besonders nützlich, wenn eine sichtbare Beschriftung zwar vorhanden, aber nicht direkt über ein natives HTML-Element wie <label> mit dem interaktiven Element verbunden ist. Es schafft eine programmatische Verbindung, die für assistierende Technologien wie Screenreader entscheidend ist, um den Kontext und die Funktion von UI-Komponenten zu vermitteln.

Was ist aria-labelledby?

Die offizielle WAI-ARIA-Spezifikation definiert aria-labelledby wie folgt:

"Identifies the element (or elements) that labels the current element. See related aria-describedby." [1]

Das bedeutet im Grunde: Das Attribut enthält eine oder mehrere IDs von anderen Elementen in der Seite. Der Textinhalt dieser Elemente wird dann von assistiven Technologien als Beschriftung für das Element verwendet, auf dem aria-labelledby gesetzt ist.

Ausführliche Erklärung

Stell Dir vor, Du hast eine komplexe Benutzeroberfläche. Manchmal ist der Text, der ein Element beschreibt, nicht direkt daneben oder lässt sich nicht einfach in ein <label>-Tag packen. Hier kommt aria-labelledby ins Spiel.

Du gibst dem aria-labelledby-Attribut eine durch Leerzeichen getrennte Liste von id-Attributen. Der Browser sammelt dann den Textinhalt aus jedem dieser Elemente in der angegebenen Reihenfolge und fügt sie zu einer einzigen Zeichenkette zusammen. Diese Zeichenkette wird zum Accessible Name des Elements – also dem Namen, den ein Screenreader vorliest, wenn der Nutzer auf das Element stößt.

Ein entscheidender Punkt ist die Rangfolge bei der Berechnung des Accessible Name. Wenn Du aria-labelledby verwendest, überschreibt es andere Methoden zur Namensfindung, wie den Inhalt des Elements selbst oder ein aria-label-Attribut. Es hat eine sehr hohe Priorität.

Das folgende Diagramm zeigt den Prozess, wie der Accessible Name mittels aria-labelledby gebildet wird:

Textbeschreibung für das Schema "Prozess der Accessible Name Berechnung durch aria-labelledby"

Dieses Flussdiagramm illustriert, wie aria-labelledby funktioniert.

  1. Ein Element hat das Attribut aria-labelledby="id1 id2".
  2. Der Browser und die Accessibility API analysieren dieses Attribut.
  3. Sie suchen die Elemente im DOM mit den IDs "id1" und "id2".
  4. Die Textinhalte dieser beiden Elemente werden extrahiert.
  5. Die Inhalte werden in der Reihenfolge "id1" dann "id2" zu einer einzigen Zeichenkette zusammengefügt.
  6. Dieser kombinierte Text wird zum Accessible Name des ursprünglichen Elements. 7. Ein Screenreader wird diesen kombinierten Namen ansagen, wenn der Nutzer das Element fokussiert.

Wofür wird es eingesetzt?

aria-labelledby ist keine Allzwecklösung, sondern ein Spezialwerkzeug für bestimmte Situationen. Hier sind die häufigsten Anwendungsfälle:

  1. Beschriftung von Dialogen und Modals: Ein <h2>-Titel innerhalb eines Dialogfensters kann als perfekte Beschriftung für den gesamten Dialog-Container (role="dialog") dienen.
  2. Verknüpfung von Formularfeldern mit nicht-standardmäßigen Beschriftungen: Wenn eine Beschriftung aus gestalterischen Gründen nicht direkt mit einem <label> verknüpft werden kann (z. B. in komplexen Tabellen oder Rastern), kann aria-labelledby die Brücke schlagen.
  3. Kombination mehrerer Textquellen: Manchmal setzt sich eine vollständige Beschriftung aus mehreren sichtbaren Textelementen zusammen. Mit aria-labelledby kannst Du sie zu einem sinnvollen Ganzen verketten.
  4. Beschriftung von interaktiven Elementen ohne sichtbaren Text: Ein Button, der nur ein Icon enthält, kann durch einen nahegelegenen, sichtbaren Textabschnitt beschriftet werden.
  5. Strukturierung von komplexen Widgets: Bei Komponenten wie radiogroup, menu oder tree kann ein übergeordnetes Element (z. B. eine div mit einer Überschrift) die gesamte Gruppe beschriften.

Beispiele aus der Praxis

Hier siehst Du den Unterschied zwischen einer guten und einer schlechten Anwendung von aria-labelledby.

Dialogfenster mit aria-labelledby
<!--
Gutes Beispiel:
Der Dialog-Container (role="dialog") wird durch die Überschrift (id="dialog-title") beschriftet.
Ein Screenreader würde beim Öffnen des Dialogs "Einstellungen bearbeiten, Dialog" ansagen.
-->
<div role="dialog" aria-modal="true" aria-labelledby="dialog-title">
<h2 id="dialog-title">Einstellungen bearbeiten</h2>
<!-- ... Inhalt des Dialogs ... -->
<button>Speichern</button>
<button>Abbrechen</button>
</div>

Best Practices & Empfehlungen

Um aria-labelledby korrekt und effektiv einzusetzen, solltest Du einige Regeln beachten.

Bevorzuge immer native HTML-Lösungen

Die erste Regel der ARIA-Nutzung lautet:

Verwende native HTML-Elemente und -Attribute, wann immer es möglich ist [2].

Für Formularfelder ist <label for="id"> fast immer die bessere Wahl [3]. Es ist robuster, bietet eine größere Klickfläche und benötigt kein JavaScript, um zu funktionieren. Nutze aria-labelledby nur dann, wenn eine native Lösung nicht umsetzbar ist.

Stelle sicher, dass die referenzierten IDs gültig sind

Das aria-labelledby-Attribut ist nutzlos, wenn die ids, auf die es verweist, nicht im DOM existieren oder nicht einzigartig sind. Der Browser kann die Referenz nicht auflösen, und das Element erhält keinen Accessible Name. Automatische Tests und manuelle Prüfungen mit einem Screenreader sind hier unerlässlich.

Kombiniere mehrere IDs mit Bedacht

Wenn Du mehrere IDs referenzierst, werden deren Textinhalte in der angegebenen Reihenfolge mit einem Leerzeichen dazwischen verbunden. Teste das Ergebnis mit einem Screenreader, um sicherzustellen, dass die resultierende Beschriftung verständlich und natürlich klingt.

Kombination mehrerer Beschriftungselemente
<h3 id="form-heading">Kontaktformular</h3>
<!-- ... andere Felder ... -->
<label id="date-label">Geburtsdatum</label>
<span id="date-format" class="small-text">(TT.MM.JJJJ)</span>
<input type="text" aria-labelledby="form-heading date-label date-format" />
<!-- Screenreader sagt: "Kontaktformular Geburtsdatum (TT.MM.JJJJ), Eingabefeld" -->

Verwende aria-labelledby und aria-label nicht gleichzeitig

Gemäß der Spezifikation [4] zur Berechnung des Accessible Name hat aria-labelledby Vorrang vor aria-label. Wenn Du beide Attribute auf demselben Element platzierst, wird der Wert von aria-label ignoriert. Das kann zu Verwirrung bei der Wartung des Codes führen. Entscheide Dich für eine der beiden Methoden.

Häufige Missverständnisse

aria-labelledby ist dasselbe wie aria-describedby

Das ist ein weit verbreiteter Irrtum. Die beiden Attribute haben unterschiedliche Zwecke:

  • aria-labelledby liefert den Namen eines Elements (essentiell, die Identität). Es beantwortet die Frage: "Was ist das?"
  • aria-describedby liefert eine Beschreibung (ergänzend, zusätzliche Informationen). Es beantwortet die Frage: "Was muss ich sonst noch darüber wissen?"

Ein Screenreader liest den Namen in der Regel sofort vor, während die Beschreibung oft nach einer kurzen Pause oder auf Anforderung des Nutzers vorgelesen wird.

aria-labelledby ist ein universeller Ersatz für das <label>-Element

Nein, auf keinen Fall. Wie bereits erwähnt, ist <label> die semantisch korrekte und robustere Methode für Standard-Formularelemente. aria-labelledby ist eine Fallback-Lösung für komplexe UI-Komponenten und Situationen, in denen <label> nicht ausreicht oder nicht anwendbar ist.

Verwandte Begriffe

Häufig gestellte Fragen

Wann sollte ich aria-labelledby anstelle von aria-label verwenden?

Verwende aria-labelledby, wenn der Text für die Beschriftung bereits sichtbar auf der Seite vorhanden ist. Verwende aria-label, wenn es keine sichtbare Beschriftung gibt und Du einen reinen "Off-Screen"-Text für assistierende Technologien bereitstellen musst (z.B. für einen Button mit nur einem Icon).

Was passiert, wenn eine in aria-labelledby angegebene ID nicht existiert?

Wenn der Browser eine ID nicht finden kann, wird diese einfach ignoriert. Wenn alle referenzierten IDs ungültig sind, greift der Browser auf die nächste Methode in der Hierarchie zur Berechnung des Accessible Name zurück (z.B. den Textinhalt des Elements). Im schlimmsten Fall hat das Element keine zugängliche Beschriftung, was ein klares WCAG-Verstoß ist.

Kann ich aria-labelledby auf jedes HTML-Element anwenden?

Ja, aria-labelledby ist ein globales ARIA-Attribut und kann auf jedes HTML-Element angewendet werden. Sinnvoll ist es jedoch nur bei Elementen, die einen Accessible Name benötigen. Dazu gehören interaktive Elemente (wie button, input, a), Elemente mit einer Widget-Rolle (wie role="dialog", role="slider") und Landmark-Regionen (wie <nav> oder role="search").

Wie verketten Screenreader die Inhalte bei mehreren IDs?

Screenreader lesen die Textinhalte der Elemente in der Reihenfolge vor, in der ihre IDs im aria-labelledby-Attribut aufgelistet sind. Zwischen den einzelnen Teilen wird ein Leerzeichen eingefügt. aria-labelledby="id1 id2" führt zur Ausgabe "[Inhalt von id1] [Inhalt von id2]".

Hinweis

Dieser Artikel dient der Wissensvermittlung und stellt keine Rechtsberatung dar. Bei der Umsetzung von digitaler Barrierefreiheit sind stets die spezifischen gesetzlichen Anforderungen und Standards zu berücksichtigen.

  1. World Wide Web Consortium (W3C), „Accessible Rich Internet Applications (WAI-ARIA) 1.2“. 2023. [Online]. Verfügbar unter: https://www.w3.org/TR/wai-aria-1.2/
  2. W3C Web Accessibility Initiative (WAI), „W3C Using Aria: Erste Regel der ARIA-Nutzung“. 2018. [Online]. Verfügbar unter: https://www.w3.org/TR/using-aria/#firstrule
  3. W3C, „H44: Using label elements to associate text labels with form controls“, 2023, [Online]. Verfügbar unter: https://www.w3.org/WAI/WCAG22/Techniques/html/H44
  4. „Accessible Name and Description Computation 1.2“. W3C, Oktober 2025. Zugegriffen: 6. November 2025. [Online]. Verfügbar unter: https://www.w3.org/TR/accname-1.2/

Über den Autor

Porträtfoto von Dmitry Dugarev

Beste Grüße

Dmitry Dugarev

Gründer von Barrierenlos℠ und Entwickler des Semanticality™ Plugins. Mit einem Masterabschluss, über 8 Jahren Erfahrung in Web-Entwicklung & IT-Compliance bei Big-Four, Banken und Konzernen und mehr als 1.000 auf Barrierefreiheit geprüften Seiten für über 50 Kunden helfe ich Web-Teams, Barrierefreiheit planbar umzusetzen – ohne monatelange Umbauten.

Werde selbst zum BFSG-Profi-Entwickler. In nur 4 Tagen.

Lerne in unserem 4-Tage-Workshop, wie Du komplexe Audits selbst durchführst und barrierefreie Komponenten entwickelst. Erhalte einen individuellen Lernplan, 1:1-Strategie-Gespräch und ein Zertifikat.

Jetzt zum Workshop anmelden