ARIA-Label richtig einsetzen: Der Praxis-Guide für Entwickler

Es gibt eine Regel rund um ARIA-Label und WAI-ARIA insgesamt, die jeder Frontend-Entwickler kennen sollte und die in der Praxis trotzdem regelmäßig gebrochen wird: Kein ARIA ist besser als falsches ARIA. So steht es in den ARIA Authoring Practices des W3C, und es ist nicht als Provokation gemeint, sondern als Schutz. Falsch eingesetztes ARIA macht eine Komponente nicht zugänglich, es macht sie kaputt – und zwar oft schlimmer kaputt, als wenn niemand ARIA-Attribute angefasst hätte. In diesem Praxis-Guide zeige ich Ihnen die fünf ARIA-Regeln in Klartext, die Anti-Patterns, die mir in Code-Reviews am häufigsten begegnen, und wann ARIA tatsächlich gebraucht wird.

Was ARIA ist und wofür Sie es brauchen

WAI-ARIA – Accessible Rich Internet Applications – ist eine W3C-Spezifikation, mit der sich HTML-Elementen zusätzliche Semantik geben lässt, die natives HTML nicht abbildet. Über Attribute wie role, aria-label, aria-expanded oder aria-live können Sie assistiven Technologien Informationen mitteilen, die ein Screenreader sonst nicht hätte: dass ein div wie ein Button funktionieren soll, dass ein Akkordeon gerade aufgeklappt ist, dass ein Bereich der Seite Live-Updates erhält. ARIA ergänzt HTML – es ersetzt es nicht. Und genau dort liegt die häufigste Fehlerquelle: ARIA wird eingesetzt, wo natives HTML denselben Effekt von Haus aus hätte.

Die erste Regel von ARIA: Verwenden Sie es nicht

Die erste der fünf ARIA-Regeln klingt für Entwickler kontraintuitiv: Wenn ein natives HTML-Element die benötigte Semantik und das Verhalten bereits mitbringt, verwenden Sie dieses Element – nicht ARIA. Ein <button> ist von sich aus tastaturbedienbar, fokussierbar, hat eine implizite Rolle und reagiert auf Enter und Leertaste. Ein <div role="button"> hat das alles nicht – Sie müssen es per JavaScript nachbauen, und in den meisten Fällen wird es unvollständig nachgebaut. Die Regel ist also kein Anti-ARIA-Statement, sondern eine pragmatische Risikoabwägung: Natives HTML bringt die Barrierefreiheit gratis mit, ARIA verlangt korrekte Umsetzung in jedem Detail. Wie diese native Basis aussieht, beschreibe ich in Semantisches HTML als Fundament der Barrierefreiheit.

Die fünf ARIA-Regeln in Klartext

Die offiziellen Regeln des W3C übersetzt, so wie ich sie in Code-Reviews einsetze:

1. Wenn natives HTML reicht, nehmen Sie natives HTML. ARIA ist die zweite Wahl, nicht die erste.
2. Verändern Sie native Semantik nur, wenn Sie wirklich müssen. Eine Überschrift sollte nicht plötzlich die Rolle eines Buttons bekommen.
3. Alle interaktiven ARIA-Controls müssen mit der Tastatur bedienbar sein. Ein div role="button" ohne tabindex und Tastatur-Handler ist sinnlos.
4. Verstecken Sie keine fokussierbaren Elemente vor assistiver Technologie. aria-hidden="true" auf einem Element, in das man tabben kann, ist die zuverlässigste Methode, einen Screenreader-Nutzer im Niemandsland zu verlieren.
5. Jedes interaktive Element braucht einen zugänglichen Namen. Ein Icon-Button ohne Beschriftung ist für blinde Nutzer unsichtbar – egal, wie hübsch das Icon ist.

Diese Regeln klingen banal, sind aber in jedem zweiten Audit verletzt. Die folgenden Anti-Patterns sind die häufigsten Verstöße in der Praxis.

Die häufigsten ARIA-Anti-Patterns

aria-label auf Elementen mit sichtbarem Text

Der Klassiker. Ein Entwickler will „auf Nummer sicher“ gehen und schreibt:

<button aria-label="Speichern">Speichern</button>

Das ist nicht doppelt gemoppelt – das ist potenziell schädlich. Der aria-label-Wert überschreibt den sichtbaren Text. Wenn der sichtbare Text in der Übersetzung „Save changes“ lautet, der aria-label aber „Speichern“ geblieben ist, hat ein Screenreader-Nutzer eine andere Information als ein sehender. Schlimmer noch: Spracheingabe-Nutzer sagen, was sie sehen – „Save changes anklicken“ –, aber das Element heißt im Code „Speichern“ und reagiert nicht. Faustregel: Wenn das Element sichtbaren, korrekten Text trägt, brauchen Sie kein aria-label.

role=“button“ auf einem div oder einem Link

Wenn ein Entwickler ein <div> oder ein <a> wie einen Button verwenden will und ihm die Rolle „button“ zuweist, verliert er alles, was ein nativer Button mitbringt:

<!-- Falsch -->
<div role="button" onclick="speichern()">Speichern</div>

<!-- Richtig -->
<button onclick="speichern()">Speichern</button>

Der div ist nicht fokussierbar, reagiert nicht auf Enter und Leertaste, hat keinen Default-Fokus-Stil und löst keine Formularaktionen aus. Sie müssten tabindex="0", einen Keydown-Handler und einen sichtbaren Fokus-Stil nachrüsten, um das gleiche Verhalten zu erreichen – und vermutlich noch ein paar Dinge übersehen. Natives Element nehmen, fertig.

aria-hidden auf fokussierbaren Elementen

