ARIA Barrierefreiheit richtig einsetzen: Wann Sie es brauchen und wann nicht

Von Manuel Hack, ihp media · Aktualisiert am 16. Juni 2026

ARIA steckt auf mehr als 80 Prozent aller Websites, und Seiten mit ARIA haben trotzdem im Schnitt mehr automatisch erkennbare Barrierefreiheitsfehler als Seiten ohne. Der Grund: ARIA beschreibt, aber liefert keine Funktion. Falsch eingesetzt, meldet ein Screenreader einen Button, den die Tastatur nicht auslösen kann, oder versteckt Inhalte, die noch im Tab-Fluss liegen. Dieser Artikel zeigt, wo ARIA nötig ist, wo natives HTML die bessere Wahl ist und welche Einsätze aktiv schaden.

Was ARIA ist, und was nicht

ARIA steht für Accessible Rich Internet Applications und ist eine Spezifikation des W3C. Sie erweitert HTML um Attribute, die Rollen, Zustände und Eigenschaften von Elementen beschreiben, für Screenreader, Sprachsteuerungen und andere assistive Technologien, die auf den sogenannten Accessibility Tree des Browsers zugreifen.

Das entscheidende Missverständnis: Ein <div> mit role="button" sieht nicht wie ein Button aus und verhält sich nicht wie einer. Der Screenreader meldet zwar einen Button, aber ohne JavaScript, das Enter und Leertaste auswertet, lässt sich das Element für Tastaturnutzer nicht auslösen. ARIA ist ein Beschreibungswerkzeug. Die Funktion muss der Entwickler selbst bereitstellen.

Natives HTML dagegen bringt beides mit: Ein <button> ist automatisch per Tastatur erreichbar, per Enter und Leertaste auslösbar, für Screenreader korrekt beschriftet und über CSS vollständig gestaltbar. Die eingebaute Semantik kostet keinen Mehraufwand.

Die vier ARIA-Grundregeln

Das W3C hat vier verbindliche Grundregeln für den ARIA-Einsatz formuliert. Sie stehen im Dokument „Using ARIA“ (W3C, Stand 2026) und gelten für jeden, der ARIA-Attribute setzt.

Das ist die wichtigste Regel, und sie wird am häufigsten ignoriert. Ein <nav> ist bereits eine Landmark-Navigation. Ein <main> trägt bereits die Hauptinhalts-Rolle. Ein <label> verknüpft bereits programmatisch mit seinem Eingabefeld. Wer diese Elemente kennt und nutzt, spart sich ARIA in der großen Mehrheit aller Fälle.

Falsch: <h2 role="tab">, das erzeugt eine widersprüchliche Bedeutung. Richtig: <div role="tab"><h2>…</h2></div>, wenn eine Überschrift visuell als Tab erscheinen soll.

Ein role="button" auf einem <div> muss per Enter und Leertaste auslösbar sein. Ein role="dialog" muss den Fokus fangen und per Escape schließbar sein. Was mit der Maus funktioniert, muss auch mit der Tastatur funktionieren, das gilt für jede Aktion.

Das wäre eine Sackgasse: Der Tastaturnutzer landet auf einem Element, der Screenreader meldet nichts. Wer ein Element für Screenreader verbergen will, muss sicherstellen, dass es auch keinen Fokus mehr bekommt, zum Beispiel durch tabindex="-1" oder das Entfernen aus dem Tab-Fluss.

Wann ARIA sinnvoll ist

Komplexe Bedienelemente ohne HTML-Entsprechung

Tabs, Accordion, Slider, modale Dialoge und Autocomplete-Felder haben kein eigenes HTML-Element. Der ARIA Authoring Practices Guide (APG) des W3C liefert für alle diese Muster getestete Implementierungen mit den nötigen Rollen, Attributen und Tastaturinteraktionen.

Ein Tab-Widget braucht: role="tablist" am Container, role="tab" an jedem Tab mit aria-selected, und role="tabpanel" am Inhaltsbereich. Pfeiltasten navigieren zwischen Tabs, Tab wechselt in den Panel, Shift+Tab zurück. Das lässt sich nicht mit nativem HTML allein abbilden, hier ist ARIA die richtige Lösung.

