Was ist aria-label? - Barrierefreie Beschriftungen für Elemente

Das aria-label Attribut ist eines der bekanntesten und gleichzeitig am häufigsten missverstandenen Werkzeuge in der Welt der digitalen Barrierefreiheit. Richtig eingesetzt, ist es unglaublich mächtig, um die User Experience für Nutzer von assistiven Technologien (AT) wie Screenreadern zu verbessern. Falsch eingesetzt, kann es jedoch mehr schaden als nutzen. Lass uns gemeinsam tief eintauchen und klären, wie Du aria-label korrekt und effektiv einsetzt.

Was ist aria-label?

Die offizielle Spezifikation definiert aria-label wie folgt:

Defines a string value that labels the current element. [1]

Auf Deutsch bedeutet das: Es definiert einen String-Wert (eine Zeichenkette), der das aktuelle Element beschriftet.

Ausführliche Erklärung

Stell Dir vor, Du hast ein interaktives Element, zum Beispiel einen Button, der nur ein Icon enthält – wie das klassische "X" zum Schließen eines Fensters. Ein sehender Nutzer erkennt die Funktion sofort. Aber was hört ein Nutzer, der einen Screenreader verwendet? Ohne weitere Informationen hört er vielleicht nur "Button". Das ist nicht hilfreich.

Hier kommt aria-label ins Spiel. Es versorgt dieses Element mit einem "barrierefreien Namen" (Accessible Name). Dieser Name ist für sehende Nutzer unsichtbar, wird aber von assistiven Technologien ausgelesen. Im Falle unseres "X"-Buttons würdest Du aria-label="Schließen" hinzufügen. Der Screenreader-Nutzer hört dann "Schließen, Button" – und weiß sofort, was passiert, wenn er ihn aktiviert.

Das Wichtigste, was Du verstehen musst: aria-label hat eine hohe Priorität und überschreibt jeglichen sichtbaren Textinhalt des Elements für assistive Technologien. Wenn ein Button den Text "Mehr erfahren" hat und Du ihm ein aria-label="Klicke hier" gibst, wird der Screenreader "Klicke hier" vorlesen, nicht "Mehr erfahren". Das kann zu großer Verwirrung führen.

Der barrierefreie Name wird nach einer festgelegten Hierarchie ermittelt, die in der "Accessible Name and Description Computation" Spezifikation [2] definiert ist. aria-label steht in dieser Hierarchie weit oben.

Vereinfachte Hierarchie der Berechnung des barrierefreien Namens

Textbeschreibung für das Schema "Vereinfachte Hierarchie der Berechnung des barrierefreien Namens"

Dieses Flussdiagramm zeigt den vereinfachten Prozess, wie assistive Technologien den Namen eines Elements bestimmen.

1. Zuerst wird geprüft, ob ein aria-labelledby Attribut vorhanden ist. Wenn ja, wird dessen Inhalt als Name verwendet.
2. Wenn nicht, wird geprüft, ob ein aria-label Attribut vorhanden ist. Wenn ja, wird dessen Wert als Name verwendet.
3. Wenn nicht, wird der sichtbare Textinhalt des Elements als Name verwendet.
4. Als letzte Möglichkeit wird das title Attribut als Fallback herangezogen.
5. Wenn keine dieser Methoden einen Namen liefert, hat das Element keinen barrierefreien Namen, was ein Accessibility-Problem darstellt. aria-label überschreibt also den sichtbaren Textinhalt.

Wofür wird es eingesetzt?

aria-label ist Dein Werkzeug der Wahl, wenn es keine sichtbare Beschriftung gibt oder die sichtbare Beschriftung nicht aussagekräftig genug ist.

Typische Anwendungsfälle sind:

