Hartnäckig hält sich das Gerücht, für echte Barrierefreiheit braucht es ARIA-Rollen und Attribute. Je nachdem wen man fragt lösen diese entweder jedes vorhandene Problem wie von Zauberhand auf oder, egal was man tut: ohne geht es nicht. Beides ist falsch.
In diesem Beitrag möchte ich erklären, wieso das so ist. Was ist eigentlich ARIA, was ist der Unterschied zwischen Rollen und Attributen und wofür sollte man sie einsetzen?
Wer oder was ist ARIA?
ARIA ist eine technische Spezifikation, die von Mitgliedern der Web Accessibility Initiative (kurz WAI) entwickelt wurde. Sie soll Assistenzsysteme, vor allem sehbehinderter Menschen, beim Verstehen einer Website unterstützen. Das heißt, richtig eingesetzte ARIA-Attribute können die Nutzung von Screenreadern vereinfachen. Seit März 2014 ist es sogar ein empfohlender Webstandard des W3C.
Versucht man zu beschreiben, was ARIA macht, dann kann man das wohl am deutlichsten so zusammenfassen: Die vergebenen Rollen und Attribute machen aus einer statischen Website eine echte Anwendung. Wann immer also der Nutzer eine bestimmte Art mit der Internetseite interagieren kann – Inhalte ein- und ausblenden, in Slidern weiterblättern oder Formulare ausfüllen – kann mithilfe von ARIA exakt beschrieben werden wie diese Interaktion erfolgt, welche Auswirkungen sie hat und wie der aktuelle Zustand ist.
Bestandteile von ARIA sind Rollen, die eine grobe Klassifizierung der Elemente beschreiben, und Attribute, die diese verfeinern und individuelle Eigenschaften definieren. Schauen wir uns beide genauer an.
ARIA-Rollen
Rollen dienen, wie schon gesagt, einer groben Klassifizierung von Elementen. Dies soll Screenreadern und anderen Assistenzsystemen die Möglichkeit geben, zu erkennen, wie mit dem Element interagiert werden kann. Welche Tastatur-Shortcuts werden funktionieren? Wichtig ist aber, dass man sich an diesen Standard dann auch hält. Zum Beispiel kann ein Link immer mit der Enter-Taste ausgelöst werden, ein Button mit Enter und Leertaste. Werden Elemente also mit den jeweiligen Rollen versehen, dann müssen sie diese Interaktion auch zulassen. Bei Bedarf muss sie mit JavaScript bereitgestellt werden.
Über die korrekte Verwendung von Link und Button habe ich schon einmal in meinem Blog geschrieben.
Es gibt grundsätzlich 4 verschiedene Rollen
- Landmark Roles
- Widget Roles
- Document Structure Roles
- Live Regions
Ausgezeichnet werden alle im Prinzip gleich über das Attribut „role“ an jedem HTML-Element. Unterschiede gibt es aber darin, wie der Browser jeweils damit umgeht. Deshalb möchte ich kurz die Unterschiede erklären.
Landmark Roles
Landmark Roles beschreiben bestimmte Bereiche einer Seite, so wie der namensgebende Grenzstein. Häufig sind diese Bereiche interaktiv, denken Sie an ein Formular oder eine Suche. Landmarks können über ein eigenes Tastaturkürzel der Screenreader angesprungen werden. Dadurch kann man schnell zu den einzelnen Bereichen einer Seite navigieren, ohne sich jedes Mal wieder durch das Menü hangeln zu müssen.
Einige Landmark Roles gibt es inzwischen auch als eigene HTML-Tags. <header>, <footer> oder <main> waren früher nur über die entsprechende Rolle definiert.
Sind die Landmark Roles korrekt ausgezeichnet oder wurde direkt ihr passendes HTML-Element verwendet, dann kümmert sich der Browser um die richtige Interaktion. Vielen ist vielleicht schon einmal aufgefallen, dass die Betätigung der Enter-Taste ein Formular abschickt. Das funktioniert auch, wenn man gerade nicht den dafür vorgesehenen Button fokusiert hat. Das ist möglich, weil man das Formular und den Button korrekt auszeichnet.
Widget Roles
Widget Roles beschreiben einfache oder zusammengesetzte interaktive Elemente. Wie das Element mit der Tastatur bedient werden kann ist vorgegeben, muss aber selbst implementiert werden. Beispiele sind hier ein Akkordeon oder die Anzeige eines Fortschritts. Eine Rolle sollte nur dann vergeben werden, wenn Sie sich auch an die Regeln zur Bedienung halten.
Document Structure Roles
Wie der Name schon sagt, beschreiben Document Strukture Roles eher strukturelle Bereiche einer Seite, die meist nicht interaktiv sind. Viele dieser Rollen gibt es auch als HTML-Elemente. Sie dienen der semantischen Strukturierung einer Website. Das heißt, anhand der Rolle soll man genau erkennen können, welche Bedeutung das Element hat. Beispiele sind paragraph (Textabsätze), image (Bild) oder auch heading (Überschrift).
Live Regions
Live Regions werden immer dann eingesetzt, wenn sich der Inhalt von Bereichen während der Nutzung der Seite ändern kann. Diese Änderung wird vom Screenreader priorisiert vorgelesen. Mann kann dabei steuern, ob sogar gerade gesprochener Text unterbrochen wird, wenn die Mitteilung besonders wichtig ist. Besonders gut geeignet sind diese Bereiche für Erfolge oder Fehler bei der Verwendung von Formularen. Auch ein ablaufender Timer ist eine gute Live Region.
ARIA-Attribute
Im Gegensatz zu Rollen beschreiben ARIA-Attribute die individuellen Eigenschaften eines Elementes. Ähnlich wie bei Rollen wird zwischen zwei verschiedenen Varianten unterschieden. Diese werden aber auch hier mit derselben Syntax ausgezeichnet. Für die Nutzung durch Entwickler und Autoren ist der Unterschied deshalb nur selten relevant. Um zu verstehen, wie Attribue eingesetzt werden, werde ich trotzdem kurz auf beide eingehen.
States (Status-Attribute)
Status unterliegen möglicherweise Veränderungen während der Nutzung einer Website. Zum Beispiel kann eine Checkbox mit aria-checked ausgezeichnet werden, wenn diese gerade aktiv ist. Der Nutzer kann den Zustand der Checkbox und damit das Attribut aber jederzeit ändern.
Properties (Eigenschaften)
Eigenschaften können normalerweise nicht geändert werden. Zum Beispiel kann über das Attribut aria-labeledby einem Element eine Textalternative in Form eines anderen HTML-Elementes mitgegeben werden. Diese Zuordnung ändert sich normalerweise nicht.
Regeln zur Anwendung von ARIA-Rollen und -Attributen
Grundsätzlich können ARIA-Attribute an allen Elementen eingesetzt werden. Trotzdem haben sich die folgenden fünf Regeln entwickelt, die den Einsatz klar machen und dafür sorgen, dass die Assistenzsysteme sauber mit den gewählten Attributen arbeiten können.
- Verwende ARIA nur, wenn es kein natives HTML-Element oder Attribut gibt!
- Ändere nicht die Semantik von HTML-Elementen, wenn nicht notwendig!
- Alle interaktiven ARIA-Elemente müssen mit der Tastatur bedienbar sein!
- Verstecke keine fokussierbaren Elemente!
- Alle fokussierbaren Elemente müssen einen zugänglichen Namen haben!
Nützliches
Als Entwickler kommt man häufig in die Situation, dass man bestimmte Elemente vor dem Screenreader verstecken möchte. Wenn diese allerdings visuell sichtbar sein sollen oder aus anderen Gründen nicht mit einem display:none versehen werden können, dann hilft aria-hidden=true.
Viele Elemente wie Akkordeons oder Slider sind inzwischen zum Standard in allen Internetseiten geworden. Wie bereits erzählt, gibt es dafür passende Widget Roles. Da man sich um deren Implementierung allerdings selbst kümmern muss, ist es wichtig, dass man die Anforderungen an Markup und Bedienung kennt. Eine super Anlaufstelle ist hier die Bibliothek des W3C, die mit Definitionen und Beispielen verschiedene Inhaltselemente vorgibt.
ARIA Rollen und Attribute – Fazit
ARIA-Rollen sind sehr nützlich, wenn man sehr interaktive Seiten hat. Was sie aber nicht tun, ist eine schlecht geschriebene Seite barrierefrei zu machen. Achten Sie beim Schreiben ihres HTML immer darauf, ob es nicht schon ein passendes HTML-Element gibt und lassen Sie dann die unnötige Rollendefinition weg. Ich sehe oft, dass Elementen dieselbe Rolle noch einmal mitgegeben wird. Das ist nicht nur unnötig, sondern verschlechtert auch die Ladezeit Ihrer Internetseite.