Ein modaler Dialog braucht role="dialog", aria-modal="true", eine Beschriftung per aria-labelledby und Tastaturlogik: Fokus wandert beim Öffnen in den Dialog, bleibt darin im Kreis (Tab/Shift+Tab), und Escape schließt ihn. Ohne diese Attribute weiß ein Screenreader nicht, dass gerade ein eingeschränkter Kontext aktiv ist.

Dynamische Inhalte und Live-Regionen

Wenn sich Inhalte ändern, ohne dass die Seite neu lädt, eine Statusmeldung nach dem Absenden eines Formulars, ein Zähler, ein Ladestatus, bekommen Screenreader-Nutzer das ohne Hinweis nicht mit. Das Attribut aria-live="polite" signalisiert: Diese Region wird aktualisiert, bitte vorlesen sobald der Nutzer gerade nichts anderes tut. aria-live="assertive" unterbricht sofort und gehört ausschließlich auf kritische Fehlermeldungen. Beide sollten sparsam gesetzt werden, weil häufige Ansagen irritieren.

Fehlende Beschriftungen

Icon-Buttons ohne sichtbare Textbeschriftung brauchen ein aria-label, zum Beispiel aria-label="Suche öffnen" auf einem Lupensymbol. Wird ein Feld durch Text außerhalb eines <label>-Elements beschriftet, stellt aria-labelledby die programmatische Verbindung her. Das ist der einzige Fall, in dem aria-label sinnvoll ist, nicht als Ergänzung zu einem bereits eindeutigen Linktext.

Wann ARIA schadet

Die WebAIM Million 2026 analysiert jährlich eine Million Startseiten automatisiert. Das Ergebnis 2026: Seiten mit ARIA-Attributen hatten im Schnitt 59 automatisch erkennbare Fehler, Seiten ohne ARIA 42. Je mehr ARIA-Attribute auf einer Seite, desto mehr Fehler. Das liegt nicht daran, dass ARIA per se schlecht ist, sondern dass es häufig auf bereits korrekt beschriebene Elemente gesetzt wird, oder ohne das nötige Verhalten dahinter.

Die verbreitetsten schädlichen Einsätze:

• Redundantes role auf nativen Elementen: <button role="button">, <nav role="navigation">, <main role="main">. Nicht falsch, aber nutzlos und ein Zeichen fehlender Grundkenntnisse.
• aria-label überschreibt sinnvollen Linktext: <a href="…" aria-label="hier klicken">Barrierefreie Formulare</a>. Der Screenreader liest „hier klicken“ statt des Linktexts. Das Gegenteil von barrierefrei.
• aria-hidden auf sichtbaren, wichtigen Inhalten: Das Element verschwindet vollständig aus dem Zugänglichkeitsbaum. Wenn gleichzeitig Tastaturfokus möglich ist, entsteht eine Sackgasse.
• aria-label in falscher Sprache: Ein deutsches aria-label auf einer als Englisch deklarierten Seite wird mit englischer Phonetik vorgelesen. Screenreader richten die Aussprache nach der deklarierten Dokumentsprache, nicht nach dem tatsächlichen Text.
• role=“button“ ohne Tastaturlogik: Der Screenreader meldet einen Button. Drückt der Nutzer Enter, passiert nichts. Schlechter als gar keine Beschriftung, weil es eine Funktion verspricht, die nicht existiert.

Überblick: Natives HTML oder ARIA?

<!-- Unnötig: button hat bereits role="button" -->
<button role="button" type="submit">Absenden</button>

<!-- Schädlich: überschreibt nativen Namen mit leerem Label -->
<button aria-label="">Absenden</button>

<!-- Korrekt: button-Element, kein ARIA nötig -->
<button type="submit">Absenden</button>

<!-- Icon-Button: aria-label ist hier der richtige Weg -->
<button type="button" aria-label="Suche öffnen">
  <svg aria-hidden="true" focusable="false">…</svg>
</button>

<!-- Visuell sieht es aus wie ein Button, aber: -->
<!-- - kein Tastaturfokus (kein tabindex) -->
<!-- - kein Enter/Space-Handler -->
<!-- - der Screenreader meldet "Button", Enter löst nichts aus -->
<div role="button" onclick="doSomething()">Aktion ausführen</div>

<!-- Option A: immer bevorzugen -->
<button type="button" onclick="doSomething()">Aktion ausführen</button>

