UX-Glossar · engl. ARIA
ARIA
ARIA ist ein W3C-Standard, der HTML um Rollen, Zustände und Eigenschaften ergänzt. So erfahren Screenreader, was ein Element ist und wie es sich gerade verhält.
Stell dir vor, ein Team baut für eine Website ein eigenes Ausklappmenü aus einfachen div-Elementen. Mit der Maus funktioniert alles. Ein Screenreader liest aber nur „Produkte“ vor, ohne zu sagen, dass es sich um einen Button handelt oder ob das Menü offen ist. Mit der Tastatur lässt es sich gar nicht öffnen.
Um solche Lücken zu schließen, gibt es ARIA. Und genau hier passieren auch viele Fehler.
Einfach erklärt
ARIA steht für „Accessible Rich Internet Applications“, offiziell WAI-ARIA. Es ist ein Standard des W3C, also des Gremiums, das Webstandards festlegt. ARIA ergänzt HTML um zusätzliche Attribute, die assistiven Technologien wie einem Screenreader erklären, was ein Element ist und in welchem Zustand es sich befindet. Die aktuelle Empfehlung ist WAI-ARIA 1.2 aus dem Jahr 2023.
Ein Vergleich aus dem Alltag: ARIA funktioniert wie ein Etikett auf einer Schachtel. Das Etikett sagt „Werkzeug“, aber es legt kein Werkzeug hinein. Steht auf der Schachtel etwas, das nicht drin ist, wird es für alle, die sich auf das Etikett verlassen, ärgerlich.
Rollen, Zustände und Eigenschaften
ARIA arbeitet mit drei Bausteinen:
- Rollen sagen, was ein Element ist, etwa
role="dialog"oderrole="tab". - Zustände beschreiben, was sich ändern kann, etwa
aria-expanded="true"für ein geöffnetes Menü. - Eigenschaften liefern zusätzliche Informationen, etwa
aria-labelfür einen Namen, wenn kein sichtbarer Text vorhanden ist.
Wichtig: ARIA verändert nur, was assistive Technik ankündigt. Verhalten oder Tastaturbedienung bringt es nicht mit. Wer einem div die Rolle „button“ gibt, muss Fokus und Tastatursteuerung selbst nachbauen.
Die erste Regel von ARIA
Daraus folgt die oft zitierte erste Regel: Wenn es ein natives HTML-Element mit der benötigten Bedeutung und Funktion gibt, nutze es, statt ein anderes Element mit ARIA umzudeuten. Der ARIA Authoring Practices Guide des W3C fasst das sinngemäß so zusammen: Lieber gar kein ARIA als falsches ARIA. Die Auswertung „WebAIM Million“ fand 2026 auf Startseiten mit ARIA im Schnitt mehr erkannte Fehler als auf Seiten ohne, wobei das keinen ursächlichen Zusammenhang beweist.
Ein Beispiel
Ein Beispiel: Das Ausklappmenü aus dem Einstieg bekommt zuerst nur role="button". Der Screenreader sagt jetzt „Button“, aber Enter und Leertaste tun nichts.
Die bessere Lösung: Das Team ersetzt das div durch ein echtes button-Element und ergänzt nur aria-expanded, das beim Öffnen auf „true“ wechselt. Fokus und Tastatur funktionieren automatisch, und der Zustand wird korrekt angesagt.
In der Praxis
- Starte mit nativem HTML. Buttons, Links, Formularfelder und Überschriften bringen Bedeutung und Tastaturbedienung schon mit.
- Halte Versprechen ein. Jede Rolle, die du vergibst, verlangt das passende Verhalten. Ohne Tastatursteuerung ist sie eine falsche Ankündigung.
- Teste mit echter Technik. Tools wie axe DevTools finden ungültige Attribute, ein kurzer Test mit einem Screenreader zeigt, wie es sich anhört. Mehr Methoden im Artikel Accessibility-Prüfung: Werkzeuge und Methoden für UX-Designer.
Verwandte Begriffe
Screenreader, Barrierefreiheit, WCAG, Alternativtext