Eines der zerstörerischsten Anti-Patterns. Wenn Sie ein interaktives Element vor Screenreadern verbergen, es aber per Tastatur erreichbar bleibt, landet der Nutzer im Tabbing dort – und sein Screenreader sagt nichts. Er steht in einem unsichtbaren Element fest:

<!-- Falsch -->
<button aria-hidden="true">Aktion</button>

Wenn ein Element nicht für assistive Technologie da sein soll, muss es auch nicht fokussierbar sein – etwa durch tabindex="-1" oder durch komplettes Entfernen aus dem DOM. Beide Eigenschaften müssen zusammen entschieden werden.

Redundante Rollen auf nativen Elementen

Native HTML-Elemente haben ihre Rollen bereits implizit. Diese erneut zu setzen, ist nicht falsch, aber unnötig – und kann in seltenen Fällen sogar Probleme erzeugen, wenn die Rolle sich weiterentwickelt:

<!-- Redundant -->
<nav role="navigation">...</nav>
<button role="button">...</button>

<!-- Sauber -->
<nav>...</nav>
<button>...</button>

Lassen Sie native Elemente ihre Arbeit tun. ARIA ist für die Fälle gedacht, in denen HTML keine passende Rolle hat – nicht für die, in denen es längst eine hat.

Custom-Komponenten ohne Zustands-Attribute

Wenn Sie schon ein Akkordeon, einen Tab-Container oder eine Checkbox selbst bauen müssen, gehört der Zustand zwingend in die Auszeichnung. Ein Akkordeon, das visuell auf- und zuklappt, aber kein aria-expanded aktualisiert, sagt einem Screenreader nichts über seinen Zustand:

<button aria-expanded="false" aria-controls="panel-1">
  Mehr Details
</button>
<div id="panel-1" hidden>...</div>

Der Wert von aria-expanded muss sich synchron mit dem visuellen Zustand ändern. Vergisst man das, hat man eine Komponente, die für Sehende funktioniert und für Screenreader-Nutzer ein Rätsel bleibt.

aria-label, der dem sichtbaren Text widerspricht

Eine Variante des ersten Anti-Patterns mit besonderer Tücke. Wenn der sichtbare Text „Mehr erfahren“ lautet, der aria-label aber „Produktdetails öffnen“, entsteht ein Konflikt für Voice-Control-Nutzer und potenziell verwirrende Ausgabe für Screenreader. Wenn Sie den Namen ändern wollen, ändern Sie den sichtbaren Text – nicht den aria-label parallel dazu.

Wann ARIA wirklich gebraucht wird

Diese Liste ist kürzer, als die Vielfalt der Attribute vermuten lässt – und genau das ist die Botschaft. Sie brauchen ARIA vor allem in diesen Fällen:

• Icon-Buttons ohne sichtbaren Text: Ein Lupen-Symbol ohne Beschriftung braucht aria-label="Suche".
• Komplexe Custom-Widgets: Tabs, Akkordeons, Modale, Karussells, Trees – Komponenten, für die HTML keine native Entsprechung kennt.
• Live-Regionen: Toast-Notifications, dynamische Suchergebnisse, Statusmeldungen, die ankommen müssen, ohne dass der Fokus wandert (aria-live="polite" oder role="status").
• Zusätzliche Beschreibungen: Hilfetexte zu Formularfeldern, die mit aria-describedby referenziert werden.
• Zustandsangaben: aria-current für die aktuelle Seite in der Navigation, aria-invalid für fehlerhafte Felder, aria-pressed für Toggle-Buttons.

Bei interaktiven ARIA-Widgets müssen Sie zusätzlich die Tastaturbedienung selbst implementieren – Pfeiltasten in Tabs, Escape zum Schließen eines Modals, korrektes Fokus-Management. Welche Anforderungen WCAG hier konkret stellt, lesen Sie in Tastaturbedienung und Fokus-Management nach WCAG umsetzen.

Was im Code-Review auffallen sollte

In Reviews scanne ich gezielt nach diesen Mustern: jedes div role="button" oder a role="button" wird hinterfragt – warum kein nativer Button? Jedes aria-label wird mit dem sichtbaren Text abgeglichen – Widerspruch oder Verdopplung? Jedes aria-hidden="true" wird mit der Tabbing-Reihenfolge abgeglichen – ist das Element trotzdem erreichbar? Jedes Custom-Widget wird auf vorhandene State-Attribute geprüft – verändert sich aria-expanded, aria-checked, aria-pressed mit dem visuellen Zustand? Diese vier Fragen finden in meiner Erfahrung den Großteil der ARIA-Probleme.

Wie Sie ARIA-Fehler automatisiert finden

Das Problem mit ARIA-Fehlern ist, dass sie ständig neu entstehen. Eine Komponente, die heute sauber ist, kann nach dem nächsten Refactoring kaputt sein – ein vergessenes aria-expanded-Update, ein neues aria-label, das den sichtbaren Text überschreibt, ein dazugekommenes aria-hidden auf einem fokussierbaren Element. Manuelle Reviews fangen einen Teil, aber nicht alles.

Genau hier setzt unser Access Guard an. Das Monitoring prüft Ihre Seiten nach jedem Code-Deployment automatisch auf Accessibility-Verstöße – inklusive der typischen ARIA-Anti-Patterns aus diesem Ratgeber – und meldet Treffer direkt in Ihre Entwicklungs-Werkzeuge wie Jira, Slack oder Teams. Für jeden Befund liefert es konkrete Code-Hinweise zur Behebung, sodass Ihre Entwickler keine tiefen WCAG-Kenntnisse brauchen, um den Fehler zu fixen. So bleibt ein sauber implementiertes ARIA-Muster auch nach dem nächsten Sprint sauber – und Fehler werden gefunden, bevor sie in Production gehen.