Was ist WAI-ARIA, was tut es, und was tut es nicht?

Am 20.03.2014 veröffentlichte das W3C WAI-ARIA endlich als Version 1.0. Nach vielen jahren der Entwicklung, des Testens und Fine-Tunings ist WAI-ARIA nun ein Webstandard.

Ich werde jedoch häufig gefragt: Was ist WAI-ARIA, und wie kann es mir als Webentwickler helfen? Und was kann es nicht?

Ich habe in den letzten Jahren immer wieder festgestellt, dass von falschen Voraussetzungen ausgegangen wird, was die Fähigkeiten und beabsichtigte Benutzung von WAI-ARIA angeht. Dies führt dann häufig zu Seiten, die weniger zugänglich sind als sie es wären, wenn WAI-ARIA überhaupt nicht zum Einsatz gekommen wäre.

Zusätzlich schrieb Jared W. Smith vom WebAIM-Projekt am 26.03. einen Blogbeitrag mit dem Titel „Accessibility Lipstick on a Usability Pig“ (Zugänglichkeits-Lippenstift für ein Benutzbarkeits-Schwein), in dem auf ein weiteres verwandtes Problem eingegangen wird: Obwohl die Seite von der Benutzerfreundlichkeit her absoluter Müll ist, wird so lange WAI-ARIA-Zuckerguss draufgestreut, bis die WCAG-Kriterien irgendwie erfüllt werden.

All diese Faktoren und eine Ermutigung durch Jason Kiss auf Twitter führten dazu, dass ich diesen längst überfälligen Blogbeitrag darüber schreibe, was WAI-ARIA ist, wobei es helfen kann, wann es benutzt werden sollte und – und das ist noch wichtiger – wann es nicht benutzt werden sollte. Ich verfasste ihn zunächst auf englisch und biete ihn hier jetzt in einer deutschen Übersetzung an.

So, nach langer Vorrede nun der Einstieg!

Was ist WAI-ARIA? 🔗

WAI-ARIA steht für den englischen Ausdruck „Web Accessibility Initiative – Accessible Rich Internet Applications“, also frei übersetzt Webbarrierefreiheitsinitiative (des W3C) – Zugängliche angereicherte Internetanwendungen. Es handelt sich dabei um einen Satz von semantischen Attributen, die Hilfstechnologien für Menschen mit Behinderungen (wie z. B. Bildschirmleseprogrammen für Blinde) dabei helfen, Markupkonstrukte auf Webseiten und -applikationen zu verstehen, die es nicht nativ in HTML gibt. Die zur Verfügung gestellten Informationen können so etwas Triviales sein wie das Kommunizieren des Zustands einer Schaltfläche oder eines Links, ob das Aktivieren weiteren Inhalt ein- oder ausblendet, oder auch so komplexe Widgets wie ein Hierarchiebaum oder ganze Menüsysteme.

Dies wird dadurch erreicht, dass man dem vorhandenen HTML 4.01 oder neuer bestimmte Rollen- und Zustandssattribute hinzufügt. Diese Attribute haben keinen Einfluss auf das Layout oder die vom Browser zur Verfügung gestellte Funktionalität, erweitern aber die Informationen, die der Browser an Hilfstechnologien übermittelt.

Ein Eckpfeiler von WAI-ARIA ist das Attribut role. Es weist den Browser an, der Hilfstechnologie mitzuteilen, dass das verwendete HTML-Element nicht das ist, wonach es aussieht, sondern etwas ganz anderes. Ursprünglich nur ein div-Element, kann es durch das Rollen-Attribut zu einem Container für eine Liste von Elementen einer Autovervollständigung werden. In diesem Fall ist die richtige zu verwendende Rolle „listbox“. Genauso wird ein Kind-Element, das ebenfalls ein div ist, zu einem einzelnen Element dieser Autovervollständigung, wofür die Rolle „option“ die Richtige ist. Zwei divs, aber durch die Rollen zwei völlig unterschiedliche Bedeutungen. Die Rollen sind übrigens stark ihren Entsprechungen aus Desktop-Programmen entlehnt.