• Icon-Buttons: Buttons, die nur ein Icon anzeigen (z. B. ein Zahnrad für "Einstellungen", eine Lupe für "Suche", ein "X" für "Schließen").
• Grafische Steuerelemente: Bedienelemente, deren Funktion rein visuell dargestellt wird.
• Eindeutige Benennung von Landmark-Regionen: Wenn Du mehrere Navigationselemente (<nav>) auf einer Seite hast, kannst Du sie unterscheiden, z.B. mit aria-label="Hauptnavigation" und aria-label="Seitennavigation".
• Klarstellung mehrdeutiger Links: Ein "Weiterlesen"-Link ist ohne Kontext unklar. Mit aria-label="Weiterlesen über unser neues Produkt" wird er für Screenreader-Nutzer verständlich. (Obwohl es hier oft bessere Techniken gibt!)

Hier ist ein kleiner Entscheidungsbaum, der Dir hilft:

Entscheidungsbaum zur Verwendung von `aria-label`

Textbeschreibung für das Schema "Entscheidungsbaum zur Verwendung von aria-label"

Dieses Diagramm hilft bei der Entscheidung, ob aria-label verwendet werden sollte. 1. Frage: Hat das Element eine sichtbare Beschriftung? 2. Wenn nein: aria-label ist eine ausgezeichnete Wahl. 3. Wenn ja, frage weiter: Ist die sichtbare Beschriftung ausreichend? 4. Wenn ja: aria-label wird nicht benötigt. 5. Wenn nein, frage weiter: Kann der sichtbare Text verbessert werden? 6. Wenn ja: Verbessere den sichtbaren Text. Das ist die bevorzugte Lösung. 7. Wenn nein: aria-label kann als letzte Option verwendet werden, um den Kontext zu ergänzen, aber es ist Vorsicht geboten.

Beispiele aus der Praxis

Gutes Beispiel

Icon-Button zum Schließen

<!--
  Gutes Beispiel:
  Ein Button ohne sichtbaren Text.
  aria-label gibt ihm einen barrierefreien Namen.
-->
<button aria-label="Dialog schließen">
  <svg aria-hidden="true" focusable="false" ...>
    <!-- Icon-Grafik hier -->
    <path
      d="M19 6.41L17.59 5 12 10.59 6.41 5 5 6.41 10.59 12 5 17.59 6.41 19 12 13.41 17.59 19 19 17.59 13.41 12z"
    ></path>
  </svg>
</button>

Schlechtes Beispiel

Button mit sichtbarem Text

<!--
  Schlechtes Beispiel:
  Dieser Button hat bereits sichtbaren Text ("Suchen").
  Das aria-label="Suche starten" überschreibt diesen Text.
  Das führt zu einer Inkonsistenz.
-->
<button aria-label="Suche starten">Suchen</button>

Das schlechte Beispiel erzeugt ein Problem:

• Ein Screenreader-Nutzer hört "Suche starten, Button".
• Ein Nutzer von Spracherkennungssoftware sagt vielleicht "Klicke Suchen", was fehlschlägt, da der barrierefreie Name "Suche starten" lautet.
• Ein sehender Screenreader-Nutzer ist verwirrt, weil er "Suchen" liest, aber "Suche starten" hört.

Best Practices & Empfehlungen

• Verwende aria-label nur, wenn es keine sichtbare Beschriftung gibt. Das ist die goldene Regel. Wenn Text vorhanden ist, ist es fast immer besser, diesen Text so zu gestalten, dass er aussagekräftig ist.
• Überschreibe niemals sichtbaren Text. Wenn ein Element sichtbaren Text hat, muss dieser Text Teil des barrierefreien Namens sein. Das ist eine direkte Anforderung des WCAG-Erfolgskriteriums 2.5.3 Label in Name. [3]
• Bevorzuge native HTML-Elemente. Für Formularfelder ist ein <label>-Element, das mit dem for-Attribut verknüpft ist, immer die bessere, robustere und semantisch korrektere Lösung als aria-label auf einem <input>. [4]
• Sei präzise und kurz. Der Inhalt von aria-label sollte wie eine echte, kurze Beschriftung sein, nicht wie ein Roman. Für längere Beschreibungen gibt es aria-describedby.
• Verwende es nicht auf statischen Elementen wie <div> oder <span>, es sei denn, sie haben eine spezifische ARIA-Rolle (z.B. role="navigation" oder role="region"), die eine Beschriftung erfordert. Ein aria-label auf einem simplen <div> ohne Rolle wird von den meisten Screenreadern ignoriert.
• Teste Deine Implementierung! Nichts ersetzt das Testen mit einem echten Screenreader (NVDA, VoiceOver, JAWS). So stellst Du sicher, dass die User Experience wirklich so ist, wie Du sie Dir vorstellst.

