ARIA richtig einsetzen: Rollen, Zustände, Live-Regions
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. Die erste Regel der ARIA Authoring Practices lautet sinngemäß: 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, weil ARIA oft ohne das nötige Verständnis ergänzt wird. 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.
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 das häufigste Missverständnis. Wer ein bringt all das automatisch mit. Die W3C-Dokumentation formuliert es klar: ARIA beschreibt, HTML implementiert (W3C WAI, ARIA in HTML, 2024).
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 fünf Regeln für die ARIA-Nutzung formuliert (W3C, Using ARIA, 2024). Sie bilden den Maßstab, an dem wir in jedem WCAG-Audit die ARIA-Implementierung messen. Wer diese Regeln verinnerlicht, vermeidet die überwiegende Mehrheit aller ARIA-Fehler. Die Reihenfolge ist bewusst gewählt: Die erste Regel ist die wichtigste und löst viele Probleme bereits 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
ist immer einemvorzuziehen.- Ändere die native Semantik eines Elements nicht, wenn es nicht nötig ist. Ein
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. - Ändere die native Semantik eines Elements nicht, wenn es nicht nötig ist. Ein
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 in allen Browsern und assistiven Technologien getestet ist.
| 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. Der häufigste Fehler ist nicht ein falsch gewähltes Attribut, sondern ein 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. Das ist einer der häufigsten Befunde, die wir in der barrierefreien Webentwicklung bei bestehenden Komponenten korrigieren.
<!-- 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. Eine Studie der Nielsen Norman Group (2023) weist darauf hin, dass häufige assertive Unterbrechungen die Nutzung erheblich stören und schnell als belastend empfunden werden.
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 und robusteste Wahl, weil sie ohne zusätzliche Attribute auskommt und von gängigen Screenreadern zuverlässig unterstützt wird (W3C WAI-ARIA, 2024).
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 angekuendigt
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. Der Grund ist nicht, dass ARIA schadet, sondern dass es oft ohne ausreichendes Verständnis eingesetzt wird. Die folgenden Fehlerbilder begegnen uns in fast jedem Projekt und lassen sich systematisch identifizieren und beheben.
- Redundante Rollen:
oderwiederholen, 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.
ARIA kann HTML-Semantik überschreiben. Eine falsche Rolle verbirgt, was ein Element wirklich ist. Deshalb ist die sicherste Strategie, ARIA nur dort einzusetzen, wo natives HTML wirklich nicht ausreicht.
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. Studien zeigen, dass automatisierte Tests typischerweise nur einen Teil der WCAG-Erfolgskriterien überhaupt prüfen können (W3C/WAI). Den Rest deckt nur ein manueller Test mit echten Screenreadern auf.
Wir testen ARIA-Komponenten mit mindestens zwei Screenreadern, 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. Diese strukturierte Prüfung ist fester Bestandteil unseres WCAG-Audits und ergänzt die automatisierte Analyse um die Dimension, die Maschinen nicht abdecken können.
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.