Eine Ausnahme hiervon bilden lediglich die Rollen für Dokumentmarkierungen (Landmarks). Diese teilen der Hilfstechnologie lediglich mit, dass man jetzt an einer bestimmten Stelle im Dokument angekommen ist, ohne aber die eigentliche Bedeutung des Elements zu verändern. Mehr über Landmarks erfahrt ihr im englischen ARIA-Tipp #4. Wenn ihr HTML5 verwendet, könnt ihr auch native Elemententsprechungen verwenden.

Der zweite Eckpfeiler von WAI-ARIA sind Attribute für Zustände und Eigenschaften. Sie geben Auskunft über den Zustand von nativen Elementen oder WAI-ARIA-Widgets wie z. B. ob der Inhalt zu einem Element ein- oder ausgeklappt ist, ein Formularelement erforderlich ist, einem Widget ein Popup-Menü angeheftet ist und andere. Diese Attribute sind sehr dynamischer Natur und verändern ihre Werte natürlich im Laufe des Lebens einer Webapplikation. Sie werden normalerweise durch JavaScript-Code verändert.

Was ist WAI-ARIA nicht? 🔗

WAI-ARIA wurde nicht dazu entworfen, das Verhalten des Webbrowsers zu beeinflussen. Wenn ihr z. B. einem div die Rolle „button“ gebt, weiß der Browser im Gegensatz zum echten button-Element nichts von der Fokussierbarkeit durch die Tastatur oder davon, dass er beim Druck auf Leertaste oder Eingabe einen onClick-Handler ausführen soll. Auch andere Eigenschaften, die einem Button eigen sind, sind nicht im Browserverhalten vorhanden. Der Browser weiß nicht, dass ein div mit der Rolle „button“ eine Schaltfläche ist. Lediglich der Teil, der für die Kommunikation mit Hilfstechnologie zuständig ist, weiß darüber bescheid.

In der Konsequenz heißt dies, dass es in eurer Verantwortung liegt, die Fokussierbarkeit durch die Tastatur und andere Verhalensmuster, die denen von Desktop-Applikationen ähneln, sämtlichst händisch nachbauen müsst. Ein gutes Beispiel hierfür könnt ihr in meinem englischen Artikel über ARIA-Tabs nachlesen, in dem ich schrittweise erkläre, was dazu gehört, ein Widget, das es nicht in HTML gibt, zugänglich zu machen. Dazu gehört ein bestimmtes erwartetes Verhalten bei der Benutzung durch die Tastatur.

Wann sollte ich WAI-ARIA nicht benutzen? 🔗

Ja, das ist schon richtig so, dass dieser Abschnitt zuerst kommt! Denn die allererste Regel bei der Benutzung von WAI-ARIA lautet: Verwende es nicht, wenn du es nicht unbedingt musst und dein Ziel auch durch reine HTML-Elemente erreichen kannst. Je mehr du dich auf native HTML-Elemente stützen kannst, desto besser! Es gibt noch einige weitere Regeln, denen ihr folgen solltet und die ihr in diesem informellen englischen Dokument nachlesen könnt.

Der Fall von button-Elementen versus anklickbaren div- oder span-Elementen habe ich bereits erwähnt. Dies setzt sich auch bei Attributen fort. Das HTML5-Attribut „required“ sorgt automatisch bei einem nicht ausgefüllten Wert für eine Kennzeichnung als ungültige Eingabe durch den Browser, das Attribut aria-required tut dies nicht. Genauso wird der Zustand der Gültigkeit einer Eingabe „invalid“ kommuniziert, indem entweder durch bestimmte input type-Attribute oder dem pattern-Attribut eine automatische Evaluierung der Gültigkeit der Eingabe durch den Browser durchgeführt wird (Beispiel: <input type="email" required />). All dies muss bei der Verwendung der Entsprechungen der WAI-ARIA-Attribute von Hand durchgeführt werden, also eine Evaluierung der Eingabe und das Setzen von aria-invalid auf „true“ oder „false“. Gerade auf Mobilgeräten haben die verschiedenen input-Typen sogar noch andere Vorteile, indem z. B. für number, email, url usw. entsprechend passende Tastaturen eingeblendet werden, und man bekommt die Validierung der Eingabe frei Haus gleich mit und braucht dafür dann kein WAI-ARIA mehr. Eine Veranschaulichung findet sich auch in diesem Blogbeitrag über HTML5- und WAI-ARIA-Formulare, den ich geschrieben habe, nachdem ich hierüber 2011 einen Vortrag beim Multimedia-Treff in Köln (Link zu Youtube-Video) gehalten habe.