Häufige Missverständnisse

aria-label ist wie ein Tooltip

Das ist falsch. Das title-Attribut in HTML erzeugt einen Tooltip, der bei Maus-Hover erscheint. aria-label erzeugt keinerlei visuelle Ausgabe. Es ist ausschließlich für die API-Kommunikation mit assistiven Technologien gedacht. Während das title-Attribut manchmal als letzter Fallback für den barrierefreien Namen dient, ist es notorisch unzuverlässig und für mobile oder tastaturgesteuerte Nutzer oft gar nicht zugänglich. Verwechsle die beiden also nicht.

aria-label ist für lange Erklärungen gedacht

Nein, dafür ist es nicht geeignet. aria-label soll eine kurze, prägnante Beschriftung sein (der "Name"). Wenn Du zusätzliche Informationen oder Anweisungen geben möchtest (die "Beschreibung"), ist aria-describedby das richtige Werkzeug. Es verknüpft ein Element mit einem anderen Element auf der Seite, dessen Inhalt dann als Beschreibung vorgelesen wird.

Verwandte Begriffe

• Accessible Name
• aria-labelledby
• aria-describedby
• role (Attribut)
• WAI-ARIA

Häufig gestellte Fragen

Was ist der Unterschied zwischen aria-label und aria-labelledby?

aria-label verwendet einen einfachen String als Beschriftung, den Du direkt in das Attribut schreibst. aria-labelledby ist mächtiger: Es verwendet die id eines oder mehrerer anderer Elemente auf der Seite, um deren Inhalt als Beschriftung zu verketten. aria-labelledby hat Vorrang vor aria-label und ist oft die bessere Wahl, wenn die Beschriftung bereits als sichtbarer Text auf der Seite existiert.

Wann sollte ich aria-label NICHT verwenden?

Du solltest aria-label nicht verwenden, wenn ein Element bereits eine sichtbare und aussagekräftige Textbeschriftung hat. Außerdem solltest Du es nicht auf generischen, nicht-interaktiven Elementen wie <div>, <p> oder <span> ohne eine passende ARIA-Rolle verwenden, da es dort oft ignoriert wird.

Wirkt sich aria-label auf die SEO aus?

Nein, aria-label hat in der Regel keinen direkten Einfluss auf die Suchmaschinenoptimierung (SEO). Suchmaschinen-Crawler konzentrieren sich auf den sichtbaren Inhalt und die semantische Struktur des DOM. aria-label ist für die User Experience von AT-Nutzern gedacht, nicht für Suchmaschinen.

Können alle HTML-Elemente ein aria-label haben?

Technisch gesehen kannst Du das Attribut auf fast jedes HTML-Element setzen. Sinnvoll und wirksam ist es aber nur auf Elementen, die eine Beschriftung benötigen. Das sind in der Regel interaktive Elemente (wie button, a, input), Elemente mit einer Landmark-Rolle (wie nav, main) oder Widgets mit einer ARIA-Rolle (wie tab, dialog).

Hinweis

Die in diesem Artikel enthaltenen Informationen, insbesondere Bezüge auf gesetzliche Regelungen oder Normen wie die WCAG, dienen ausschließlich der allgemeinen Information und stellen keine Rechtsberatung dar. Bei spezifischen rechtlichen Fragen zur digitalen Barrierefreiheit solltest Du immer einen qualifizierten Anwalt konsultieren.

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. „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/ ⤴
3. W3C, „Success Criterion 2.5.3 Label in Name“, 2023, [Online]. Verfügbar unter: https://www.w3.org/TR/WCAG22/#label-in-name ⤴
4. 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 ⤴