ARIA-Attribute

Definition: ARIA-Attribute (Accessible Rich Internet Applications; WAI-ARIA) sind HTML-Attribute die der W3C Web Accessibility Initiative (WAI) entstammen und semantische Informationen über die Rolle, den Zustand und die Eigenschaften von Interface-Elementen für assistive Technologien wie Screen-Reader bereitstellen. ARIA überbrückt die Lücke zwischen dynamischen JavaScript-gesteuerten UI-Komponenten (die HTML-Semantik fehlt) und den Zugänglichkeitsbedürfnissen von Nutzern mit Behinderungen. ARIA-Attribut-Kategorien: Rollen (roles): beschreiben die semantische Funktion eines Elements (role="button"; role="navigation"; role="dialog"; role="alert"; role="tab"); Eigenschaften (properties): beschreiben permanente Merkmale (aria-label="Menü schließen"; aria-required="true"; aria-controls="panel-1"); Zustände (states): beschreiben veränderliche Zustände (aria-expanded="true/false"; aria-checked="true/false/mixed"; aria-disabled="true"; aria-hidden="true"). Erste Regel der ARIA-Nutzung (W3C): «No ARIA is better than Bad ARIA» – verwende native HTML-Elemente wenn möglich; ein <button>-Element ist besser als <div role="button"> weil natives HTML automatisch Tastaturinteraktion, Fokusierbarkeit und Semantik mitbringt ohne zusätzliches JavaScript. ARIA-Unterstützung durch Browser und Screen-Reader: ARIA-Attribute werden durch den Accessibility-Tree des Browsers an assistive Technologien weitergegeben; Unterstützung variiert je nach Browser/Screen-Reader-Kombination; zuverlässig: Chrome + NVDA; Safari + VoiceOver; Firefox + NVDA.

Erläuterung

WAI-ARIA (Web Accessibility Initiative – Accessible Rich Internet Applications) wurde durch das W3C entwickelt als Antwort auf die zunehmende Verbreitung von JavaScript-gesteuerten Web-Anwendungen (AJAX, SPA-Frameworks) die keine native HTML-Semantik hatten und für Screen-Reader-Nutzer damit vollständig unzugänglich waren. Die erste WAI-ARIA-Spezifikation wurde 2008 als W3C-Recommendation veröffentlicht; WAI-ARIA 1.1 folgte 2017; WAI-ARIA 1.2 ist seit 2023 final. Léonie Watson (Accessibility-Beraterin; Mitglied des W3C Advisory Board; Co-Chair des Web Platform Working Group) beschrieb ARIA als «Rettungsring für schlechtes HTML» – das Prinzip das die gesamte ARIA-Community prägt: ARIA kompensiert fehlende semantische Struktur, sollte aber nie ein Ersatz für korrekte HTML-Semantik sein. Das ARIA Authoring Practices Guide (APG; W3C WAI) dokumentiert Implementierungsmuster für alle gängigen UI-Widgets (Accordions, Carousels, Dialogs, Tab Panels, Treeviews) mit vollständigen Keyboard Interaction Patterns und ARIA-Annotationen; dieser Guide ist der De-facto-Standard für barrierefreie Custom-Components. Scott O'Hara und Sarah Higley (beide aus der Accessibility-Community) haben bedeutende praktische Forschungsarbeiten zu spezifischen ARIA-Implementierungen veröffentlicht, die zeigen dass viele verbreitete ARIA-Implementierungen tatsächlich Barrieren erzeugen statt sie zu beseitigen – insbesondere übermäßiger ARIA-Einsatz der den Accessibility-Tree aufbläht und Screen-Reader-Nutzern redundante oder verwirrende Informationen liefert.

Wichtige ARIA-Attribute und ihre Verwendung

Benennungs-Attribute (Naming): aria-label: direkte Textbeschriftung eines Elements wenn kein sichtbarer Text vorhanden; Beispiel: <button aria-label="Menü schließen"><svg ...></svg></button>; für Icon-Buttons ohne sichtbaren Text; aria-labelledby: Referenz auf ID eines anderen Elements als Beschriftung; Beispiel: <div role="dialog" aria-labelledby="dialog-title">; verknüpft Dialog mit sichtbarer Überschrift; aria-describedby: Referenz auf zusätzliche Beschreibung; Beispiel: <input aria-describedby="password-hint"><p id="password-hint">Mindestens 8 Zeichen</p>; Screen-Reader liest Label + kurze Pause + Beschreibung; Priorität: native HTML <label>-Element immer bevorzugen; aria-label/aria-labelledby nur wenn Label nicht im DOM sichtbar sein kann oder wenn Verknüpfung über mehrere Elemente nötig ist; Accessible Name Computation: Browser berechnet Accessible Name nach spezifischer Priorität (aria-labelledby → aria-label → native label → alt → title)
Zustands-Attribute (States): aria-expanded: für ausklappbare Elemente (Accordions, Dropdowns, Submenus); true = geöffnet; false = geschlossen; an dem Element platzieren das die Aktion auslöst (Button), nicht am Panel; <button aria-expanded="false" aria-controls="menu">Menü</button>; aria-checked: für Checkboxen, Radio-Buttons, Switches; true/false/mixed; native HTML-Elemente bevorzugen; aria-checked für Custom-Checkboxen mit role="checkbox"; aria-disabled: Element ist visuell sichtbar aber nicht interaktiv; anders als HTML disabled: fokusierbar bleibt für Screen-Reader; aria-hidden: versteckt Element vollständig vom Accessibility-Tree; für dekorative Elemente: <svg aria-hidden="true">; für ausgeblendete modale Overlays: aria-hidden="true" auf den Seitenhintergrund wenn Modal offen; Vorsicht: aria-hidden="true" auf fokusierbares Element = Barrierefreiheitsproblem; aria-selected: für Tabs, Listbox-Optionen, Treeview-Items; aria-current: für aktuelle Seite in Navigation (<a aria-current="page">) oder aktiven Schritt in einem Prozess
Live Regions und dynamische Inhalte: Problem ohne Live Regions: wenn JavaScript Seiteninhalt dynamisch ändert (Suchergebnisse; Fehlermeldungen; Ladezustände) erfährt Screen-Reader-Nutzer die Änderung nicht wenn er/sie nicht erneut navigiert; Lösung: ARIA Live Regions; aria-live="polite": Ankündigung nach Abschluss der aktuellen Leseaufgabe; für Statusmeldungen, Suchergebnisse; aria-live="assertive": sofortige Unterbrechung der aktuellen Ausgabe; nur für kritische Fehlermeldungen; role="status": implizit aria-live="polite" + aria-atomic="true"; für nicht-kritische Statusmeldungen; role="alert": implizit aria-live="assertive" + aria-atomic="true"; für Fehlermeldungen; Implementierungs-Best-Practice: Live-Region-Container beim Seitenload im DOM vorhanden sein (leer); Inhalt dynamisch einfügen per JavaScript; nicht: Container dynamisch ins DOM einfügen (Screen-Reader erkennt erst Live Regions die beim Laden vorhanden waren); aria-atomic="true": gesamter Inhalt der Region wird bei Änderung vorgelesen; aria-atomic="false": nur geänderte Teile werden vorgelesen