Glücklicherweise kommt diese Message inzwischen sogar bei Branchenriesen an. Google Maps verwendet in der neuesten Version z. B. echte button-Elemente anstatt anklickbarer divs und spans. Dank an Christian Heilmann, dass er dies rausgefunden und bei einem Accessibility-panel auf der Edge Conf (Link zum Youtube-Video) im März 2014 hervorgehoben hat!

Hier ist eine Liste der WAI-ARIA-Rollen, für die es Entsprechungen in HTML gibt und wo diese HTML-Elemente verwendet werden sollten, wann immer dies möglich ist: WAI-ARIA-RolleNatives ElementBemerkungenbuttonbuttonVerwendet type=“button“ wenn die Schaltfläche sich nicht wie eine submit-Schaltfläche verhalten sollcheckboxinput type=“checkbox“–radiogroup und radiofieldset/legend und input type=“radio“fieldset ist der Container, legend ist die Frage, auf die die Auswahlschalter die möglichen Antworten geben, und die input mit type „radio“ sind die eigentlichen Auswahlschaltercomboboxselect size=“1″Einzige Ausnahme greift, wenn ihr ein wirklich reichhaltiges Widget baut. Aber selbst dann ist combobox ein Tretminenfeld, das seinen eigenen Blogbeitrag rechtfertigen würde.listboxselect mit size größer als 1Einzige Ausnahme bildet das Erzeugen eines komplexen Widgets zur Autovervollständigungoptionoptionals Kinder von select-Elementen oder solchen mit Rolle combobox oder listboxlistul oder olnicht zu verwechseln mit listbox! Bei list handelt es sich um eine nicht interaktive Liste wie eine unsortierte oder eine sortierte Liste. Diese sollten immer bevorzugt werden. Screen Reader bekommen auch Verschachtelungen im Normalfall prima geregelt.spinbuttoninput type=“number“Wenn der Browser diese bereits unterstützt.linka mit href-AttributSollte nach meiner unmaßgeblichen Meinung niemals und unter keinen Umständen in einem HTML-Dokument verwendet werden!formformNiemand, den ich kenne, kann mir schlüssig erklären, warum diese Rolle sich überhaupt in der Spezifikation befindet. Ich vermute, es hat mit SVG und vielleicht noch EPUB zu tun. Der Grund für diese Duplizierung liegt darin, dass zum einen WAI-ARIA-Attribute nicht nur auf HTML, sondern auch auf SVG 2 und EPUB 3 angewendet werden können. Außerdem wurde WAI-ARIA ursprünglich zu einer Zeit entwickelt, als HTML 4.01 noch der vorherrschende Standard war und die Entwicklung von HTML5 ebenfalls erst begann. Die beiden Standards wurden dann parallel weiterentwickelt, und die HTML5-Entsprechungen bekamen, gerade bei den Attributen wie disabled, required usw. deutlich mehr vom Browser implementierte Funktionen hinzugefügt, die bei WAI-ARIA händisch nachgebildet werden müssen. Also sollten auch immer die HTML5-Attribute bevorzugt werden.

Eine Ausnahme hiervon tritt nur dann in Kraft, wenn ihr speziell noch HTML 4.01 oder gar XHTML 1.x bauen müsst. Dann müsst ihr aber eh die Validierung usw. von Hand einbauen. Bei HTML5 solltet ihr allerdings immer die Attribute disabled, required usw. verwenden anstatt der aria-disabled, aria-required, aria-invalid usw. Und ja, mir ist klar, dass ich hierin nicht mit einigen anderen Web-Zugänglichkeits-Experten übereinstimme, die empfehlen, grundsätzlich auch die WAI-ARIA-Attribute hinzuzufügen. Das Problem ist nämlich, dass dann trotzdem immer noch extra JavaScript-Code nötig ist, um die WAI-ARIA-Attribute mit den HTML5-Attributen und -Zuständen synchron zu halten.

Warum diese Verdoppelung? Warum kann der Browser nicht einfach auch auf die WAI-ARIA-Attribute so reagieren, wie er dies bei den HTML5-Attributen tut? 🔗

