Wann brauchen Sie ARIA?
Kurzantwort: Nutzen Sie zuerst das passende native HTML-Element. Ergänzen Sie ARIA nur, wenn HTML die benötigte Semantik oder einen dynamischen Zustand nicht ausdrückt. ARIA verändert die Darstellung oder Tastaturbedienung nicht automatisch.
Auf einen Blick:
- Reihenfolge: erst natives HTML, dann ARIA. Ein
<button>bringt Rolle, Fokus und Tastaturverhalten mit. - Drei Kerninformationen: jede interaktive Komponente braucht Name, Rolle und Zustand.
aria-labelüberschreibt den sichtbaren Text. Bevorzugen Sie sichtbaren Text oderaria-labelledby.- Zustände synchron halten:
aria-expandedundhiddenmüssen gemeinsam umschalten. - Statusmeldungen: Live-Region mit
aria-live="polite"beim Laden ins DOM,role="alert"nur für Dringendes.
Ein <button> bringt Rolle, Fokusfähigkeit und Tastaturaktivierung bereits mit. Ein <div role="button"> benötigt zusätzlich tabindex, Enter-/Leertastenbehandlung, deaktivierte Zustände und Fokusgestaltung.
Links und Buttons nicht verwechseln
Links navigieren zu einem Ziel, Buttons lösen eine Aktion aus:
<a href="/einstellungen/">Einstellungen öffnen</a>
<button type="button">Filter zurücksetzen</button>Ein Link mit href="#" und JavaScript-Aktion ist kein robuster Button. Ein Button, der lediglich zu einer anderen Seite führt, nimmt dagegen Browserfunktionen wie „in neuem Tab öffnen“.
Seitenstruktur mit nativen Regionen
<header>…</header>
<nav aria-label="Hauptnavigation">…</nav>
<main id="main">…</main>
<aside aria-labelledby="related-heading">…</aside>
<footer>…</footer>Mehrere Navigationen brauchen unterscheidbare Namen. Verwenden Sie aria-label oder aria-labelledby nicht, um jeden neutralen Container vorsorglich zur Region zu machen. Zu viele Regionen erschweren die Orientierung.
Überschriften bilden eine Gliederung
Wählen Sie Überschriften nach ihrer inhaltlichen Ebene, nicht nach ihrer visuellen Größe (siehe Heading-Hierarchie im Glossar). CSS gestaltet das Aussehen. Ein Text, der nur fett und groß dargestellt ist, erscheint nicht in der Überschriftennavigation eines Screenreaders.
Eine Seite besitzt üblicherweise eine präzise Hauptüberschrift. Darunter folgen logisch verschachtelte Ebenen. Ein Sprung kann in Sonderfällen inhaltlich begründbar sein, sollte aber nicht aus Bequemlichkeit entstehen.
Namen, Rollen und Zustände
Assistive Technologien benötigen für interaktive Komponenten drei Kerninformationen:
- Name: Was ist das? Beispielsweise „Filter öffnen“.
- Rolle: Wie kann es bedient werden? Beispielsweise Button.
- Zustand: Was gilt gerade? Beispielsweise geöffnet oder ausgewählt.
<button type="button" aria-expanded="false" aria-controls="filters">
Filter öffnen
</button>
<div id="filters" hidden>…</div>Das Skript muss aria-expanded und hidden synchron aktualisieren. Ein Attribut ohne passendes Verhalten liefert falsche Informationen.
Zugängliche Namen nicht überschreiben
aria-label ersetzt den aus dem Inhalt berechneten Namen. Dadurch kann sichtbarer Text für Screenreader verschwinden:
<!-- Problematisch: Sichtbar steht „Suche“, ausgegeben wird nur „Öffnen“. -->
<button aria-label="Öffnen">Suche</button>Bevorzugen Sie sichtbaren Text. Nutzen Sie aria-labelledby, wenn bereits sichtbare Texte gemeinsam den Namen bilden sollen. Vermeiden Sie Namen, die von der sichtbaren Beschriftung abweichen; das erschwert unter anderem Sprachsteuerung.
Dynamische Statusmeldungen
Ein Status wie „3 Ergebnisse gefunden“ kann mit einer zurückhaltenden Live-Region angekündigt werden:
<p id="results-status" aria-live="polite" aria-atomic="true"></p>Fügen Sie die Live-Region bereits beim Laden in das DOM ein und ändern Sie anschließend ihren Text. Verwenden Sie role="alert" nur für dringende Meldungen. Zu viele Ansagen unterbrechen die Bedienung.
Prüfen statt vermuten
- Validieren Sie das HTML.
- Prüfen Sie Rollen und zugängliche Namen im Accessibility Tree des Browsers.
- Bedienen Sie alles mit der Tastatur.
- Testen Sie Zustandswechsel mit einem Screenreader.
- Entfernen Sie redundante Rollen und unnötige ARIA-Attribute.
Die Leitfäden zu Tastatur und Fokus, Formularen und Screenreader-Tests vertiefen diese Schritte. Wenn Ihr Team diese Muster dauerhaft verankern soll, hilft eine Barrierefreiheits-Schulung für Entwicklung und Redaktion.
Häufige Fragen
Wann sollte ich ARIA einsetzen?
Erst dann, wenn HTML die benötigte Semantik oder einen dynamischen Zustand nicht ausdrücken kann. Für Buttons, Links, Überschriften, Formularfelder und Seitenregionen gibt es passende native Elemente, die Rolle, Fokusfähigkeit und Tastaturverhalten mitbringen. ARIA ergänzt Information, verändert aber weder Darstellung noch Bedienbarkeit.
Warum heißt es, kein ARIA sei besser als schlechtes ARIA?
Weil ARIA nur beschreibt, was ein Element sein soll, ohne es dazu zu machen. Ein <div role="button"> ohne tabindex und Tastenbehandlung wird als Schalter angekündigt, lässt sich aber nicht bedienen – das ist schlechter als ein schmuckloses <div>, weil es eine Zusage macht, die nicht eingehalten wird. Falsche oder widersprüchliche Attribute verschlechtern die zugängliche Oberfläche aktiv.
Was ist der Unterschied zwischen aria-label und aria-labelledby?
aria-label setzt einen Namen als freien Text und überschreibt dabei den sichtbaren Inhalt. aria-labelledby verweist über IDs auf bereits sichtbaren Text und setzt ihn zum Namen zusammen. Bevorzugen Sie aria-labelledby oder gleich sichtbaren Text, denn abweichende Namen erschweren unter anderem die Sprachsteuerung.
Darf ich Überschriftenebenen überspringen?
WCAG verbietet es nicht ausdrücklich, aber es beschädigt die Gliederung, über die Screenreader-Nutzende navigieren. Wählen Sie die Ebene nach der inhaltlichen Verschachtelung und gestalten Sie die Größe mit CSS. Ein Sprung kann in Sonderfällen begründet sein, sollte aber nicht aus Bequemlichkeit entstehen.
Quellen
Stand: 7. August 2026.