Auf dieser Seite
aria-label hilft, wenn ein Element einen Namen braucht und kein sichtbarer Text ihn liefern kann, etwa ein Button, der nur ein Symbol zeigt. Es schadet, wenn es sichtbaren Text überschreibt, wenn es auf Elementen steht, deren Rolle keinen Namen erlaubt, oder wenn es nicht zu dem passt, was auf dem Bildschirm steht.
Dieser Beitrag richtet sich an Entwicklerinnen und Entwickler im Frontend. Die technischen Aussagen stammen aus Dokumenten des W3C, die wir am 12.11.2026 gelesen haben. Ob eine Quelle verbindlich formuliert ist (Spezifikation, Empfehlung des W3C) oder nur ein Leitfaden, steht jeweils dabei.
Was macht aria-label?
aria-label setzt den zugänglichen Namen eines Elements aus einem Text, den der Bildschirm nicht anzeigt. Der Browser übernimmt diesen Text als Namen, statt ihn aus dem Inhalt zu berechnen. Ein Screenreader liest ihn vor.
Die WAI-ARIA-Spezifikation 1.2 (W3C Recommendation vom 6. Juni 2023) definiert das Attribut so:
"Defines a string value that labels the current element."
(WAI-ARIA 1.2, Abschnitt „aria-label“)
Der Name erscheint nicht auf dem Bildschirm. Wer ohne Hilfstechnik arbeitet, sieht ihn nie. Das ist der Grund, warum die folgenden Abschnitte so streng mit dem Attribut umgehen.
Für die WCAG 2.1 zählt der Name unter 4.1.2 Name, Rolle, Wert (Stufe A): Bei allen Bedienelementen müssen Name und Rolle programmatisch ermittelbar sein ("the name and role can be programmatically determined", WCAG 2.1, Erfolgskriterium 4.1.2). Ein Button ohne Namen verfehlt dieses Kriterium. aria-label ist eine Möglichkeit, den Namen zu setzen, aber nicht die erste.
<button type="button" aria-label="Schließen">×</button>Wann ist aria-label die richtige Wahl?
aria-label ist richtig, wenn der Name nicht aus sichtbarem Text kommen kann oder soll. Typische Fälle sind ein Button mit reinem Symbol, mehrere gleichartige Navigationsbereiche auf einer Seite und Teilfelder, deren gemeinsame Beschriftung sichtbar an einer Gruppe steht.
Das W3C beschreibt in der Technik ARIA14 genau diesen Fall: "When no clear visible text label is available due to design decisions, the accessible name can be set by using the aria-label attribute instead, provided that the element has an implicit or explicit role that supports naming." (WCAG 2.1 Techniques, ARIA14). Techniken sind Beispiele und keine Pflicht. Die Seite sagt das selbst und nennt Techniken "Examples of ways to meet WCAG; not required".
Button mit Symbol. Der Name gehört an den Button, das Icon bleibt für Hilfstechnik unsichtbar:
<button type="button" aria-label="Warenkorb">
<svg aria-hidden="true" width="24" height="24">...</svg>
</button>Mehrere Navigationsbereiche. Der Leitfaden APG (ARIA Authoring Practices Guide, ein Leitfaden und keine Norm) rät für Landmarks: "If a specific landmark role is used more than once on a page, provide each instance of that landmark with a unique label." (APG, Landmark Regions). Im APG-Abschnitt zu Namen und Beschreibungen heißt eine Navigation "Product" und wird etwa als "Product navigation region" angesagt. Das Wort „Navigation“ fügt die Hilfstechnik selbst hinzu; der Leitfaden rät ausdrücklich davon ab, es in den Namen zu schreiben:
<nav aria-label="Hauptmenü">...</nav>
<nav aria-label="Fußzeile">...</nav>Teilfelder ohne eigenen Text. In einem Beispiel zu ARIA14 besteht eine Telefonnummer aus mehreren Feldern: Die Gruppe hat eine sichtbare Beschriftung, die einzelnen Felder bekommen einen kurzen Namen wie "area code".
Wann sind sichtbarer Text oder natives HTML besser?
Sobald ein sichtbarer Text den Namen liefern kann, ist er besser. Die ARIA-Spezifikation sagt das ausdrücklich:
"If the label text is available in the DOM (i.e. typically visible text content), authors SHOULD use aria-labelledby and SHOULD NOT use aria-label."
(WAI-ARIA 1.2, Abschnitt „aria-label“)
Der APG-Leitfaden nennt zwei Gründe. Erstens: "When a user interface includes visible text that could be used to provide an appropriate accessible name, using the visible text for the accessible name simplifies maintenance, prevents bugs, and reduces language translation requirements." Zweitens: "In HTML documents, whenever possible, rely on HTML naming techniques, such as the HTML label element for form elements and caption element for tables." (APG, Providing Accessible Names and Descriptions, Rule 2 und Rule 3).
Für Formulare heißt das: label mit for. Der APG-Leitfaden nennt dafür einen Vorteil, den aria-label nicht bietet: "browsers automatically make clicking the label equivalent to clicking the form control." Die Klickfläche des Feldes wird größer.
<!-- besser: sichtbares Label -->
<label for="plz">Postleitzahl</label>
<input id="plz" name="plz" autocomplete="postal-code">
<!-- schlechter: Name ohne sichtbaren Text -->
<input id="plz2" name="plz2" aria-label="Postleitzahl">Hat ein Eingabefeld kein dauerhaft sichtbares Label, lautet die Empfehlung des APG: "consider adjusting the design to include one." Auch für Bedienelemente gilt: Nehmen Sie das native Element. Ein div mit role="button" ist laut APG "a promise that the author of that <div> has also incorporated JavaScript that provides the keyboard interactions expected for a button." Ein button bringt Tastaturbedienung und Fokus mit.
aria-label, aria-labelledby oder aria-describedby?
aria-label und aria-labelledby setzen den Namen eines Elements, aria-describedby ergänzt eine Beschreibung. Der Unterschied zwischen den beiden Namensattributen liegt in der Quelle: aria-label nimmt einen Text aus dem Attribut, aria-labelledby verweist auf vorhandene Elemente.
| Attribut | Liefert | Quelle des Textes | Wann verwenden |
|---|---|---|---|
aria-label | Namen | Attributwert, nicht sichtbar | Es gibt keinen sichtbaren Text, der als Name dienen könnte |
aria-labelledby | Namen | Text anderer Elemente per ID, auch versteckter | Sichtbarer Text ist vorhanden, oder der Name besteht aus mehreren Teilen |
aria-describedby | Beschreibung | Text anderer Elemente per ID | Zusätzliche Hinweise zu einem Element, das schon einen Namen hat |
Drei Regeln aus den W3C-Dokumenten helfen bei der Wahl:
- Vorrang. "user agents give precedence to aria-labelledby over aria-label when computing the accessible name property" (WAI-ARIA 1.2). Setzen Sie beide, gewinnt aria-labelledby.
- Kurz oder ausführlich. "a label should be concise, where a description is intended to provide more verbose information." (WAI-ARIA 1.2, Abschnitt „aria-labelledby“). Lange Hinweise gehören in die Beschreibung, nicht in den Namen.
- Versteckte Quellen. Laut APG nimmt aria-labelledby Inhalt "regardless of their visibility" auf, auch von Elementen mit
hiddenoderdisplay: none. aria-labelledby lässt sich nicht verketten: Verweist ein referenziertes Element selbst per aria-labelledby weiter, wird das ignoriert.
aria-labelledby kann Text zusammensetzen. Im APG-Beispiel besteht der Name eines Links aus seinem eigenen Text und der Überschrift darüber. Hier mit href, damit der Link bedienbar ist:
<h2 id="t1">Sieben Wege, Bienen zu helfen</h2>
<a id="l1" href="/bienen" aria-labelledby="l1 t1">Mehr lesen</a>Der Name lautet „Mehr lesen Sieben Wege, Bienen zu helfen“. Der Link ist damit auch aus einer Linkliste heraus verständlich (WCAG 2.4.4, Linkzweck im Kontext).
aria-describedby setzt keinen Namen, sondern hängt eine Beschreibung an. Die Spezifikation sagt: "The element or elements referenced by the aria-describedby comprise the entire description." (WAI-ARIA 1.2, Abschnitt „aria-describedby“).
<label for="pw">Passwort</label>
<input id="pw" type="password" aria-describedby="pw-hinweis">
<p id="pw-hinweis">Wählen Sie ein Passwort, das Sie nirgends sonst nutzen.</p>Welche typischen Fehler gibt es?
Fünf Fehler benennen die W3C-Dokumente selbst: aria-label auf Elementen, die keinen Namen tragen dürfen, aria-label über sichtbarem Inhalt, Namen ohne den sichtbaren Text, nicht übersetzte Werte und zu lange Namen.
1. aria-label auf Elementen ohne Namensrolle. In ARIA in HTML (W3C Recommendation) steht als Pflicht: "Authors MUST NOT specify aria-label or aria-labelledby on elements with implicit WAI-ARIA roles which cannot be named." Das Dokument zeigt dazu p, span, code und ein div ohne Rolle als Beispiele dafür, was man nicht tun soll. ARIA 1.2 nennt die Rollen, die keinen Namen tragen dürfen: caption, code, deletion, emphasis, generic, insertion, paragraph, presentation, strong, subscript und superscript. Ein <div aria-label="Preisbereich"> ist deshalb unzulässig. Geben Sie dem Element eine passende Rolle, oder lassen Sie das Attribut weg.
2. aria-label über sichtbarem Inhalt. Der APG-Leitfaden warnt: "When applied to an element with one of the roles that supports naming from child content, aria-label hides descendant content from assistive technology users and replaces it with the value of aria-label." Zu diesen Rollen zählen unter anderem button, link, heading, checkbox und tab. Auf einem Link ersetzt aria-label also den sichtbaren Linktext:
<!-- Screenreader sagen nur "Mehr" an, nicht den Linktext -->
<a href="/preise" aria-label="Mehr">Alle Preise ansehen</a>3. Name enthält den sichtbaren Text nicht. WCAG 2.5.3 Beschriftung (Label) im Namen (Stufe A) verlangt: "For user interface components with labels that include text or images of text, the name contains the text that is presented visually." Wer eine Sprachsteuerung nutzt, spricht den sichtbaren Text aus. Zeigt ein Button „Suchen“ und heißt „Produkte finden“, scheitert der Befehl „Suchen“. Ein Name wie „Suchen: Produkte im Shop“ erfüllt das Kriterium.
4. Nicht übersetzte Werte. Der APG-Leitfaden sagt: "When a user interface is translated into multiple languages, ensure that aria-label values are translated." Sichtbarer Text als Quelle des Namens senkt laut APG den Übersetzungsaufwand ("reduces language translation requirements", Rule 2).
5. Lange Namen. Der APG-Leitfaden nennt als Regel: "Compose Brief, Useful Names". Ein Name soll sagen, was das Element ist. Alles Weitere gehört in aria-describedby.
Wie prüfen Sie aria-label?
Prüfen Sie jeden Namen zweimal: im Zugänglichkeitsbaum der Browser-Entwicklertools und anschließend mit einem Screenreader. Der APG-Leitfaden begründet das so: "Because the value of aria-label is not rendered visually, testing with assistive technologies to ensure the expected name is presented to users is particularly important."
Ein Scan deckt einen Teil ab. Unser Scanner nutzt axe-core. Regeln wie aria-prohibited-attr, button-name, link-name und label-content-name-mismatch erkennen unzulässige, fehlende oder nicht zum sichtbaren Text passende Namen. Ob ein vorhandener Name verständlich und zutreffend ist, kann kein Scan entscheiden. Automatisierte Tests erfassen grob 30 bis 40 Prozent der WCAG-Erfolgskriterien. Den Rest muss ein Mensch prüfen.
Der kostenlose Barrierefreiheitstest prüft die Startseite automatisiert. Eine vollständige Liste prüfbarer Punkte mit WCAG-Kriterium bietet die Checkliste für barrierefreies Webdesign. Gute und schlechte Umsetzungen aus der Praxis zeigen die zehn Muster, vorher und nachher.
Quellen, gelesen am 12.11.2026: WAI-ARIA 1.2 (W3C Recommendation, 6. Juni 2023), ARIA in HTML (W3C Recommendation), WCAG 2.1 mit Understanding-Dokument zu 2.5.3 und Technik ARIA14, APG-Seiten "Providing Accessible Names and Descriptions", "Landmark Regions" und "Read Me First" (Leitfaden). Rechtliche Aussagen enthält dieser Beitrag nicht. Prüfen Sie die aktuellen Fassungen, bevor Sie handeln.
Sehen Sie, wo Ihre Website steht
Der kostenlose Scan prüft eine Seite gegen die automatisierten Regeln der WCAG 2.1 AA und zeigt die ersten Ergebnisse.
Dieser Artikel dient der Orientierung und stellt keine Rechtsberatung dar.