Was ist ein ARIA-Label in HTML?

Ein ARIA-Label (aria-label) ist ein HTML-Attribut der WAI-ARIA-Spezifikation. Es weist einem Element einen zugänglichen Namen zu, der von Screenreadern und assistiven Technologien vorgelesen wird – auch wenn kein sichtbarer Text vorhanden ist.

Wann sollte aria-label verwendet werden?

aria-label wird verwendet, wenn ein interaktives Element keinen sichtbaren Textnamen besitzt – zum Beispiel bei Icon-Buttons, verlinkten Grafiken oder Formularfeldern ohne Label-Element. Für Elemente mit sichtbarem, aussagekräftigem Text ist aria-label in der Regel nicht notwendig.

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

aria-label enthält den zugänglichen Namen direkt als Textwert. aria-labelledby referenziert über eine ID ein anderes Element im DOM, dessen sichtbarer Text als Name dient. aria-labelledby hat eine höhere Priorität als aria-label und ist bevorzugt einzusetzen, wenn passender Text bereits sichtbar vorhanden ist.

Funktioniert aria-label bei allen HTML-Elementen?

Nein. aria-label ist nur wirksam bei Elementen, die in der Accessibility-Baumstruktur einen Namen unterstützen – also bei interaktiven Elementen wie Buttons, Links und Formularfeldern sowie bei Elementen mit expliziten ARIA-Rollen. Auf generischen Elementen wie div oder span ohne Rolle hat aria-label keinen Effekt.

Ist aria-label für die WCAG-Konformität erforderlich?

In vielen Fällen ja. WCAG 2.1 Erfolgskriterium 4.1.2 fordert, dass alle Benutzeroberflächenkomponenten einen programmatisch bestimmbaren Namen haben. Fehlt dieser Name bei einem interaktiven Element – etwa bei einem Icon-Button ohne Label – liegt ein WCAG-Verstoß vor, der unter das BFSG fällt.

ARIA-Label

16.06.2026

Drucken

ARIA-Label – Zugängliche Namen für Screenreader und assistive Technologien

ARIA-Label (aria-label) ist ein HTML-Attribut der WAI-ARIA-Spezifikation, das interaktiven Elementen einen zugänglichen Namen zuweist – unabhängig davon, ob sichtbarer Text vorhanden ist. Screenreader und andere assistive Technologien lesen diesen Wert vor, sobald ein Nutzer das Element fokussiert, und ermöglichen so eine vollständige Navigation ohne visuelle Wahrnehmung.

Das Attribut ist besonders wichtig für Buttons mit ausschließlich einem Icon, verlinkte Grafiken und Formularfelder ohne sichtbare Beschriftung. In diesen Fällen liefert aria-label die einzige Information über Funktion und Zweck des Elements für Benutzer assistiver Technologien – und ist damit ein zentrales Werkzeug für digitale Barrierefreiheit im gesamten Internet.

Seit dem 28. Juni 2025 verpflichtet das Barrierefreiheitsstärkungsgesetz (BFSG) – die deutsche Umsetzung des European Accessibility Act (EAA) – Unternehmen zur WCAG 2.1 Level AA-Konformität. Fehlendes aria-label bei interaktiven Elementen verstößt direkt gegen WCAG-Kriterium 4.1.2 (Name, Rolle, Wert) und kann zu Abmahnungen führen.

ARIA-Label auf einen Blick

✓ Definition: HTML-Attribut der WAI-ARIA-Spezifikation – weist Elementen einen zugänglichen Namen zu, der von Screenreadern vorgelesen wird
✓ Typischer Einsatz: Icon-Buttons, verlinkte Grafiken, Formularfelder und interaktive Controls ohne sichtbaren Text
✓ Screenreader-Verhalten: Der aria-label-Wert ersetzt den sichtbaren Elementinhalt als vorgelesenen Namen im Accessibility-Baum
✓ Varianten: aria-labelledby referenziert vorhandenen Text per ID (höhere Priorität); aria-describedby liefert ergänzende Beschreibungen
✓ WCAG-Relevanz: Pflichterfordernis laut WCAG 2.1 Kriterium 4.1.2 – unmittelbar relevant für BFSG- und EAA-Konformität