Diese Frage wird mir immer wieder gestellt. Die einfachste Antwort lautet: WAI-ARIA war nie dazu gedacht, das Verhalten des Browsers zu beeinflussen, sondern lediglich, um zusätzliche semantische Informationen an Hilfstechnologien weiterzugeben.Die längere antwortet lautet: WAI-ARIA-Attribute können auf HTML 4.01, XHTML 1.x und HTML5 angewendet werden. Die HTML5-Attribute können nur auf HTML5-Seiten angewendet werden und bringen eine ganze Palette von Browser-Funktionen mit, die in den Standards für diese Attribute definiert sind. Wenn die WAI-ARIA-Attribute auf einmal auch das Browserverhalten beeinflussen würden, wäre die Menge an Unstimmigkeiten enorm hoch. Um WAI-ARIA sauber zu halten, wurde irgendwann die Entscheidung getroffen, dass diese Attribute das Browserverhalten niemals und unter keinen Umständen beeinflussen mögen.

Wann sollte ich WAI-ARIA verwenden? 🔗

Wann immer ihr ein Widget baut, das nicht in der Gastgebersprache wie z. B. HTML beheimatet ist. Solche Widgets können z. B. Folgende sein:

tree mit treeitem Kindelementen. Dies sind Hierarchiebäume, wie man sie z. B. in der Ordnerliste des Windows-Explorer oder der Liste von Büchern und Hilfethemen in der Windows HTML-Hilfe findet.
menu mit Kindern menuitem, menuitemcheckbox oder menuitemradio: Dies ist ein echtes menüsystem, das man in vielen Windows- oder Mac-Desktop-Programmen findet.
grid oder treegrid mit Kindelementen gridrow, columnheader, rowheader und gridcell: Eine bearbeitbare Tabelle wie in einem Tabellenkalkulationsprogramm. Dies nicht verwechseln mit Datentabellen, für die native Elemente wie table, tr, th und td mit scope- und anderen Attributen verwendet werden müssen.
toolbar: Ein Container mit Kindelementen wie buttons oder anderen interaktiven Elementen.
dialog: Ein modaler Dialog, der auf die eine oder andere Weise geschlossen werden muss. Solange er geöffnet ist, ist keine Interaktion mit dem Rest der Seite möglich. Die Rolle alertdialog ist verwandt, ich empfehle ihre Benutzung jedoch nicht, da die Unterstützung hierfür sehr inkonsistent ist.
application: Eine Webapplikation, in der die Tastatur und sätmliche Elemente vollständig vom Webentwickler kontrolliert werden und keine Standard-Dokumentnavigation gewünscht ist. Wann und wie diese zu benutzen ist und wann nicht, habe ich in einem Blogbeitrag zur Rolle application ausführlich beschrieben.

In allen oben erwähnten Fällen liegt es in eurer Verantwortung:

euch mit den erwarteten Interaktionsmuster für Maus und Tastatur vertraut zu machen.
sicherzustellen, dass alle Elemente mit der Tabulator-Taste erreichbar sind und der Tastaturfokus immer sichtbar ist. Verwendet das Attribut tabindex mit dem Wert 0, um Elemente, die normalerweise mit der Tastatur nicht erreicht werden können, an ihrer natürlichen Position im Dokumentverlauf einzufügen.
Ausnahmen von dieser Regel zu implementieren, um die Tastaturnavigation effizienter zu gestalten. So empfiehlt es sich z. B., auf Symbolleisten zu landen, die einzelnen Elemente innerhalb einer solchen aber nicht unbedingt mit Tab anzuspringen, sondern hierfür Pfeil rechts und links zu verwenden. Tab sollte statt dessen zum nächsten Container, z. B. der nächsten Symbol- oder Menüleiste, springen. Escape sollte die Symbolleiste verlassen und in den Hauptbereich der Anwendung zurückkehren. Analog sollten einzelne Tabs mit Pfeil links und rechts ausgewählt werden und die Tab-Taste direkt ins Tabpanel selbst springen.
den Fokus immer unter Kontrolle zu haben. Wenn ihr z. B. ein Dialogfeld öffnet (Rolle „dialog“), ist es eure Aufgabe, den Fokus auf das Dialogelement selbst oder sein erstes fokussierbares Element zu stellen. Weiterhin müsst ihr dafür sorgen, dass man mit Tab nicht aus diesem Dialogfeld „entkommen“ kann, die Interaktion also definitiv modal ist. Escape sollte ein Dialogfeld in der Regel ohne Änderungen schließen, und es sollte ein OK/Speichern/Akzeptieren-Button vorhanden sein, der das Dialogfeld schließt und Änderungen übernimmt. Nachdem das Dialogfeld geschlossen wurde, müsst ihr den Fokus wieder auf ein definiertes Element außerhalb stellen, z. B. den Button, der das Dialogfeld ursprünglich öffnete, damit der Fokus nicht irgendwo im Nirvana landet.

