Inhaltsverzeichnis
Einleitungstext zum Thema WAI-ARIA
Dieser Text enthält viele technische Begriffe und richtet sich hauptsächlich an Webentwicklende und Menschen, die mit HTML5 vertraut sind. Wir beziehen uns im Text auf die gerade aktuelle Version von WAI-ARIA 1.2.
Dynamische und interaktive Webinhalte gehören längst zum Arbeitsalltag vieler Menschen. Doch gerade dort, wo JavaScript die Oberfläche ständig verändert, kommen Screenreader und andere Hilfstechnologien an ihre Grenzen. Hier setzt WAI an, die Web Accessibility Initiative. Sie ist ein technischer Standard des World Wide Web Consortium (W3C). Die WAI-ARIA list eine Spezifikation der WAI und legt fest, wie Entwickelnde und Frameworks semantische Informationen ergänzen können, damit auch komplexe Webanwendungen zugänglich bleiben.
WAI-ARIA schließt Lücken, wo HTML selbst keine geeigneten Mittel bietet. Sie beschreibt Rollen, Zustände und Eigenschaften, die assistive Technologien verstehen können. So wird zum Beispiel ein Button, der visuell als Schalter dargestellt wird, auch tatsächlich als solcher erkannt.
Ziel und Bedeutung
Ziel von WAI-ARIA ist es, die semantische Bedeutung von interaktiven Elementen für assistive Technologien zugänglich zu machen, insbesondere bei dynamischen Anwendungen wie Formularen, Tabs, Modalen, Slidern oder Menüs. Während HTML5 bereits viele semantische Elemente bereitstellt geht WAI-ARIA weiter:
- Sie ermöglicht die nachträgliche Ergänzung von Semantik, wenn HTML-Strukturen allein nicht ausreichen.
- Sie hilft, Zustände und Veränderungen (etwa „aktiv“, „ausgeblendet“, „ausgewählt“) maschinenlesbar zu machen.
- Sie unterstützt die Navigation in komplexen Strukturen, indem Beziehungen zwischen Elementen beschrieben werden können.
Richtiger Einsatz von WAI-ARIA
WAI-ARIA ist ein umfangreiches Werkzeug, aber falsch angewendet führt es schnell zu Problemen. Eingeschränkte Nutzende werden dann eher behindert statt unterstützt. Daher gelten einige grundlegende Regeln, die als Best Practices anerkannt sind.
Semantik vor WAI-ARIA
WAI-ARIA ist kein Ersatz für HTML-Semantik. Ein korrektes <button> ist immer besser als ein <div role=“button“> . WAI-ARIA ergänzt nur dort, wo HTML keine ausreichende Bedeutung liefern kann, etwa bei eigenen Komponenten oder komplexen Widgets.
Keine doppelte Semantik
Wenn ein HTML-Element bereits eine Rolle hat, darf sie nicht durch role überschrieben werden. Beispiel: Ein <button role=“link“ führt zu widersprüchlichen Ansagen eines Screenreaders, weil die native und die erzwungene Rolle konkurrieren.
WAI-ARIA-Attribute müssen dynamisch gepflegt werden
Zustände wie aria-expanded, aria-checked oder aria-hidden müssen den aktuellen Zustand widerspiegeln. Diese Aktualisierung erfolgt dann, wenn beim Bedienelement ein Statuswechsel ausgelöst wird. Entwickelnde müssen daher sicherstellen, dass Interaktionen wie bspw. das Öffnen eines Akkordeons auch programmgesteuert den entsprechenden ARIA-Wert anpassen. Bleibt beispielsweise ein Akkordeon visuell geöffnet, aria-expanded jedoch auf false, erhält der Screenreader veraltete Informationen und meldet weiterhin „eingeklappt“, obwohl der Inhalt sichtbar ist.
Beziehung herstellen, nicht nur beschreiben
Aria-labelledby und aria-describedby sind oft aria-label vorzuziehen, weil sie Beziehungen zwischen sichtbarem und unsichtbarem Text herstellen. So bleibt der Kontext erhalten und redundante Beschriftung wird vermieden. Aria-label eignet sich vor allem dort, wo es keinen sinnvollen sichtbaren Text gibt.
Verstecken mit Bedacht
Aria-labelledby und aria-describedby sind oft aria-label vorzuziehen, weil sie Beziehungen zwischen sichtbarem und unsichtbarem Text herstellen. So bleibt der Kontext erhalten und redundante Beschriftung wird vermieden. Aria-label eignet sich vor allem dort, wo es keinen sinnvollen sichtbaren Text gibt.
Prüfen in realen Umgebungen
Assistive Technologien interpretieren WAI-ARIA unterschiedlich. Daher ist das Testen mit Screenreadern wie beispielsweise: NVDA, JAWS, VoiceOver oder TalkBack unverzichtbar. Automatische Tools können helfen, ersetzen aber keine echte Nutzungsprüfung.
Überblick über zentrale WAI-ARIA-Attribute
Die folgende Übersicht erläutert einige wichtige Rollen und Attribute in WAI-ARIA 1.2 und erklärt ihren Zweck in einfachen Worten.
| Kategorie | Attribut/Rolle | Beschreibung | Beispielhafte Anwendung |
|---|---|---|---|
| Struktur und Navigation | role=“navigation“ | Kennzeichnet einen Bereich mit Navigationslinks. | Hauptmenü, Footer-Navigation |
| Struktur und Navigation | role=“banner“ | Oberer Seitenbereich, meist mit Logo oder Titel. | Kopfzeile einer Website |
| Struktur und Navigation | role=“main“ | Hauptinhalt der Seite, einzigartig pro Seite. | Inhaltsbereich eines Artikels |
| Struktur und Navigation | role=“contentinfo“ | Fußbereich mit Impressum, Kontakt etc. | Seitenfooter |
| Struktur und Navigation | role=“region“ + aria-label | Beschrifteter Inhaltsabschnitt. | „Ergebnisse der Suche“ |
| Widgets und Interaktion | role=“button“ | Kennzeichnet klickbares Steuerelement. | Custom-Button auf <div> |
| Widgets und Interaktion | role=“dialog“ + aria-modal=“true“ | Modales Fenster; blockiert Hintergrund. | Login-Dialog |
| Widgets und Interaktion | role=“tablist“, role=“tab“, role=“tabpanel“ | Struktur für Reiter-Navigation. | Registerkarten |
| Widgets und Interaktion | role=“menu“, role=“menuitem“ | Menü oder Kontextmenü. | Dropdown in App |
| Widgets und Interaktion | role=“checkbox“, aria-checked | Kontrollkästchen mit Zustand. | „Ich stimme zu“ |
| Widgets und Interaktion | role=“switch“ | Umschalter zwischen zwei Zuständen. | Dark-Mode-Schalter |
| Status und Hinweise | role=“alert“ | Sofortige, wichtige Meldung. | Fehlermeldung bei Formular |
| Status und Hinweise | role=“status“ | Informative Änderung ohne Fokusänderung. | „Speichern abgeschlossen“ |
| Status und Hinweise | aria-live=“polite“ / „assertive | Bereich mit dynamischen Inhalten. | Chatnachrichten, Ladezustände |
| Status und Hinweise | aria-busy=“true“ | Bereich wird gerade aktualisiert. | Während eines Ladevorgangs |
| Beschriftung und Beziehung | aria-label | Unsichtbare Kurzbeschreibung. | Symbol-Button ohne Text |
| Beschriftung und Beziehung | aria-labelledby | Verknüpft mit sichtbarem Label. | Überschrift beschreibt Widget |
| Beschriftung und Beziehung | aria-describedby | Verweist auf erläuternden Text. | Hilfetext für Eingabefeld |
| Beschriftung und Beziehung | aria-details | Verknüpft ergänzende Informationen. | Verweis auf lange Beschreibung |
| Zustände und Eigenschaften | aria-expanded | Zeigt an, ob ein Bereich geöffnet ist. | Akkordeon |
| Zustände und Eigenschaften | aria-hidden | Verbirgt Element vor Screenreader. | Unsichtbare Inhalte |
| Zustände und Eigenschaften | aria-pressed | Zustand eines Toggle-Buttons. | „Favorit aktiv“ |
| Zustände und Eigenschaften | aria-disabled | Element ist deaktiviert, aber sichtbar. | Inaktive Schaltfläche |
| Zustände und Eigenschaften | aria-required | Feld muss ausgefüllt werden. | Pflichtfeld in Formular |
| Zustände und Eigenschaften | aria-invalid | Markiert fehlerhafte Eingabe. | „E-Mail ungültig“ |
| Zustände und Eigenschaften | aria-current | Aktives oder ausgewähltes Element. | Aktueller Menüpunkt |
Checkliste zum Einsatz von ARIA Attributen
Grundprinzipien
- Weniger ist mehr: ARIA nur einsetzen, wenn HTML keine passende Lösung bietet.
- Semantik testen: Screenreader-Ausgabe prüfen – stimmt sie mit der visuellen Darstellung überein?
- Pflege sicherstellen: Bei jeder dynamischen Änderung (Ein- oder Ausblenden, Öffnen, Umschalten) müssen ARIA-Zustände aktualisiert werden.
- Dokumentation führen: Festlegen, welche ARIA-Attribute im Projekt erlaubt oder untersagt sind und warum.
Erweiterte Prüfpunkte
- Richtige Rollen verwenden: Prüfen, ob die zugewiesene role-Eigenschaft der tatsächlichen Funktion entspricht (zum Beispiel role=“dialog“ nur für echte Dialoge).
- Zustände korrekt setzen: Attribute wie aria-expanded, aria-pressed oder aria-selected müssen den aktuellen UI-Zustand widerspiegeln.
- Beziehungen prüfen: Wenn aria-labelledby oder aria-describedby verwendet wird, müssen die referenzierten IDs existieren und eindeutig sein.
- ARIA und Fokus gemeinsam denken: Ein Element mit role=“dialog“ oder role=“alertdialog“ muss beim Öffnen den Tastaturfokus korrekt setzen.
- Verstecken mit Bedacht: aria-hidden=“true“ darf nicht auf sichtbare, relevante Inhalte angewendet werden. Sichtbar bedeutet nicht automatisch zugänglich.
- Konsistenz über Komponenten sicherstellen: Gleiche Komponenten (zum Beispiel Akkordeons oder Tabs) müssen ARIA-Attribute konsistent verwenden.
- Frameworks prüfen: Überprüfen, welche ARIA-Werte von Frameworks wie React, Angular oder Vue automatisch gesetzt werden und welche ergänzt werden müssen.
- Test mit Assistive Technologien: Die Umsetzung immer mit mindestens einem Screenreader und Tastatur testen, um vorhersehbares Verhalten sicherzustellen.
- Keine widersprüchliche Semantik: Native HTML-Rollen dürfen nicht durch role überschrieben werden (zum Beispiel kein <button role=“link“>).
- ARIA und Live-Regionen prüfen: aria-live-Bereiche gezielt einsetzen und sicherstellen, dass Statusmeldungen tatsächlich vorgelesen werden.
Weitere Informationen
- Offizielle Spezifikation: W3C Recommendation – Accessible Rich Internet Applications (WAI-ARIA) 1.2: https://www.w3.org/TR/wai-aria/
- Begleitdokument: ARIA Authoring Practices Guide (APG): https://www.w3.org/WAI/ARIA/apg