Was ist ein ARIA-Label? – Definition und Grundlagen

ARIA steht für Accessible Rich Internet Applications – ein Standard des W3C zur Verbesserung der Zugänglichkeit von Webinhalten für assistive Technologien. Das Attribut aria-label ist eines der grundlegendsten Werkzeuge dieser Spezifikation: Es weist einem HTML-Element direkt einen zugänglichen Namen zu, der ausschließlich für Hilfsmitteltechnologien bestimmt ist und nicht visuell dargestellt wird.

Der Wert des Attributs ist ein einfacher Textstring. Screenreader lesen diesen Wert vor, wenn der Benutzer das Element fokussiert. Beispiel: Ein Button mit einem Papierkorb-Icon ohne sichtbaren Text erhält aria-label="Eintrag löschen". Der Screenreader gibt dann „Eintrag löschen, Schaltfläche" aus – vollständige Information für Nutzer ohne Sehvermögen.

Wichtig: aria-label sollte nur eingesetzt werden, wenn kein natives HTML-Element oder kein sichtbarer Text die Funktion bereits ausreichend beschreibt. Semantisches HTML wie <button> mit Textinhalt ist immer vorzuziehen. ARIA schließt Lücken, die natives HTML nicht schließen kann – es ist kein Ersatz für semantische Grundstruktur.

Screenreader und ARIA-Roles: Wie der Accessibility-Baum funktioniert

Wenn ein Screenreader eine Seite analysiert, baut er eine Accessibility-Baumstruktur auf – eine vereinfachte Repräsentation des DOM mit barrierefreiheitsrelevanten Informationen. Jedes Element hat dort einen Namen, eine Rolle und optional einen Wert. Das aria-label-Attribut beeinflusst direkt den „Name"-Eintrag eines Elements in diesem Baum.

Die Priorität bei der Berechnung des zugänglichen Namens ist durch die W3C-Spezifikation klar festgelegt:

✓ 1. Priorität: aria-labelledby – referenziert sichtbaren Text per id-Attribut
✓ 2. Priorität: aria-label – direkter Textwert im Attribut
✓ 3. Priorität: Nativer Name aus HTML-Elementinhalt, title-Attribut oder verknüpftem <label>
✓ Kein Name vorhanden: WCAG 4.1.2-Verstoß – Nutzer von Screenreadern erhalten keine verwertbare Information

ARIA-Roles definieren, welche Art von Element vorliegt – role="button", role="img", role="dialog" – und bestimmen, welche ARIA-Attribute erlaubt sind. aria-label ist bei den meisten interaktiven Roles zulässig und wird von allen gängigen Screenreadern und assistiven Technologien korrekt verarbeitet.

aria-label, aria-labelledby und aria-describedby im Vergleich

Diese drei ARIA-Attribute werden häufig verwechselt, erfüllen aber klar unterschiedliche Aufgaben:

✓ aria-label: Weist einen zugänglichen Namen direkt als Textwert zu. Einsatz: kein geeigneter sichtbarer Text im Element vorhanden.
✓ aria-labelledby: Referenziert über eine id ein anderes Element als Namensquelle. Hat Vorrang vor aria-label – bevorzugt, wenn passender Text bereits sichtbar existiert.
✓ aria-describedby: Liefert eine ergänzende Beschreibung, keinen Namen. Der Screenreader liest die Beschreibung nach dem Namen vor – geeignet für Fehlermeldungen, Formathinweise oder Zusatzinformationen.

Ein konkretes Beispiel: Ein Suchfeld erhält den Namen via aria-labelledby="search-heading", das auf eine sichtbare Überschrift zeigt. Zusätzlich gibt aria-describedby="search-hint" einen Hinweis auf das erwartete Eingabeformat. Die id-Vergabe ist dabei entscheidend – ohne eindeutige, korrekte IDs funktioniert aria-labelledby nicht. Entwickler sollten IDs niemals mehrfach vergeben.

Praktische Anwendungsfälle: Button, Icon, Grafik und Formular

