ARIA (Accessible Rich Internet Applications) ist eine Spezifikation des W3C, die HTML um Attribute erweitert, um dynamische Web-Inhalte für assistive Technologien zugänglich zu machen. Ohne ARIA wären moderne Single-Page-Applications, Tabs, Modals und Autocomplete-Widgets für Screenreader oft nicht verständlich.
Die fünf ARIA-Regeln
Das W3C definiert fünf Grundregeln für den ARIA-Einsatz:
- Wenn HTML reicht, kein ARIA: Ein nativer
<button>ist immer besser als<div role="button">. - Native Semantik nicht überschreiben: Niemals
role="button"auf ein bestehendes<button>setzen. - Tastatur-Bedienbarkeit ist Pflicht: ARIA-Rollen brauchen passende Tastatur-Interaktion.
- Sichtbare Elemente nicht verstecken:
aria-hidden="true"darf nicht auf fokussierbare Elemente. - Interaktive Elemente brauchen Namen:
aria-labeloderaria-labelledbybei jeder Custom-Interaktion.
Wichtige ARIA-Attribute
Beschriftung und Beschreibung
| Attribut | Zweck | Beispiel |
|---|---|---|
aria-label | Alternative Bezeichnung als String | <button aria-label="Suchen">🔍</button> |
aria-labelledby | Verweis auf bestehendes Label-Element | aria-labelledby="dialog-title" |
aria-describedby | Zusätzliche Beschreibung (z.B. Hilfetext) | aria-describedby="passwort-hilfe" |
Sichtbarkeit
| Attribut | Zweck |
|---|---|
aria-hidden="true" | Element für Screenreader unsichtbar machen |
aria-expanded="true/false" | Ausgeklappter Zustand (z.B. Akkordeon) |
aria-pressed="true/false" | Aktiver Zustand bei Toggle-Buttons |
Live-Regionen
Mit aria-live werden dynamische Inhalts-Updates angekündigt:
<div aria-live="polite" role="status">
Suchergebnisse werden geladen...
</div>
polite: Update wird nach aktueller Sprachausgabe vorgelesenassertive: Update wird sofort vorgelesen (für kritische Hinweise)off: Standardwert, keine Ankündigung
Rollen (role)
Mit role wird einem Element eine semantische Rolle zugewiesen. Häufig genutzte Werte:
role="navigation",role="main",role="banner",role="contentinfo": Landmarks (besser: native Elemente nutzen)role="alert": Sofortige Meldungrole="status": Status-Regionrole="dialog": Modaler Dialogrole="tab",role="tabpanel",role="tablist": Tab-Komponenten
Praxis-Beispiele
Icon-Button mit aria-label
<button aria-label="Suche öffnen" class="icon-btn">
<svg aria-hidden="true">...</svg>
</button>
Das SVG ist aria-hidden, weil der Button-Text das Element bereits beschreibt. Doppelte Ansage vermieden.
Modal mit Fokus-Management
<div role="dialog" aria-labelledby="dlg-title" aria-modal="true">
<h2 id="dlg-title">Termin buchen</h2>
...
</div>
Fokus muss beim Öffnen in den Dialog wandern, beim Schließen zurück zum Trigger.
Akkordeon
<button aria-expanded="false" aria-controls="acc-panel-1">
Frage 1
</button>
<div id="acc-panel-1" hidden>
Antwort 1
</div>
JavaScript togglet aria-expanded und das hidden-Attribut beim Klick.
Formular-Validierung
<input
id="email"
type="email"
aria-invalid="true"
aria-describedby="email-err"
>
<p id="email-err" role="alert">
Bitte gültige E-Mail eingeben.
</p>
Screenreader lesen die Fehlermeldung automatisch beim Erscheinen vor (durch role="alert").
Häufige ARIA-Fehler
- Doppelte Ansage:
<button aria-label="Suchen">Suchen</button>wird zweimal vorgelesen - Falsche Rollen:
role="button"auf einem<a>-Element, das eigentlich eine Aktion ausführt - Vergessene Tastatur-Bedienung: Custom-Widget mit
role="button", aber kein Enter-/Space-Handler - Versteckte fokussierbare Elemente:
aria-hidden="true"auf einem Element mittabindex="0"
Werkzeuge wie axe DevTools oder Lighthouse erkennen viele dieser Fehler automatisch. Ein vollständiger Accessibility Audit zeigt sie alle.