<!-- Option B: nur wenn button wirklich nicht passt -->
<div role="button" tabindex="0"
     onclick="doSomething()"
     onkeydown="if(event.key==='Enter'||event.key===' ')doSomething()">
  Aktion ausführen
</div>

<!-- Der Screenreader liest "mehr erfahren", nicht "Barrierefreie Formulare" -->
<a href="/ratgeber/barrierefreie-formulare-schritt-fuer-schritt-zum-zugaenglichen-kontaktfo/" aria-label="mehr erfahren">
  Barrierefreie Formulare
</a>

<!-- Korrekt: Linktext ist bereits eindeutig -->
<a href="/ratgeber/barrierefreie-formulare-schritt-fuer-schritt-zum-zugaenglichen-kontaktfo/">
  Barrierefreie Formulare erstellen
</a>

<!-- Bei Mehrdeutigkeit: aria-label präzisiert -->
<a href="/ratgeber/barrierefreie-formulare-schritt-fuer-schritt-zum-zugaenglichen-kontaktfo/"
   aria-label="Ratgeber: Barrierefreie Formulare erstellen">
  Mehr erfahren
</a>

<!-- Akkordeon-Button -->
<button type="button"
        aria-expanded="false"
        aria-controls="panel-1"
        id="btn-1">
  Häufige Fragen zu ARIA
</button>

<!-- Akkordeon-Panel -->
<div id="panel-1"
     role="region"
     aria-labelledby="btn-1"
     hidden>
  <p>Inhalt des Panels…</p>
</div>

Praxisbeispiel: ARIA-Audit in einem WooCommerce-Shop

Ein Onlineshop kam mit einem Problem: Im axe DevTools-Audit fielen über 40 ARIA-Fehler auf, obwohl das verwendete Theme nach eigenen Angaben „barrierefrei“ war. Die Analyse zeigte ein typisches Muster.

Das Theme hatte auf die Produktkarten-Links ein generisches aria-label="Produkt ansehen" gesetzt. Alle 24 Produkte auf der Kategorienseite trugen dasselbe Label. Ein Screenreader-Nutzer, der über die Links navigierte, hörte 24 Mal „Produkt ansehen“ ohne jeden Unterschied. Das Theme hatte ARIA eingesetzt, um eine Schwäche im Linktext zu kaschieren, das Ergebnis war schlechter als kein ARIA.

Die Lösung: Das generische aria-label wurde entfernt. Stattdessen erhielt jede Produktkarte einen aussagekräftigen Linktext, der aus dem Produktnamen bestand. Für die Preis-Angaben, die visuell klar waren, aber für Screenreader ohne Kontext kamen, wurde aria-label="Preis: 49,90 Euro" ergänzt. 40 Fehler wurden zu zwei, und beide wurden mit einem nativen HTML-Fix gelöst.

Das zweite Problem lag im Mini-Warenkorb: Er öffnet sich per JavaScript ohne Fokussteuerung. Der Screenreader meldete keinen modalen Kontext, der Nutzer konnte den Warenkorb nicht per Escape schließen und wusste nicht, ob er sich im Haupt-Content oder im Overlay befand. Hier war ARIA die richtige Lösung: role="dialog", aria-modal="true", Fokus-Management per JavaScript. Für die Barrieren-Analyse kam zusätzlich der manuelle Screenreader-Test mit VoiceOver auf macOS zum Einsatz, der WAVE-Scanner hatte das Fokus-Problem nicht erkannt.

Das Barrierefreiheitsthema hat viele Facetten, von ARIA bis zu Alternativtexten. Alle häufigen Fehler in einer Übersicht zeigt der Artikel Die 12 häufigsten Barrierefreiheitsfehler auf Mittelstands-Websites.

Sofort-Checkliste