Die häufigsten Einsatzszenarien für aria-label in der Entwicklungspraxis:

✓ Icon-Button: <button aria-label="Menü schließen"><svg ...></svg></button> – der Button enthält nur ein Icon, kein sichtbares Label
✓ Verlinkte Grafik: <a href="/" aria-label="Zur Startseite"><img src="logo.svg" alt=""></a> – wenn das Logo bereits ein leeres alt-Attribut trägt
✓ Suchfeld ohne Label: <input type="search" aria-label="Website durchsuchen"> – kein sichtbares <label>-Element vorhanden
✓ SVG-Grafik mit Rolle: <div role="img" aria-label="Balkendiagramm: Umsatz Q1–Q4 2024"> – für komplexe CSS- oder SVG-basierte Grafiken ohne natives <img>-Element

Für Entwickler gilt als Grundregel: Natives HTML mit sichtbarem Text hat immer Vorrang. aria-label ist die Lösung für den Fall, dass semantische HTML-Elemente allein nicht ausreichen. Konsequent eingesetzt, verbessert es die Accessibility jeder Website messbar – und sichert WCAG-Konformität nach BFSG und EAA.

SiteCockpit Lösung

easyMonitoring erkennt fehlende ARIA-Labels automatisch

Fehlende oder leere aria-label-Attribute gehören zu den häufigsten WCAG-Verstößen – und bleiben ohne systematisches Monitoring oft unentdeckt. easyMonitoring scannt deine Website automatisch auf interaktive Elemente ohne zugänglichen Namen: Icon-Buttons ohne Label, Formularfelder ohne Beschriftung, verlinkte Grafiken ohne zugänglichen Text. Jeder Fund wird nach WCAG-Kriterium kategorisiert, mit Schweregrad bewertet und direkt im Dashboard angezeigt – mit Quellenangabe zur betroffenen Stelle im Code.

So erkennst du ARIA-Lücken unmittelbar nach dem Deployment – bevor sie zu BFSG-Abmahnungen werden.

easyMonitoring kennenlernen →

Häufige Fragen zu ARIA-Label

Kann aria-label sichtbaren Text ersetzen?

Technisch ja – aber nicht empfehlenswert. Wenn aria-label und sichtbarer Text inhaltlich abweichen, können Nutzer mit Spracheingabe-Software Probleme haben: Sprachbefehle müssen dem sichtbaren Text entsprechen. Der zugängliche Name sollte den sichtbaren Text enthalten oder mit ihm übereinstimmen.

Muss ich aria-label bei jedem Button setzen?

Nein. Buttons mit sichtbarem, aussagekräftigem Text brauchen kein aria-label – der Textinhalt wird automatisch als zugänglicher Name verwendet. Das Attribut ist nur notwendig, wenn der Button keinen sichtbaren Text enthält oder der Text den Zweck allein nicht klar beschreibt.

Wie teste ich, ob mein aria-label korrekt funktioniert?

Am zuverlässigsten mit einem echten Screenreader wie NVDA, JAWS oder VoiceOver. Alternativ zeigt der Accessibility-Tab in den Chrome DevTools den berechneten Namen im Accessibility-Baum. Automatisierte Tools wie easyMonitoring erfassen WCAG-Verstöße durch fehlende Namen systemübergreifend über alle Seiten.

Gilt aria-label auch für ARIA-Rollen wie role="img"?

Ja. Wird einem Element eine ARIA-Rolle zugewiesen, die einen Namen unterstützt – wie role="img", role="dialog" oder role="region" – muss immer ein zugänglicher Name gesetzt werden, entweder via aria-label oder aria-labelledby. Fehlt er, ist das Element für Screenreader-Nutzer nicht eindeutig identifizierbar.

ARIA-Labels auf deiner Website korrekt eingesetzt?

Fehlende zugängliche Namen gehören zu den häufigsten, aber unsichtbarsten WCAG-Barrieren – ohne Screenreader kaum zu entdecken. Mit easyMonitoring prüfst du deine gesamte Website automatisch auf ARIA-Lücken und WCAG-Verstöße – und erfüllst die Anforderungen des BFSG nachweislich.