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.
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. 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.
Quellen
Stand: 7. August 2026.