Häufige ARIA-Fehler und Landmark-Rollen

Häufige ARIA-Fehler die Barrieren erzeugen: Fehler 1 – redundante ARIA-Rollen: <button role="button"> – unnötig; native Elemente haben Rollen bereits; <nav role="navigation"> – doppelt; Fehler 2 – ARIA auf nicht-interaktiven Elementen ohne Tastatur-Event: <div role="button"> ohne tabindex="0" und ohne keydown-Event (Enter/Space) → klickbar mit Maus aber nicht mit Tastatur; Fehler 3 – aria-hidden auf fokusierbaren Elementen: <button aria-hidden="true"> – Element für Screen-Reader versteckt aber per Tab fokussierbar; erzeugt «unsichtbare» fokussierbare Elemente; Fehler 4 – fehlendes aria-expanded-Update: Toggle-Button ändert aria-expanded nicht synchron mit der visuellen Änderung; Fehler 5 – ARIA-Labels auf Container statt interaktiven Elementen: aria-label auf <div> statt auf enthaltenen <a> oder <button>; Fehler 6 – Überflüssige aria-required bei nativem required: HTML required-Attribut reicht; beide setzen erzeugt doppelte Ansage; Fehler 7 – Live Region sofort füllen: wenn Inhalt bei Load bereits in Live Region ist wird er nicht angekündigt; nur dynamische Änderungen werden angesagt
Landmark-Rollen für Seitenstruktur: HTML5-Elemente mit impliziten ARIA-Rollen (bevorzugen): <header> = role="banner"; <nav> = role="navigation"; <main> = role="main"; <footer> = role="contentinfo"; <aside> = role="complementary"; <form> = role="form" (wenn aria-label oder aria-labelledby vorhanden); <section> = role="region" (nur mit zugänglichem Namen); Mehrere gleichnamige Landmarks: wenn mehrere <nav> auf einer Seite: mit aria-label differenzieren (<nav aria-label="Hauptnavigation">; <nav aria-label="Breadcrumb">); Screen-Reader-Nutzer navigieren per Landmark-Shortcuts (NVDA: D = nächster Landmark; R = nächste Region); klare Landmark-Struktur = schnellere Navigation; Prüfung: NVDA + Chrome: Insert+F7 zeigt Landmarks-Liste; axe DevTools erkennt fehlende oder doppelte Landmark-Strukturen
Tastatur-Interaktionsmuster für Custom Widgets: Tab-Panel-Pattern (ARIA APG): Tabs: role="tablist"; role="tab"; aria-selected; aria-controls; tabindex; Tab-Panels: role="tabpanel"; aria-labelledby; Keyboard: Tab aktiviert Fokus auf Tab-Gruppe; Pfeiltasten navigieren zwischen Tabs; Enter/Space aktiviert Tab; Dialog-Pattern: role="dialog" + aria-modal="true"; aria-labelledby auf Dialog-Titel; Fokus-Management: Fokus beim Öffnen auf erstes fokusierbares Element; Fokus beim Schließen zurück auf auslösenden Button; Escape schließt Dialog; Fokus-Trap innerhalb des Dialogs (Tab bleibt im Dialog); Combobox-Pattern (Autocomplete): role="combobox"; aria-expanded; aria-autocomplete; aria-controls → role="listbox"; role="option"; aria-selected; vollständige Spezifikation im ARIA APG (www.w3.org/WAI/ARIA/apg)

Praxistipp: Befolgen Sie die erste Regel der ARIA-Nutzung konsequent: Prüfen Sie vor jedem ARIA-Einsatz ob ein natives HTML-Element dieselbe Funktion erfüllen kann. <button> statt <div role="button">; <select> statt Custom-Dropdown mit role="combobox"; <input type="checkbox"> statt <div role="checkbox">. Wenn Custom-Widgets unvermeidlich sind: implementieren Sie das entsprechende Muster aus dem ARIA Authoring Practices Guide vollständig – inklusive aller Keyboard Interactions. Testen Sie anschließend immer mit einem echten Screen-Reader: NVDA (kostenlos für Windows) + Chrome genügt für 80% aller praktisch relevanten Tests.