30.11.2010
Seit einigen Jahren beschäftigen sich Web-Entwickler viel mit WAI-ARIA, ein in Entwicklung befindlicher Standard des W3C. ARIA steht für Accessible Rich Internet Applications. Das Hauptziel des Standards ist es, das dynamische Verhalten von Web-Anwendungen für blinde und sehbehinderte Nutzer wahrnehmbar zu machen.
Wenn etwa durch AJAX ohne Neu-Laden der Seite Änderungen des Seiteninhalts ausgelöst werden, sorgt WAI-ARIA dafür, dass Screenreader-Nutzer das mitbekommen. Auch komplexere Interface-Komponenten (Widgets) wie Ausklappmenüs, Reiter, Schieberegler oder Hierarchiebäume können durch WAI-ARIA brauchbar werden vorausgesetzt allerdings, Nutzer verfügen über aktuelle Browser und Screenreader.
Viele Nutzer haben jedoch keine aktuellen Software-Versionen, gerade am Arbeitsplatz.
Deshalb werden beim Testen der Zugänglichkeit bewusst nicht die neuesten Browser und Screenreader-Versionen eingesetzt. So gilt laut BITV-Test Werkzeugliste zur Zeit immer noch der Test mit Internet Explorer 7 als verbindlich. Die dazu passendende JAWS-Version ist JAWS 8, eine Version, die WAI ARIA noch nicht unterstützt und in neueren Browserversionen bereits nicht mehr funktioniert.
Obwohl der BITV-Test keinen Praxistests mit Screenreadern einschließt, wird die Hilfsmittelunterstützung von WAI-ARIA durchaus implizit mitgeprüft. Angebote, die sich etwa bei Custom Widgets auf WAI-ARIA verlassen, bekommen (zur Zeit) Punktabzüge, etwa in den Prüfschritten "Ohne CSS nutzbar", "ohne Scripte nutzbar", und "Grafiken vor wechselndem Hintergrund erkennbar".
Dies führt zu der grundlegenden Frage, ob es überhaupt sinnvoll ist, bei einer Prüfung auf Barierefreiheit eine inzwischen veraltete Browser-Hilfsmittel Kombination, die WAI-ARIA noch nicht unterstützt, zur Messlatte zu nehmen. Werden denn damit nicht jene Web-Entwickler bestraft, die sich bemühen, die vom Kunden verlangten dynamischen Web-Applikationen mittels JavaScript und WAI-ARIA auch für blinde Nutzer zugänglich zu machen?
Um diese Frage zu beantworten, muss man etwas weiter ausholen. Erstmal: Was verlangen die Web Content Accessibility Guidelines (WCAG) 2.0, an denen sich die zukünftige BITV 2.0 und damit auch der zukünftige BITV-Test orientieren? Dann, wie gut ist jetzt schon die Unterstützung von WAI-ARIA in Browsern und Hilfsmitteln? Und schließlich: was für praktische Hindernisse für den Einsatz von WAI-ARIA bestehen am Arbeitsplatz?
"Accessibility support" kann man sich als eine Brücke mit zwei Bögen vorstellen. Nur wenn beide Bögen da sind, können Hilfsmittel-Nutzer an alle Informationen gelangen, die auch den übrigen Nutzen zugänglich sind.
Der erste Bogen ist die eingesetzte Webtechnologie. Webentwickler, die sich an die WAI-ARIA-Spezifikation und die empfohlenen Authoring Practices halten, können sicherstellen, dass ihre Inhalte potenziell zugänglich sind.
Warum "potenziell?" Weil der zweite Bogen der Brücke noch fehlt: geeignete Nutzeragenten. Browser und Screenreader müssen angepasst beziehungsweise aktualisiert werden, damit sie die neuen Webtechnologien auch unterstützen. Bei älteren Versionen kommt häufig nichts an.
Um den "accessibility support" einer bestimmte Webtechnologie zu erklären, reicht es also nicht aus, den Standard zu verabschieden. Man muss auch prüfen, in welchem Maße aktuelle, Unterstützung bietende Browser und Hilfsmittel bereits weitreichende Verbreitung gefunden haben. Die Situation ist hier je nach Land, Sprache und Nutzungskontext recht unterschiedlich.
Im Abschnitt über Understanding Accessibility Support steht deshalb:
The WCAG Working group and the W3C do not specify which or how many assistive technologies must support a Web technology in order for it to be classified as accessibility supported
Und:
...defer[s] the judgment of how much, how many, or which AT [assistive technology] must support a technology to the community and to entities closer to each situation.
In einem Intranet mit einheitlich administrierten Arbeitsplätzen kann etwa eine Unterstützung gewährleistet werden bei öffentlichen Webangeboten mit einer Vielzahl unterschiedlicher Nutzer und technischen Ausstattungen sieht es anders aus.
Die WCAG 2.0 sagen deshalb ganz klar:
Creating content that can't be used by the general public with disabilities should be avoided.
Quelle: WCAG 2.0 Understanding Conformance: Understanding Accessibility Support
Der BITV-Test orientiert sich in der Wahl seiner Messlatte vorrangig an diesem general public, also der tatsächlichen Praxis behinderter Menschen am Arbeitsplatz. Und hier zeigt sich, dass dem verbreiteten praktischen Einsatz von WAI-ARIA immer noch vieles im Wege steht.
Die Unterstützung einiger Teile von WAI-ARIA ist in neueren Browsern und Screenreadern inzwischen recht gut, so etwa bei den document landmarks. Es gibt aber auch noch viele Probleme.
Ein Blick auf die (inzwischen etwas veralteten) WAI-ARIA Tests auf codetalks zeigt, dass in vielen Screenreader/Browser-Kombinationen die Umsetzung bei vielen Widgets lückenhaft oder fehlerhaft ist. Und Workarounds für bekannte Screenreader-Bugs können die Zugänglichkeit für Nutzer standardkonformer Browser und Screenreader sogar verschlechtern.
Blinde Nutzer ohne WAI-ARIA-Unterstützung können ein Web Widget nicht erkennen, weil dessen WAI-ARIA-Rolle nicht ausgegeben wird. So etwa bei einer Reiternavigation (tabpanel), die gemäß der WAI-ARIA best practices umgesetzt wurde. Der Screenreader teilt den Nutzern nicht mit, dass es sich um eine Reiternavigation handelt und die Pfeiltasten benutzt werden können, um zwischen den Reitern zu wechseln. Nutzer werden also wahrscheinlich weitertabben und damit unwissentlich den Inhalt unter den Reitern überspringen. Und geskriptete Fokusversetzungen für die Pfeiltastennavigation zwischen den Reitern funktionieren häufig gar nicht, was bedeuten kann, das der gesamte Bereich unter den Reitern unzugänglich ist.
Wir sollten auch Nutzer mit Sehbehinderungen nicht vergessen. Die aktuellen Versionen bekannter Vergrößerungssoftware bieten noch keine WAI-ARIA-Unterstützung. ZoomText weiß anscheinend nicht einmal, dass es WAI-ARIA überhaupt gibt. Freedom Scientific plant partiellen Support in MAGic in der nächsten Version (die aktuelle Version ist 11.0). Dolphin kündigt Unterstüzung in HAL und Supernova ab Version 12 an.
Ob etwas wie gewünscht funktioniert, hängt auch davon ab, ob WAI-ARIA gemäß der WAI ARIA best practices umgesetzt wurde. Coding-Fehler können die Zugänglichkeit von Widgets noch verschlechtern. Das Problem hat auch damit zu tun, dass die eingebaute Semantik von nativen HTML-Elementen mit der durch WAI-ARIA hinzugefügten Semantik in Konflikt kommen kann. Alexander Farkas zeigt das etwa am Beispiel von Ausklappmenüs in WAI-ARIA Epic Fail: Reste fressen.
Das Zusammenwirken dieser Probleme bedeutet, dass der korrekte Einsatz von WAI-ARIA ganz schön kompliziert werden kann. Webentwickler, denen an der Zugänglichkeit ihrer Seiten liegt, testen deshalb zunehmend mit Screenreadern, um zu überprüfen, ob ihre Designs in möglichst vielen Umgebungen auch wirklich funktionieren. (Ein guter Anfang ist dafür der NVDA Screenreader: er ist kostenlos und leicht zu installieren).
WAI-ARIA kommt besonders blinden Nutzern zugute. Für sie sind desktopartige Widgets auf Webseiten jetzt nicht mehr länger unzugänglich. Aber die sprungartige Vermehrung solcher Widgets im Web hat auch negative Auswirkungen für sehende Tastaturnutzer.
Im Gegensatz zu den Desktop-Widgets und deren Konventionen tauchen die selbstgebastelten Widgets im Web in tausenderlei Spielarten auf. Nur wenige halten sich an die WAI-ARIA best practices. Ob und wie ein Widget tastaturnutzbar ist, muss in jedem Fall ausprobiert werden.
Bei einer Reiternavigation etwa gibt es keine klaren Anhaltspunkte, um zwischen einer normalen Hauptnavigation mit Reitern und einem Widget mit Reitern irgendwo weiter unten auf der selben Seite zu unterscheiden. Und nur wenige Reiternavigationen implementieren schon die Pfeiltastennavigation. Sehende Tastaturnutzer müssen also rumprobieren, was funktioniert. (Für blinde Nutzer mit WAI-ARIA-fähigen Screenreadern ist das Problem hier geringer, falls die Rollen des Widgets ähnlich wie bei Desktop-Widgets vorgelesen werden.)
Auch die Abhängigkeit von Stylesheets ist für sehbehinderte Nutzer kritisch. CSS wird bei selbstgebastelten Widgets als "accessibility-supported technique" vorausgesetzt denn ohne CSS zerbröselt alles. Die räumliche Zuordnung (CSS-Positionierung) der div und Bilder stimmt nicht mehr, Elemente tauchen doppelt auf, oder Inhalte erscheinen weit entfernt von ihrem Kontext, z.B. am Seitenende. Über CSS eingebundene Hintergrundbilder verschwinden, ebenso auch bei Nutzung eigener Farben. Eine robuste darstellungsunabhängige Semantik ist so nicht gewährleistet.
Andere Probleme gibt es am Arbeitsplatz, und oft aus Gründen, auf die Nutzer keinen Einfluss haben.
Ergänzen lässt sich, dass viele der bisher benötigten Anpassungen von Web-Anwendungen an Hilfsmittel genau solche 'selbstgebastelten' Bedienelemente betreffen, die mit WAI-ARIA Screenreader-tauglich gemacht werden können. Hier könnte die Unterstützung von WAI-ARIA viele Mühen und Kosten sparen. Natürlich müssen die Entwickler dann auch WAI-ARIA durchgängig und standardgemäß einsetzen.
Wir haben bei der Recherche zu diesem Artikel eine Stichprobe bei einem großen öffentlichen Arbeitgeber gemacht. Von den 15 erfassten Arbeitsplätzen für blinde Nutzer unterstützt zur Zeit kein einziger Screenreader WAI-ARIA.
An anderen Arbeitsplätzen sieht es sicher besser aus, aber das Signal ist klar: ein großer, vielleicht sehr großer Anteil der blinden Nutzer am Arbeitsplatz hat bisher kein System, dass WAI-ARIA unterstützt.
Es gibt leider keine Statistiken, die es ermöglichen würden, den Anteil der Anwender, die nicht WAI-ARIA fähige Screenreader einsetzen, einigermaßen verlässlich zu quantifizieren. Einzig die vielbeachtete WebAim Screenreader-Nutzer Umfrage (Update vom Oktober 2009) zeigt an, dass 83,6% der Screenreader-Nutzer ein Update innerhalb eines Jahres nach Erscheinen einer neuen Version vornehmen. Wenn man einmal nur JAWS betrachtet, dann sollte, nach mehreren Releases seit dem Erscheinen des ersten WAI-ARIA fähigen Version 9 im November 2007, inzwischen der Anteil der Nutzer, die noch JAWS 8 nutzen, auf unter 5 Prozent gefallen sein. Die Umfrage reflektiert jedoch hauptsächlich den amerikanischen Markt; auch ist anzunehmen, dass ein großer Teil der zu Grunde liegenden Antworten aus der Gruppe der technisch affinen Screenreader-Nutzer stammen, dass also die durchschnittliche Upgrade-Rate aller Screenreader-Nutzer deutlich unter 83,6% liegt.
Viele sinnvolle Nutzungsweisen von WAI ARIA zielen darauf, HTML anzureichern, um bestimmte semantische Defizite zu beheben. Da es in HTML 4 keine expliziten Elemente für die Bereichsauszeichnung gibt, gibt es in der WAI ARIA Spezifikation die sogenannten document landmarks. Damit kann ein einfaches div mit dem Attribut role="navigation" ausgezeichnet werden, während etwa der Seiteninhalt das Attribut role="main" erhält. Dann können etwa Nutzer von Screenreadern, die WAI ARIA unterstützen, schneller zwischen Seitenbereichen hin- und herspringen.
Andere Attribute verbessern die Auszeichnung von Formularen: so kann etwa bei einem Texteingabefeld (input-Element) das Attribut aria-required="true" Screenreader-Nutzer darüber informieren, dass es sich um ein Pflichtfeld handelt.
Ein weiteres nützliches Konstrukt sind die ARIA live regions, mittels derer Screenreader-Nutzer über dynamische Zustandsänderungen auf Webseiten informiert werden können, ohne dass sie ihren augenblicklichen Tastatur- Fokus verlieren.
Den Nachteil, dass mit WAI-ARIA angereicherte Seiten nicht mehr valide sind, kann man in Kauf nehmen: die gängigen Browser stören sich nicht an den zusätzlichen Auszeichnungen. Über kurz oder lang wird das Problem verschwinden, wenn aus dem augenblicklichen WAI-ARIA working draft eine recommendation geworden wird ist und eine neue Generation des W3C Validators WAI ARIA Attribute akzeptiert. Viele Sites umgehen auch das Validierungsproblem, indem sie die WAI-ARIA Attribute erst beim Laden der Seite per DOM Scripting hinzufügen.
Die WAI-ARIA Spezifikation unterstützt aber auch eine ganze Reihe von interaktiven Elementen (sogenannten Widgets) mit dem Ziel, gängige Interaktionselemente primärer Applikationen auch in Web-Applikationen zu realisieren (einen Überblick bietet die WAI-ARIA Role, State, and Property Quick Reference).
Zum einen wird versucht, die Semantik bekannter Elemente zu erweitern, etwa drei Zustände bei Checkboxen zuzulassen oder Ausklapplisten zu schaffen, die gleichzeitig Autocomplete-Eingabefelder sind (die combobox). Dabei werden bekannte HTML Input-Elemente nachgebaut, wobei ein ziemlicher Aufwand getrieben werden muss, wenn diese neuen Elemente halbwegs zugänglich umgesetzt werden sollen.
Dann gibt es aber auch eine Reihe von Interface-Elementen, die Webdesigner schon länger mit einigem Aufwand nachgebaut haben und die nun mittels WAI-ARIA zugänglich gemacht werden sollen: die custom widgets. Dazu gehören etwa Ausklapp-Menüs, Reiter (Tabpanels), hierarchische Navigationsbäume, Slider, Spinner, und sogar Drag-and-Drop Interfaces. Das jeweilig gewünschte Tastaturverhalten dieser Widgets wird nicht wie bei normalen fokussierbaren HTML-Elementen von Browser geliefert, sondern muss mittels JavaScript definiert werden. Das ist schon das erste Problem. Hier gibt es kaum verlässliche Konventionen, das heißt, es ist viel schwieriger, diese Elemente erwartungskonform zu gestalten. Welche Tasten auf ein bestimmtes Widget anwendbar sind und was genau sie auslösen, muss im Zweifelsfall erst mal ausprobiert werden.
Auch ist die Fehleranfälligkeit solcher Widgets ist höher. JavaScript-Tricks wie die von Alexander Farkas beschriebene TimeOut-Funktion für Fokusverschiebungen auf dem Seitenbaum hinzugefügte Elemente müssen genutzt werden, damit das intendierte Verhalten auch erreicht wird.
Gibt es dann nicht die Möglichkeit, Widgets mit Fallback-Lösungen für nicht WAI-ARIA fähige Browser/Hilfsmittel Kombinationen zu versehen? Die WAI-ARIA Spezifikation erwähnt dies in der Beschreibung der Rolle presentation: "
may be used to provide for an accessible fallback in older browsers that do not support WAI-ARIA".
Tatsächlich finden sich hierfür bislang keine praktischen Umsetzungsbeispiele. Es fällt schwer, sich sinnvolle Anwendungen dieses Ansatzes überhaupt vorzustellen. Was würde passieren, wenn man etwa eine selbstgebastelte Checkbox mit einem Fallback ausstatten wollte, also mit einer echten Checkbox für blinde Nutzer ohne WAI-ARIA Support, die mittels CSS vor sehenden Nutzern und mittels role="presentation" vor WAI-ARIA-fähigen Screenreadern versteckt wäre?
Das funktioniert nicht. Die Rolle presentation unterdrückt zwar WAI-ARIA-Attribute (außer globalen), nicht aber die Exponierung fokussierbarer Elemente wie Checkboxen. Der WAI-ARIA 1.0 User Agent Implementation Guide stellt klar:
...the element must still be exposed if it (...) is focusable, so that focus events can be fired (focus must never be lost).
Für Screenreader-Nutzer ohne WAI-ARIA Support, aber mit "JavaScript an", würde nicht nur die Fallback-Checkbox, sondern auch die selbstgebastelte Checkbox den Tastaturfokus erhalten, ohne jedoch Rolle und Zustand mitzuteilen. Für Screenreader-Nutzer mit WAI-ARIA Support würde die überflüssige Fallback-Checkbox zwar (dank role="presentation") nicht mitgeteilt, wärte aber dennoch Teil der Tab-Reihenfolge und weiter auswählbar. Sehende Nutzer schließlich könnten die Fallback-Checkbox auch über die Tastatur erreichen und (ohne visuelles Feedback) auslösen. Das macht natürlich keinen Sinn.
Wenn es geeignete semantische Elemente in HTML gibt, sollten möglichst diese und nicht ein nicht-semantisches, über JavaScript und WAI-ARIA Tastatur- und Screenreader-nutzbar gemachtes Widget eingesetzt werden. Die Schwierigkeit, native Elemente mittels CSS abweichend zu gestalten, mag manchen Frontend-Designer ärgern: für den Nutzer bedeutet es häufig ein Gewinn an Erwartungskonformität, wenn etwa Radio Buttons einfach wie die systemüblichen Radiobuttons aussehen und sich auch so verhalten.
Designer sollten prüfen, ob sie Abläufe, die mit komplexen Widgets unterstützt werden, nicht vereinfachen können. Braucht man wirklich eine schwer zugänglich zu machende Combobox für Autocomplete-Funktionen? Gibt es wirklich einen Bedarf für Checkboxen mit drei Zuständen, oder lässt sich das auch anders, einfacher umsetzen? Ist ein Slider nicht durch eine Gruppe von Radiobuttons mit diskreten Werten ersetzbar?
Das soll aber nicht als Aufruf zu minimalistischem Design missverstanden werden. Hübsche Interface-Komponenten richten kaum Schaden an, wenn sie eine gleichwertige zugängliche Alternative haben.
Ein Beispiel dafür ist der Schieberegler im Spendenprozess der Site SOS-Kinderdorf, die kürzlich ein Relaunch hatte. Mausnutzer können den Schieberegler benutzen, um die Höhe ihrer Spende an SOS-Kinderdorf einzustellen (siehe Abbildung 1). Abhängig von der Höhe des eingestellten Betrags drückt ein kleines Mädchen mittels einer Sprechblase ihren Dank in verschiedenen Abstufungen der Begeisterung aus.
Der Agentur zufolge hat die Spendenbereitschaft nach Einführung des Schiebereglers sprunghaft zugenommen selbst für Puristen wohl eine hinlängliche Rechtfertigung dieser spielerischen Umsetzung.
Figure 1: Zweiter Schritt im SOS-Kinderdorf Spendenprozess (Design by Aperto AG)
Statt zu versuchen, den Schieberegler hier durch den Einsatz von WAI-ARIA Screenreader-tauglich zu machen (role="slider"), haben die Designer stattdessen als Alternative ein simples Textfeld für die numerische Eingabe der Spendensumme eingesetzt. Die Tab-Reihenfolge überspringt einfach den Slider. Was wichtig ist: die Reaktion des Kindes in der Sprechblase wird von beiden Arten der Eingabe ausgelöst.
Fassen wir zusammen. JavaScript ist inzwischen überall präsent; immer mehr Websites verlassen sich darauf. WAI-ARIA ist deshalb eine willkommene Lösung, um die Zugänglichkeitslücke zu schließen, die diese Entwicklung geschaffen hat. Entwickler, die heute bereits WAI-ARIA praktisch umsetzen und auch in Hilfsmitteln testen, was tatsächlich ankommt, helfen dabei, Implementationsfehler in Browsern wie Hilfsmitteln zu entdecken. Gleichzeitig schaffen sie gute Umsetzungsbeispiele, von denen andere Entwickler profitieren können.
Solange aber noch viele der praktisch eingesetzten Browser/Hilfsmittel-Kombinationen keine oder nur eine partielle Unterstützung von WAI-ARIA bieten, sollte man zur Sicherstellung guter Zugänglichkeit WAI ARIA nur unterstützend einsetzen und sich nicht darauf verlassen.
Aus den genannten Problemen ergibt sich für den BITV-Test die Konsequenz, vorerst weiterhin zu verlangen, dass sich Websites zur Sicherstellung der Barrierefreiheit nicht auf WAI-ARIA verlassen. Das kann sich dann ändern, wenn der Anteil der Nutzer, die ältere, nicht WAI-ARIA fähige Hilfsmittel benutzen, deutlich geringer geworden ist.
Für Kommentare und Hinweise vielen Dank an Carsten Albrecht, Alexander Farkas, Michael Große-Drenkpohl, Jan-Eric Hellbusch, Werner Hoog, Martin Kliehm, Werner Krauße, Oliver Nadig, Hans-Herbert Suhling, Timo Wirth, Tiffany Wyatt und Marco Zehe.
Zeitgleich wurde eine englische Version dieses Artikels auf "A list apart" veröffentlicht.