Kurz und einfach erklärt
Dieser Beitrag erklärt ARIA. ARIA ist eine Technik für Webseiten. Sie sagt Hilfen wie dem Screenreader, was ein Teil der Seite ist.
Oft ist normales HTML besser. Ein echter Knopf kann schon viel. Er geht auch mit der Tastatur. ARIA allein macht das nicht.
Manche Teile gibt es in HTML nicht. Zum Beispiel Reiter oder Regler. Dort braucht man ARIA. Der Zustand muss bei jedem Klick stimmen. Etwa, ob ein Menü offen ist.
Live-Regions melden neue Inhalte. Der Screenreader liest sie dann vor. Die Region muss schon vorher auf der Seite stehen.
Falsches ARIA kann mehr schaden als nützen. Wir prüfen, ob Ihre Seite Screenreadern die richtigen Angaben gibt.
WAI-ARIA (Web Accessibility Initiative - Accessible Rich Internet Applications) ist eine mächtige Technik, um interaktive Komponenten für assistive Technologien zugänglich zu machen. Gleichzeitig ist sie eine der am häufigsten falsch eingesetzten Techniken im Web. Der ARIA Authoring Practices Guide stellt seinen Hinweisen den Grundsatz voran: Kein ARIA ist besser als schlechtes ARIA (W3C WAI-ARIA Authoring Practices Guide, 2024). Der WebAIM Million Report (2024) stellt fest, dass Homepages mit ARIA im Durchschnitt mehr erkennbare Fehler aufweisen als solche ohne; WebAIM betont, dass ARIA diese Fehler nicht zwingend verursacht, weil solche Seiten meist komplexer sind. Dieser Artikel zeigt, wie Rollen, Zustände und Live-Regions korrekt eingesetzt werden, welche WCAG-Anforderungen damit verbunden sind und wie ein professionelles Audit fehlerhaftes ARIA aufdeckt.
Das Wichtigste in Kürze
- ARIA beschreibt nur, implementiert aber nichts. Ein div mit role=button wird als Schaltfläche angesagt, ist jedoch weder fokussierbar noch mit Enter oder Leertaste bedienbar - ein natives button-Element bringt Rolle, Fokus und Tastaturbedienung mit.
- Die fünf W3C-Regeln (Using ARIA, 2018): natives Element bevorzugen, native Semantik nicht überschreiben, jedes interaktive ARIA-Steuerelement tastaturbedienbar machen, aria-hidden nie auf fokussierbaren Elementen setzen, jedem Bedienelement einen zugänglichen Namen geben.
- Für Tabs, Tree-Views, Comboboxen oder Slider mit zwei Griffen gibt es kein HTML-Pendant; hier ist ARIA nötig. Der ARIA Authoring Practices Guide (W3C, 2024) legt für jedes Muster Rollen, Zustände und Tastaturbedienung fest.
- Zustände wie aria-expanded, aria-selected, aria-checked und aria-current müssen bei jeder Interaktion per JavaScript aktualisiert werden. Beziehungen über aria-controls oder aria-labelledby verweisen auf IDs, die eindeutig und im DOM vorhanden sein müssen.
- Live-Regions kündigen dynamische Änderungen an: polite ist der Standard, assertive bleibt dringenden Meldungen vorbehalten. Die Region muss vorher - auch leer - im DOM stehen, sonst bleibt die Ansage aus.
- Laut WebAIM Million Report (2024) haben Seiten mit ARIA im Schnitt mehr erkennbare Fehler als Seiten ohne. Ein manueller Durchlauf mit mindestens zwei Screenreadern zeigt, ob Zustände korrekt angesagt und Live-Regions rechtzeitig ausgelöst werden.
Was ARIA ist und was es nicht ist
ARIA ist eine Sammlung von HTML-Attributen, die assistiven Technologien zusätzliche Informationen über die Rolle, den Zustand und die Eigenschaften eines Elements mitteilen. Diese Informationen fließen in den Accessibility Tree des Browsers ein, eine von der visuellen Darstellung unabhängige Repräsentation der Seite, die Screenreader auslesen. ARIA verändert nur, wie Elemente für assistive Technologien beschrieben werden. Es fügt keine Funktionalität hinzu: Kein Fokusverhalten, keine Tastaturbedienung, kein Klick-Handling.
Genau hier liegt ein häufiges Missverständnis. Wer ein <div role="button"> schreibt, erhält ein Element, das ein Screenreader als Schaltfläche ankündigt, das aber weder fokussierbar ist noch auf die Leertaste oder Enter reagiert. Die gesamte Tastaturbedienung muss per JavaScript nachgebaut werden. Ein natives <button> bringt all das automatisch mit. Der ARIA Authoring Practices Guide hält fest, dass ARIA-Rollen anders als HTML-Eingabeelemente keine Tastaturbedienung und kein Styling im Browser bewirken (W3C WAI-ARIA Authoring Practices Guide).
ARIA gliedert sich in drei Kategorien: Rollen (roles) definieren, was ein Element ist, etwa eine Registerkarte, ein Dialog oder eine Navigationsregion. Zustände (states) beschreiben den aktuellen, veränderlichen Zustand, etwa ob ein Akkordeon geöffnet oder geschlossen ist. Eigenschaften (properties) beschreiben eher statische Merkmale, etwa eine Beschriftung oder eine Beziehung zwischen Elementen. Die Trennung zwischen Zustand und Eigenschaft ist in der Praxis fließend, beide werden über aria-*-Attribute gesetzt.
Die fünf Grundregeln der ARIA-Nutzung
Das W3C hat im Leitfaden Using ARIA fünf Regeln für die ARIA-Nutzung formuliert (W3C, Using ARIA, Arbeitsentwurf 2018); die 2026 eingestellte Fassung enthält nur noch die ersten vier. Sie bilden den Maßstab, an dem wir in jedem WCAG-Audit die ARIA-Implementierung messen. Wer diese Regeln verinnerlicht, vermeidet viele typische ARIA-Fehler. Schon die erste Regel löst viele Probleme an der Wurzel.
- Verwende ein natives HTML-Element mit der gewünschten Semantik und dem gewünschten Verhalten, statt ein generisches Element mit ARIA umzufunktionieren. Ein
<button>ist einem<div role="button">in der Regel vorzuziehen. - Ändere die native Semantik eines Elements nicht, wenn es nicht nötig ist. Ein
<h2 role="tab">verbirgt für Screenreader, dass es sich um eine Überschrift handelt, und ist meist falsch. - Alle interaktiven ARIA-Steuerelemente müssen per Tastatur bedienbar sein. Ein Element mit
role="button"brauchttabindexund Tastatur-Handler für Enter und Leertaste. - Verstecke keine fokussierbaren Elemente mit
aria-hidden="true". Ein fokussierbares, aber für Screenreader verstecktes Element erzeugt einen toten Fokus-Stopp. - Alle interaktiven Elemente brauchen einen zugänglichen Namen, etwa über sichtbaren Text,
aria-labeloderaria-labelledby.
No ARIA is better than bad ARIA
Rollen vs. native HTML-Semantik
Die meisten ARIA-Rollen haben ein natives HTML-Pendant, das sie überflüssig macht. Die folgende Gegenüberstellung zeigt für typische Anwendungsfälle, warum die native Variante fast immer die bessere Wahl ist. Der Grundsatz dahinter: Natives HTML bringt Rolle, Fokusverhalten und Tastaturbedienung in einem einzigen Element mit, das Browser und assistive Technologien von Haus aus unterstützen.
| Anwendungsfall | Natives HTML | ARIA-Variante (vermeiden) |
|---|---|---|
| Schaltfläche | <button> - fokussierbar, Enter/Leertaste, role=button automatisch | <div role="button" tabindex="0"> - Tastatur per JS nachbauen |
| Link | <a href> - role=link, fokussierbar, in History | <span role="link"> - kein href, keine Tastaturbedienung |
| Navigation | <nav> - erzeugt landmark navigation automatisch | <div role="navigation"> - korrekt, aber unnötig |
| Checkbox | <input type="checkbox"> - Zustand und Bedienung nativ | <div role="checkbox" aria-checked> - alles per JS |
| Überschrift | <h2> - role=heading mit aria-level=2 | <div role="heading" aria-level="2"> - fehleranfällig |
Es gibt jedoch Komponenten, für die HTML keine native Entsprechung bietet. Tabs, ein Tree-View, ein Slider mit zwei Griffen, ein Tab-Panel-System oder ein Combobox-Pattern haben kein eigenes HTML-Element. Hier ist ARIA unverzichtbar. Der ARIA Authoring Practices Guide (W3C, 2024) dokumentiert für jedes dieser Muster die erforderlichen Rollen, Zustände und Tastaturinteraktionen. Wer ein solches Muster baut, sollte sich exakt an diese Vorgaben halten, statt ein eigenes Konzept zu erfinden.
<!-- Tabs: ARIA ist hier korrekt, weil HTML kein Tab-Element kennt -->
<div role="tablist" aria-label="Kontoeinstellungen">
<button role="tab" id="tab-1" aria-selected="true"
aria-controls="panel-1">Profil</button>
<button role="tab" id="tab-2" aria-selected="false"
aria-controls="panel-2" tabindex="-1">Sicherheit</button>
</div>
<div role="tabpanel" id="panel-1" aria-labelledby="tab-1">...</div>
<div role="tabpanel" id="panel-2" aria-labelledby="tab-2" hidden>...</div>Zustände und Eigenschaften: aria-expanded, aria-selected und Co.
Zustände teilen dem Screenreader mit, in welchem veränderlichen Zustand sich ein Steuerelement gerade befindet. Sie sind dynamisch und werden über JavaScript aktualisiert, sobald sich die Komponente verändert. Häufig liegt der Fehler nicht in einem falsch gewählten Attribut, sondern in einem Zustand, der nach einer Interaktion nicht aktualisiert wird, sodass der Screenreader veraltete Informationen vorliest.
aria-expanded
Für aufklappbare Elemente wie Akkordeons, Menüs und Disclosure-Buttons. Wert true oder false, muss beim Auf- und Zuklappen aktualisiert werden.
aria-selected
Für ausgewählte Optionen in Tabs, Listboxen und Grids. Genau ein Element pro Gruppe trägt true, der Rest false.
aria-checked
Für Checkboxen, Radios und Switches in ARIA-Form. Werte true, false oder mixed (unbestimmter Zustand bei Tri-State).
aria-disabled
Markiert ein Element als inaktiv, ohne es aus dem Fokus zu nehmen. Anders als das native disabled bleibt es fokussierbar und vorlesbar.
aria-current
Markiert das aktuelle Element in einer Menge, etwa die aktive Seite in der Navigation (aria-current=page) oder den aktuellen Schritt.
aria-label / labelledby
Liefern den zugänglichen Namen. aria-labelledby verweist auf sichtbaren Text per ID, aria-label setzt einen unsichtbaren Namen.
Ein Akkordeon zeigt das Prinzip exemplarisch. Der auslösende Button bekommt aria-expanded, das den Öffnungszustand abbildet, und aria-controls, das auf das gesteuerte Panel verweist. Bei jedem Klick muss aria-expanded zwischen true und false umgeschaltet werden. Vergisst die Implementierung dieses Update, kündigt der Screenreader dauerhaft eingeklappt an, obwohl der Inhalt sichtbar ist. Solche fehlenden Zustandswechsel prüfen und korrigieren wir in der barrierefreien Webentwicklung auch an bestehenden Komponenten.
<!-- Akkordeon: aria-expanded MUSS bei jedem Klick aktualisiert werden -->
<h3>
<button aria-expanded="false" aria-controls="sect-1" id="btn-1">
Versandkosten
</button>
</h3>
<div id="sect-1" role="region" aria-labelledby="btn-1" hidden>
<p>Innerhalb Deutschlands versenden wir ab 50 Euro kostenfrei.</p>
</div>
<script>
// JavaScript schaltet Zustand UND hidden synchron um
const btn = document.getElementById('btn-1');
btn.addEventListener('click', () => {
const open = btn.getAttribute('aria-expanded') === 'true';
btn.setAttribute('aria-expanded', String(!open));
document.getElementById('sect-1').hidden = open;
});
</script>Beziehungs-Attribute richtig verknüpfen
Live-Regions: dynamische Inhalte ankündigen
Moderne Oberflächen aktualisieren Inhalte ständig ohne vollständigen Seitenneuladen: Ein Filter reduziert die Trefferzahl, eine Formularvalidierung zeigt einen Fehler, ein Warenkorb-Counter ändert sich, eine Toast-Benachrichtigung erscheint. Sehende Nutzer bemerken diese Änderungen visuell. Screenreader-Nutzer bekommen sie nur mit, wenn die Änderung in einer Live-Region steht. Live-Regions weisen den Screenreader an, Änderungen in einem bestimmten DOM-Bereich automatisch vorzulesen, ohne dass der Fokus dorthin wandern muss.
aria-live="polite" ist der Standardfall für nahezu alle Updates. Der Screenreader wartet, bis die aktuelle Ausgabe beendet ist, und liest die Änderung dann vor, ohne den Nutzer zu unterbrechen. Geeignet für Statusmeldungen, aktualisierte Trefferzahlen, Erfolgshinweise, Speicher-Bestätigungen und Suchvorschläge. aria-live="assertive" unterbricht die laufende Ausgabe sofort und sollte ausschließlich für dringende Meldungen reserviert sein, etwa für einen Fehler, der eine sofortige Reaktion erfordert, oder für eine Sitzungs-Zeitüberschreitung. Die WAI-ARIA-Spezifikation begründet das damit, dass eine Unterbrechung Nutzer desorientieren oder davon abhalten kann, ihre aktuelle Aufgabe abzuschließen; assertive soll daher nur eingesetzt werden, wenn die Unterbrechung zwingend nötig ist (W3C WAI-ARIA 1.2).
Statt der Attribute lassen sich auch die Rollen role="status" (entspricht polite) und role="alert" (entspricht assertive) verwenden. Sie bringen die passenden Live-Eigenschaften automatisch mit und sind semantisch oft klarer. Für die meisten Statusmeldungen ist role="status" die einfachste Wahl, weil sie ohne zusätzliche Attribute auskommt: Laut Spezifikation hat die Rolle implizit aria-live="polite" und aria-atomic="true" (W3C WAI-ARIA 1.2).
Die Live-Region muss vorher im DOM stehen
<!-- Region existiert von Anfang an, leer -->
<div id="status" role="status" aria-live="polite"></div>
<script>
// Später nur den Textinhalt ändern -> wird angekündigt
function announce(message) {
document.getElementById('status').textContent = message;
}
// Beispiel: announce('3 Treffer für Ihre Filterauswahl');
</script>
<!-- FALSCH: Region erst bei Bedarf erzeugen -> keine Ansage
const div = document.createElement('div');
div.setAttribute('aria-live', 'polite');
div.textContent = 'Gespeichert';
document.body.appendChild(div); -->Häufige ARIA-Fehler in der Praxis
Der WebAIM Million Report (2024) zeigt einen kontraintuitiven Befund: Seiten, die ARIA verwenden, weisen im Durchschnitt mehr erkennbare WCAG-Fehler auf als Seiten ohne ARIA. WebAIM schränkt selbst ein, dass ARIA diese Fehler nicht zwingend verursacht, da Seiten mit ARIA meist komplexer sind. Falsch eingesetztes ARIA bleibt dennoch eine eigene Fehlerquelle. Die folgenden Fehlerbilder sind typisch und lassen sich systematisch identifizieren und beheben.
- Redundante Rollen:
<button role="button">oder<nav role="navigation">wiederholen, was das Element ohnehin schon ist. Im besten Fall überflüssig, im schlechtesten verwirrend. - Zustand wird nicht aktualisiert:
aria-expandedbleibt auf false stehen, obwohl das Panel geöffnet ist. Der Screenreader liest dauerhaft falsch vor. - aria-hidden auf fokussierbaren Elementen: Ein Element ist per Tastatur erreichbar, aber für den Screenreader versteckt. Es entsteht ein stiller, verwirrender Fokus-Stopp.
- Verwaiste Beziehungen:
aria-labelledbyoderaria-controlsverweisen auf IDs, die nicht im DOM existieren oder mehrfach vergeben sind. - Fehlender zugänglicher Name: Ein Icon-Button ohne Text und ohne
aria-labelwird nur als Schaltfläche ohne Bezeichnung angekündigt. - assertive im Übermaß: Jede Statusmeldung als assertive zu markieren, macht die Seite für Screenreader-Nutzer zu einem ständigen Unterbrechungs-Stakkato.
Es liegt selten im Interesse von Nutzern oder Autoren, mit ARIA ein interaktives Element, etwa eine Schaltfläche, mit einer Rolle zu überschreiben, die üblicherweise ein nicht interaktives Element trägt.
ARIA mit Screenreadern testen
Automatisierte Prüfwerkzeuge und Browser-Entwicklertools erkennen einen Teil der ARIA-Fehler, etwa ungültige Attributwerte, verwaiste IDs oder verbotene Rollen-Kombinationen. Sie können aber nicht beurteilen, ob ein Zustand inhaltlich korrekt ist oder ob eine Live-Region zum richtigen Zeitpunkt das Richtige ankündigt. Das W3C hält fest, dass Prüfwerkzeuge nicht alle Aspekte der Barrierefreiheit automatisch prüfen können und menschliches Urteil nötig bleibt (W3C WAI, Selecting Web Accessibility Evaluation Tools). Bei ARIA heißt das vor allem: manuell mit echten Screenreadern testen.
ARIA-Komponenten sollten mit mindestens zwei Screenreadern getestet werden, weil sich ihr Verhalten unterscheidet. Die in Windows, macOS, iOS und Android verfügbaren Screenreader decken zusammen einen Großteil der realen Nutzung ab. Ein Tab-System, das in einem Windows-Screenreader tadellos funktioniert, kann in einem macOS-Screenreader eine abweichende Tastaturbedienung erfordern, und nur der direkte Test zeigt das.
Ein systematischer ARIA-Test umfasst: das Durchlaufen jeder Komponente per Tastatur, das Prüfen, ob jeder Zustand korrekt angekündigt wird, das Auslösen jeder dynamischen Änderung und das Verifizieren der Live-Region-Ansage, sowie den Abgleich mit den Tastaturmustern des ARIA Authoring Practices Guide. Unser WCAG-Audit bedient dafür jede Komponente per Tastatur, prüft an der Ausgabe für Screenreader, ob Rollen, Namen, Zustände und Live-Regions bei jeder Änderung stimmen, und gleicht mit den Tastaturmustern des ARIA Authoring Practices Guide ab; die Ansage in einem bestimmten Screenreader ist nicht Teil der Prüfung.
Eng verwandt mit dem Thema sind zugängliche Formulare, in denen ARIA-Attribute wie aria-describedby, aria-invalid und aria-required eine zentrale Rolle für die Fehlerkommunikation spielen. Wie diese Attribute mit der Validierung zusammenspielen, beschreiben wir ausführlich im Beitrag zu barrierefreien Formularen und Validierung.
aria-live="polite" wartet, bis der Screenreader die aktuelle Ausgabe beendet hat, und ist für nahezu alle Statusmeldungen geeignet. aria-live="assertive" unterbricht sofort und sollte nur für dringende Meldungen wie kritische Fehler oder Sitzungs-Zeitüberschreitungen reserviert sein, da häufige Unterbrechungen die Nutzung stark stören.Verwandte Artikel
Barrierefreie KI-Chatbots: WCAG-konforme Voice-Bots
Wann KI-Chatbots und Voice-Assistenten unter das BFSG fallen und wie Conversational UI mit ARIA-Live-Regions, Fokus-Management und Textpfad WCAG-konform wird.
ARIA Live: Barrierefreie Fehler- und Statusmeldungen
Barrierefreie Fehler- und Statusmeldungen nach WCAG 4.1.3: ARIA Live Regions, role=alert, role=status und aria-describedby für Formulare und dynamische Inhalte.
Screenreader-Optimierung: Website vorlesbar machen
Screenreader-Optimierung für Websites: ARIA-Landmarks, Rollen, Live-Regionen, semantisches HTML und Tests mit Screenreadern auf Windows, macOS und dem Telefon.