• Keine ARIA-Rollen auf nativen Elementen gesetzt, die diese Rolle bereits haben (<button>, <nav>, <main>)?
• Alle Icon-Buttons haben ein aria-label mit verständlichem Text?
• Kein aria-hidden="true" auf Elementen, die Tastaturfokus erhalten können?
• Alle interaktiven ARIA-Elemente (role=“button“, role=“dialog“ usw.) per Tastatur vollständig bedienbar?
• Live-Regionen nur dort, wo Inhalte sich asynchron ändern (aria-live="polite" für Statusmeldungen)?
• Kein aria-label, das einen vorhandenen, aussagekräftigen Linktext überschreibt?
• Tabellen mit <thead> und scope="col" ausgezeichnet, kein role="table" auf echten Tabellen?
• aria-describedby für Feldhinweise, aria-labelledby für den zugänglichen Namen, nicht verwechseln?
• ARIA-Test mit echtem Screenreader durchgeführt (VoiceOver, NVDA oder TalkBack)?
• Automatisierter Scan mit axe oder WAVE als Einstieg, manueller Test als Abschluss?

Das Wichtigste zum Mitnehmen

Häufige Fragen

Was bedeutet „No ARIA is better than bad ARIA“?

Den Satz prägte die Webentwicklungs-Community auf Basis der W3C-Leitlinien: Ein Element ohne ARIA verhält sich nach der eingebauten Semantik des Browsers. Ein Element mit falschem ARIA widerspricht dieser Semantik. Der Screenreader bekommt widersprüchliche Informationen und kann sie schlechter verarbeiten als keine Information. Richtig eingesetztes ARIA ergänzt, was HTML nicht ausdrücken kann, falsches ARIA stört das, was bereits funktioniert.

Macht ARIA allein meine Website barrierefrei?

Nein. ARIA verbessert die Beschreibung von Elementen für Screenreader, ersetzt aber weder ausreichenden Kontrast noch eine funktionierende Tastaturbedienung, klare Sprache oder eine logische Seitenstruktur. Barrierefreiheit entsteht erst aus dem Zusammenspiel all dieser Ebenen. Wer nur ARIA setzt, ohne die Grundlagen zu klären, hat meist mehr Fehler als vorher.

Wann brauche ich ARIA zwingend?

Bei Widgets ohne HTML-Entsprechung: Tabs, modale Dialoge, Accordions, Tooltips, Comboboxen. Bei asynchron aktualisierten Bereichen, die per aria-live angekündigt werden müssen. Bei Icon-Buttons ohne sichtbaren Text, die ein aria-label brauchen. Und bei Formularfeldern, deren Fehlerhinweis per aria-describedby programmatisch verknüpft werden muss, weil er außerhalb des Labels steht.

Wie teste ich, ob mein ARIA korrekt funktioniert?

Testen Sie mit einem echten Screenreader, nicht nur mit automatisierten Werkzeugen. Für eine erste Einschätzung eignen sich NVDA mit Firefox oder VoiceOver mit Safari. Navigieren Sie alle interaktiven Elemente per Tastatur und notieren Sie, was unklar oder gar nicht angesagt wird. Werkzeuge wie axe sind ein guter Einstieg, ersetzen diesen manuellen Schritt aber nicht, sie erkennen nach gängiger Einschätzung rund 30 bis 40 Prozent aller WCAG-Verstöße. Was korrekte Beschriftung bedeutet und wie Tastaturbedienung geprüft wird, zeigt der Artikel Tastaturbedienung testen ohne Maus.

Was hat ARIA mit dem BFSG zu tun?

Das Barrierefreiheitsstärkungsgesetz schreibt die Norm EN 301 549 vor, die auf WCAG 2.1 Stufe AA verweist. Erfolgskriterium 4.1.2 „Name, Rolle, Wert“ ist der WCAG-Punkt, an dem ARIA am häufigsten relevant wird: Alle Bedienelemente müssen einen programmatisch ermittelbaren Namen, eine Rolle und ihren Zustand haben. ARIA ist das Werkzeug, das genau das für eigene Widgets bereitstellt. Formulare betrifft das besonders direkt, wie Sie sie korrekt beschriften, erklärt der Artikel Barrierefreie Formulare.

Reicht ein Accessibility-Overlay-Plugin für meine WordPress-Seite?

Nein. Overlay-Plugins fügen nachträglich JavaScript ein und können strukturelle Fehler im HTML nicht beheben. Häufig erzeugen sie sogar neue ARIA-Konflikte, weil sie ARIA-Attribute auf bereits korrekt beschriftete Elemente setzen. In der Fachgemeinschaft gelten sie als ungeeignet für echte Konformität. Verlässlich ist nur eine saubere Umsetzung im Quelltext.

Quellen