ARIA Labels gehoeren zu den am meisten missverstandenen Werkzeugen der Web-Barrierefreiheit. Der Reflex vieler Entwickler ist, aria-label zu verwenden, sobald ein Element einen barrierefreien Namen braucht. In vielen Faellen verursacht dieser Reflex mehr Probleme als er loest. Laut der jaehrlichen WebAIM-Analyse weisen Seiten mit ARIA durchschnittlich 41 Prozent mehr erkannte Barrierefreiheitsfehler auf als Seiten ohne ARIA. Diese Statistik spricht nicht gegen ARIA. Sie belegt, dass die meisten Entwickler ARIA falsch einsetzen. Dieser Leitfaden behandelt jedes ARIA-Labeling-Attribut, erklaert, wann welches die richtige Wahl ist, zeigt Fehler auf, die selbst erfahrene Entwickler machen, und liefert Code-Patterns, die Sie sofort anwenden koennen. Ob Sie eine bestehende Website fuer das BFSG (Barrierefreiheitsstaerkungsgesetz) nachruesten oder eine neue Anwendung von Grund auf bauen, die korrekte Verwendung von ARIA Labels ist grundlegend fuer jedes WCAG 2.2 Audit.
Was ARIA Labels tatsaechlich tun (und was nicht)
ARIA steht fuer Accessible Rich Internet Applications. Die WAI-ARIA-Spezifikation des W3C stellt Attribute bereit, die aendern, wie Elemente im Barrierefreiheitsbaum des Browsers erscheinen. Diesen Baum nutzen Screenreader, Sprachsteuerungssoftware und andere assistive Technologien.
Ein ARIA Label gibt einem Element seinen barrierefreien Namen. Wenn ein Screenreader auf einen Button trifft, kuendigt er diesen Namen an, damit der Nutzer weiss, was der Button tut. Ist der Name falsch, fehlend oder verwirrend, kann der Nutzer die Oberflaeche nicht bedienen.
Drei Attribute erledigen den Grossteil der ARIA-Labeling-Arbeit: aria-label, aria-labelledby und aria-describedby. Jedes verhaelt sich anders, und die falsche Wahl ist einer der haeufigsten Barrierefreiheitsfehler, die unser Checker auf tausenden gescannten Websites erkennt.
Wichtig: ARIA Labels aendern nichts am visuellen Erscheinungsbild. Ein aria-label auf einem Button fuegt keinen sichtbaren Text hinzu. Es aendert nur, was assistive Technologie ankuendigt. Sehende Nutzer und Screenreader-Nutzer koennen voellig unterschiedliche Interfaces wahrnehmen, wenn ARIA sorglos eingesetzt wird.
Die fuenf ARIA-Regeln, die Sie kennen muessen
Bevor wir in die einzelnen Attribute eintauchen, gelten diese fuenf W3C-Regeln fuer jede ARIA-Nutzung. Verstossen Sie gegen eine davon, riskieren Sie, Ihre Oberflaeche weniger barrierefrei zu machen.
Regel eins: Wenn Sie ein natives HTML-Element mit der benoetigten Semantik und dem benoetigten Verhalten verwenden koennen, tun Sie das statt ARIA hinzuzufuegen. Ein nativer button hat bereits die implizite Rolle, reagiert auf Tastaturereignisse und bezieht seinen barrierefreien Namen aus seinem Textinhalt. Ein div mit role button und aria-label erfordert, dass Sie all das manuell replizieren.
Regel zwei: Aendern Sie keine native Semantik ohne triftigen Grund. role presentation auf einer Ueberschrift entfernt deren Semantik aus dem Barrierefreiheitsbaum.
Regel drei: Alle interaktiven ARIA-Steuerelemente muessen mit der Tastatur bedienbar sein. Erstellen Sie eine benutzerdefinierte Checkbox mit role checkbox, muessen Sie auch Leertaste-Umschaltung, Fokusverwaltung und den aria-checked-Status implementieren.
Regel vier: Verwenden Sie nicht role presentation oder aria-hidden true auf einem fokussierbaren Element. Ein Element, das Tastaturfokus empfangen kann, aber im Barrierefreiheitsbaum versteckt ist, erzeugt ein Phantom-Steuerelement.
Regel fuenf: Jedes interaktive Element muss einen barrierefreien Namen haben.
aria-label: Wann und wie korrekt verwenden
Das aria-label-Attribut liefert einen Textstring als barrierefreien Namen fuer ein Element. Screenreader kuendigen diesen String statt anderem Textinhalt an.
Verwenden Sie aria-label, wenn ein interaktives Element keinen sichtbaren Text hat und kein anderer Mechanismus einen barrierefreien Namen liefert. Das klassische Beispiel ist der Icon-Button. Ein Schliessen-Button, der nur ein X-Icon oder SVG enthaelt, braucht aria-label="Schliessen".
Weiterer gueltiger Anwendungsfall: Wiederholte Navigationslandmarks unterscheiden. Hat Ihre Seite zwei nav-Elemente, koennen aria-label="Hauptnavigation" und aria-label="Breadcrumb" Screenreader-Nutzern helfen.
Hier machen Entwickler Fehler. Verwenden Sie aria-label nicht auf Elementen mit sichtbarem Text. Unter WCAG 2.2 Erfolgskriterium 2.5.3 Beschriftung im barrierefreien Namen muss der barrierefreie Name den sichtbaren Text enthalten. Sprachsteuerungsnutzer, die auf Absenden klicken sagen, koennen einen Button nicht aktivieren, dessen barrierefreier Name Formular absenden lautet.
Kritische Einschraenkung: aria-label wird von Browser-Uebersetzungstools nicht uebersetzt. Chrome, Edge und Firefox ueberspringen alle aria-label-Werte bei der Seitenübersetzung. Das ist besonders relevant in Deutschland, wo das BFSG (Barrierefreiheitsstaerkungsgesetz) seit Juni 2025 in Kraft ist und Bussgelder bis zu 100.000 Euro vorsieht. Fuer mehrsprachige Websites verwenden Sie sichtbaren Text oder aria-labelledby.
aria-labelledby: Die bevorzugte Alternative
Das aria-labelledby-Attribut setzt den barrierefreien Namen, indem es die id eines oder mehrerer Elemente referenziert. Es ist robuster als aria-label aus mehreren Gruenden.
Erstens: Da aria-labelledby sichtbaren Text auf der Seite referenziert, uebersetzen Browser-Uebersetzungstools den referenzierten Text. Screenreader-Nutzer erhalten automatisch einen uebersetzten barrierefreien Namen.
Zweitens: aria-labelledby synchronisiert sichtbaren Text und barrierefreie Namen automatisch. Aendert jemand den sichtbaren Ueberschriftentext, aktualisiert sich der barrierefreie Name mit.
Drittens: aria-labelledby kann Text aus mehreren Elementen verketten, indem mehrere IDs durch Leerzeichen getrennt aufgelistet werden.
Verwenden Sie aria-labelledby, wenn bereits sichtbarer Text existiert, der als barrierefreier Name dienen koennte. Gaengige Patterns sind die Beschriftung von Abschnitten mit ihren Ueberschriften, von Modaldialogen mit ihrem Titel und von Formulargruppen.
Wichtiges Prioritaetsverhalten: aria-labelledby hat Vorrang vor aria-label und nativen Mechanismen wie dem label-Element. Verwenden Sie nur einen Beschriftungsmechanismus pro Element.
aria-describedby: Kontext hinzufuegen, ohne den Namen zu aendern
Das aria-describedby-Attribut wird oft mit aria-labelledby verwechselt, dient aber einem anderen Zweck. Es setzt nicht den barrierefreien Namen. Es fuegt eine Beschreibung hinzu, die Screenreader nach dem Namen ankuendigen.
Wenn ein Screenreader ein Eingabefeld mit dem Label Passwort und einem aria-describedby findet, das auf den Text Muss mindestens 8 Zeichen mit einer Zahl enthalten zeigt, lautet die Ankuendigung: Passwort, Eingabefeld, Muss mindestens 8 Zeichen mit einer Zahl enthalten.
Verwenden Sie aria-describedby fuer Formularfeld-Anweisungen, Formatanforderungen, Fehlermeldungen und ergaenzende Informationen.
Gaengiges Pattern fuer Formularvalidierung: Bei Fehlern erhaelt jedes ungueltige Feld aria-describedby mit Verweis auf seine Fehlermeldung.
Verwenden Sie aria-describedby nicht als Ersatz fuer aria-label oder aria-labelledby. Ein Element ohne barrierefreien Namen, aber mit aria-describedby bleibt namenlos. Screenreader-Navigationslisten zeigen nur barrierefreie Namen, keine Beschreibungen.
Haeufige ARIA-Fehler und deren Behebung
Nach dem Scannen von ueber zehntausend Websites tauchen bestimmte ARIA-Fehler immer wieder auf.
Fehler eins: aria-label auf Elementen mit sichtbarem Text. Ein Link mit sichtbarem Text Mehr erfahren und aria-label="Mehr ueber unsere Preise erfahren" erzeugt eine Diskrepanz. Korrektur: Entweder den sichtbaren Text beschreibend genug machen oder das aria-label entfernen und visuell verborgenen Text verwenden.
Fehler zwei: aria-label auf einem div oder span ohne Rolle. Ein div mit aria-label aber ohne role-Attribut wird von den meisten Screenreadern ignoriert. Korrektur: Fuegen Sie eine passende Rolle hinzu oder verwenden Sie ein semantisches Element.
Fehler drei: Inhalt zwischen aria-label und sichtbarem Text duplizieren. Ein Button mit Text Suchen und aria-label="Suchen" ist redundant.
Fehler vier: aria-label statt eines label-Elements fuer Formulareingaben verwenden. Ein Input mit aria-label="E-Mail" aber ohne sichtbares Label bedeutet, dass auch sehende Nutzer kein Textlabel haben. Korrektur: Verwenden Sie ein label-Element mit dem for-Attribut.
Fehler fuenf: Kaputte aria-labelledby-Referenzen. Ein aria-labelledby, das auf eine nicht existierende ID zeigt, erzeugt keinen barrierefreien Namen. Unser Barrierefreiheits-Checker erkennt solche kaputten Referenzen automatisch.
Fehler sechs: aria-label auf Landmarks ohne eindeutige Labels. Drei nav-Elemente mit identischem aria-label="Navigation" sind nicht unterscheidbar.
Praxisnahe ARIA-Patterns fuer gaengige Komponenten
Theorie ist nuetzlich. Funktionierende Patterns sind besser.
Icon-Buttons. Jeder Icon-Button braucht einen barrierefreien Namen. Der robusteste Ansatz ist visuell verborgener Text im Button-Element, wie ein span mit einer visually-hidden-Klasse. Dieser Text wird uebersetzt und funktioniert mit Sprachsteuerung.
Modaldialoge. Geben Sie dem Dialog role dialog und aria-labelledby mit Verweis auf sein Ueberschriftenelement. Fuegen Sie aria-modal true hinzu. Verwalten Sie den Fokus: Bewegen Sie ihn zum ersten fokussierbaren Element beim Oeffnen, halten Sie ihn im Dialog gefangen, und setzen Sie ihn beim Schliessen auf das ausloesende Element zurueck.
Navigationslandmarks. Verwenden Sie das native nav-Element. Bei mehreren nav-Elementen beschriften Sie jedes mit aria-label. Das Hauptmenue erhaelt aria-label="Hauptnavigation".
Formulargruppen. Verwenden Sie fieldset und legend fuer zusammengehoerige Steuerelemente. Ersetzen Sie dieses Pattern nicht durch div mit aria-label.
Datentabellen. Verwenden Sie das caption-Element oder aria-labelledby fuer den Tabellennamen.
Live-Regionen. Verwenden Sie aria-live polite fuer nicht dringende Updates und aria-live assertive fuer dringende Meldungen.
Tab-Interfaces. Der Container erhaelt role tablist, jeder Tab role tab mit aria-selected, das Panel role tabpanel mit aria-labelledby.
ARIA Labels testen
Korrektes ARIA zu schreiben ist die halbe Arbeit. Zu ueberpruefen, ob es funktioniert, die andere.
Starten Sie mit einem automatisierten Scan. Lassen Sie Ihre Seiten durch unseren kostenlosen Barrierefreiheits-Checker auf web-accessibility-checker.com laufen. Er erkennt fehlende barrierefreie Namen, kaputte aria-labelledby-Referenzen und weitere ARIA-Probleme.
Oeffnen Sie dann den Barrierefreiheitsbaum im Browser. In Chrome DevTools zeigt der Accessibility-Tab den berechneten barrierefreien Namen und dessen Herkunft.
Testen Sie mit einem Screenreader. NVDA unter Windows und VoiceOver unter macOS sind kostenlos. Navigieren Sie die Seite und achten Sie darauf, was angekuendigt wird.
Pruefen Sie die Tastaturnavigation. Jedes Element mit einem ARIA Label muss per Tastatur erreichbar sein.
Testen Sie mit mehreren Screenreadern. NVDA, JAWS, VoiceOver und TalkBack interpretieren ARIA jeweils leicht unterschiedlich. Kreuz-Tests decken Diskrepanzen auf.
Das BFSG verpflichtet Unternehmen in Deutschland seit Juni 2025 zur digitalen Barrierefreiheit. Die technische Norm ist EN 301 549, die auf WCAG 2.1 AA verweist. Ein gruendlicher ARIA-Test ist Teil jeder BFSG-konformen Pruefung.