WAI-ARIA (Web Accessibility Initiative – Accessible Rich Internet Applications) ist ein technischer Standard des W3C. Er ermöglicht es, dynamische Inhalte und komplexe Bedienelemente für assistive Technologien verständlich auszuzeichnen – also überall dort, wo natives HTML an seine Grenzen stößt.
Während die WCAG als Richtlinienkatalog definieren, was für Barrierefreiheit erforderlich ist, liefert WAI-ARIA einen Teil des technischen wie. ARIA verändert ausschließlich, was assistive Technologien im Accessibility Tree vorfinden und ansagen. Es verändert nicht das Verhalten: weder Fokussierbarkeit noch Tastaturbedienung noch Darstellung.
Ein <div role="button"> klingt für einen Screenreader wie eine Schaltfläche, ist aber weder per Tabulator erreichbar noch mit Enter oder Leertaste auslösbar. Wer die Rolle setzt, muss das Verhalten selbst nachbauen: Fokussierbarkeit über tabindex="0", Tastaturereignisse, Zustandsverwaltung. Daraus folgt ein Grundsatz: Kein ARIA ist besser als falsches ARIA. Eine falsch gesetzte Rolle gibt ein Versprechen ab, das die Umsetzung nicht einlöst. Das ist schlechter als gar keine Auszeichnung.
Die drei Kernelemente:
Rollen legen fest, um was für ein Element es sich handelt:
role="tablist",role="dialog",role="alert"Eigenschaften beschreiben dauerhafte Merkmale:
aria-label,aria-required,aria-describedbyZustände bilden veränderliche Zustände ab:
aria-expanded,aria-checked,aria-invalid
Sonderfall: Live-Bereiche
Mit aria-live werden Bereiche gekennzeichnet, deren Änderungen angesagt werden sollen, ohne dass der Fokus dorthin springt: eine Statusmeldung nach dem Absenden eines Formulars, ein Zähler in einem Warenkorb, eine Fehlermeldung bei der Eingabe.
<p role="status" aria-live="polite">3 Ergebnisse gefunden</p>
polite wartet, bis die Sprachausgabe eine Pause macht; assertive unterbricht sofort und sollte echten Ausnahmefällen vorbehalten bleiben. Das zugehörige Erfolgskriterium ist 4.1.3 Statusmeldungen (Level AA).
Typische Einsatzbereiche:
Selbst gebaute Bedienelemente ohne native Entsprechung, etwa Registerkarten oder Baumansichten
Dialoge und Overlays
Aufklappbare Bereiche und Menüs
Nachgeladene Inhalte in Einzelseiten-Anwendungen
Ergänzende Beschriftungen in komplexen Formularen
Grundregeln:
Native HTML-Elemente bevorzugen. Ein
<button>bringt Rolle, Name, Fokus und Tastaturbedienung von sich aus mitVorhandene Semantik nicht überschreiben
Tastaturbedienung und Fokusverwaltung immer selbst umsetzen
Zustände bei jeder Änderung aktualisieren. Ein
aria-expanded="false", das nach dem Aufklappen stehen bleibt, ist schlimmer als keinesFür erprobte Muster den ARIA Authoring Practices Guide des W3C heranziehen, statt selbst zu konstruieren