Wenn ihr euch nicht an die Interaktionsmuster haltet, die die mit bestimmten Rollen assoziiert werden, kann euer WAI-ARIA-Zuckerguss sehr schnell zu saurer Milch werden, nämlich genau dann, wenn die vom Anwender erwarteten Interaktionen mit der Tastatur nicht funktionieren. Ich empfehle hierzu dringend das Studium der WAI-ARIA 1.0 Authoring Practices. Diese sollten auch als Referenz für später immer griffbereit liegen. Sie enthalten eine nützliche Zusammenstellung der Rollen und ihnen zugeordnete Attribute und wie die Interaktionsmuster für viele Widget-Typen aussehen. Ein weiteres Dokument, das ich auch immer für die Hinterhand empfehle, ist das schon einmal erwähnte Dokument „Using WAI-ARIA in HTML„. Dieses enthält ebenfalls eine ausführliche, aber gut verständliche Zusammenstellung von Regeln und Empfehlungen, wie WAI-ARIA am besten einzusetzen und wann von seinem Einsatz abzusehen ist.

Schlussbemerkungen 🔗

Mir ist sehr wohl bewusst, dass das Thema Barrierefreiheit im Web für jemanden, der damit gerade erst anfängt, sehr erschlagend wirken kann. Erinnert euch aber bitte daran, dass ihr auch mal mit HTML, CSS und JavaScript klein angefangen habt und euch das Thema zuerst überrumpelt hat. Die Routine kommt mit der Zeit. Genauso wie HTML, CSS und JavaScript zu einem Selbstläufer wurden, wird auch das inklusive Denken bald in Fleisch und Blut übergegangen sein und das Hinzufügen der entsprechenden Techniken wie von Selbst von der hand gehen. Und ganz wichtig: Keine falsche Scham beim Stellen von Fragen! Die Accessibility-Gemeinde ist in der Regel sehr hilfsbereit und freundlich.

Und noch ein Aspekt ist wichtig für die Motivation, der dankenswerterweise immer häufiger auch in Artikeln und Vorträgen genannt wird: Barrierefreiheit geht Hand in Hand mit Benutzbarkeit. Sobald die Benutzbarkeit für Maus, Tastatur und das Einhalten bestimmter visueller Regeln getan sind, sind schon mindestens 80% der Anforderungen für Barrierefreiheit erreicht. Ein großartiger Tipp für das Einhalten bestimmter Kontrasttiefen stammt von Eric Eggert: Stellt euch mit eurem schönen Tablet oder Handy mal in die Sonne und schaut, ob ihr eure eigene Webseite noch lesen könnt! 🙂

Und bei Benutzbarkeit und Barrierefreiheit geht es in allererster Linie um die Menschen, die eure Webseite oder Applikation benutzen können sollen. Erst dann kommt irgendwann eine WCAG-Checkliste oder eine gesetzliche Vorgabe, die es zu erfüllen gilt. Vergegenwärtigt euch immer, dass ihr dies für Menschen macht. Sobald die das benutzen können, was ihr da gebaut habt, kommt das Erfüllen von WCAG-Kriterien und gesetzlichen Vorgaben ganz automatisch.

Macht WAI-ARIA also zu einem Werkzeug in eurer Werkzeugkiste der Webentwicklung, das ihr benutzt, wenn ihr es müsst, und das ihr weg lasst, wenn andere Werkzeuge die Arbeit viel besser erledigen können. Sobald die Tastaturbedienbarkeit da ist, braucht es nur noch bestimmte semantische Erweiterungen bei bestimmten Szenarien, und der Job ist erfolgreich erledigt! Und immer daran denken: Der Mensch kommt zuerst!

Viel Spaß beim Coden!