Internet-basierte Anwendungen haben in den letzten Jahren einen großen Boom erlebt (Stichwort Web 2.0). Während die Idee standard-konformer und barrierearmer Webentwicklung im Allgemeinen in den letzten Jahren immer stärker Fuß fassen konnte, wurde diese Entwicklung durch die Verbreitung von web-basierten Applikationen jedoch massiv konterkariert.
Viele Web-Applikationen auf Basis von Javascript, AJAX, Flash oder anderen Technologien sind aus Sicht der Accessibility praktisch unbenutzbar. Es ist kaum Literatur und Wissen darüber verfügbar, wie komplexere Web-Applikationen und hochdynamische Websites barrierefrei gestaltet werden können.
Der folgende Bericht wurde von einer offenen Diskussionsrunde „Get Rich, Remain Accessible“ bei der heurigen SXSW interactive in Austin, Texas inspiriert.
Martin Kliehm und Gez Lemon hatten dankenswerter Weise die Initiative für diese Diskussion gesetzt.
Barrierefreie Web-Applikationen – das Problem
Die Zugänglichkeit von modernen Web-Applikationen die in hohem Maß auf Basis von Javascript und AJAX funktionieren ist im Prinzip von drei wesentlichen Faktoren bestimmt.
1. Webstandards: Webentwicklung für Barrierefreiheit
Wesentlicher Faktor ist hier der richtige Einsatz von HTML, CSS und Javascript. Waren hier die Möglichkeiten der EntwicklerInnen bis vor kurzem sehr eingeschränkt, so hat sich die Situation mit modernen Scripting-Methoden und neuen Webtechniken (Stichwort WAI-ARIA) innerhalb kurzer Zeit dramatisch verändert.
Damit steht den WebentwicklerInnen nun einen wesentliches Werkzeug zur Verfügung. Sie müssen nur den Ball aufgreifen und Erfahrungen damit sammeln.
2. Benutzersoftware: Browser und assistierende Technologien
Hier geht es im Wesentlichen darum, ob die verwendeten „User Agents“, sprich Browser, Screenreader, PDA-Software die entsprechenden Webtechniken aus Sicht der Barrierefreiheit unterstützen. Das betrifft in hohem Ausmaß natürlich Javascript und für die Zukunft WAI-ARIA, HTML 5.0 und andere.
Auch aus Sicht der Browser hat sich hier viel getan: WAI-ARIA wird von Firefox bereits seit der Version 1.5 zumindest ansatzweise unterstützt, auch Opera ist bereits recht weit mit der Implementierung. Microsoft wird mit dem IE 8 nachziehen, was für eine rasche Verbreitung und Akzeptanz ein wesentlicher Faktor ist.
Natürlich bestehen gerade im Bereich DOM-Scripting noch wesentliche Unterschiede zwischen den einzelnen Browsern. Zum Glück springen hier die so verbreiteten Javascript-Libraries in die Presche, die den AnwenderInnen browser-unabhängige Programmiertechniken ermöglichen.
Während vor einigen Jahren Screenreader Javascript noch nicht oder in nur sehr beschränktem Ausmaß unterstützten hat sich auch hier die Situation deutlich verändert. Der Einsatz von Javascript ist aber weiterhin ein schwieriges Feld das sehr viel Erfahrung und Tests erfordert.
Während Browser kostenlos erhältlich sind und User jederzeit zu einer aktuelleren Version oder einem anderen Hersteller wechseln können, sieht die Sache bei assistierenden Technologien anders aus. Screenreader sind zum größten Teil kommerzielle Softwarepakte die zu beachtlichen Kosten gekauft oder aktualisiert werden müssen. Daher ist die Migrationsrate deutlich langsamer als bei Browsern. Genaue Nutzungszahlen sind leider nicht bekannt.
Derzeit unterstützen nur die beiden Marktführer Jaws und Window Eyes in mehr oder weniger lückenhaften Implementierungen die aktuellen Standards wie WAI-ARIA. Darüber hinaus gibt es Tools wie zB. die Firevox-Sprachausgabe für Firefox, die aber eher Entwicklertools sind, um Implementierungen zu verifizieren, als echte assistierende Technologien.
3. Usability: Benutzerinterfaces verständlich machen
Selbst für klassische Websites ist es häufig nicht einfach, die Zusammenhänge und den Aufbau eines Interfaces für blinde BenutzerInnen oder Menschen mit kognitiven Behinderungen nachvollziehbar zu gestalten. Bei komplexen Web-Applikationen kann diese Aufgabe zu einer beachtlichen Herausforderung werden: Interfaces folgen nicht den gewohnten Design-Mustern, neue Interaktions- und Kommunikationskonzepte entstehen, Elemente sind nicht notwendigerweise fix positioniert, Benutzeraktionen und Feedback stehen unter Umständen nicht in räumlichen Kontext zueinander.
WAI-ARIA – the missing Link
Mit großem Nachdruck wurde in den letzten Jahren ein Standard entwickelt, um die technischen Voraussetzungen für barrierefreie Web-Applikationen zu schaffen. So wie es aussieht, stehen wir hier kurz vor der Möglichkeit diese neuen Techniken auch in einer Produktionsumgebung einsetzen zu können.
WAI-ARIA bringt im Wesentlichen drei neue Konzepte mit sich:
Rolle, Zustand und Eigenschaften von HTML-Elementen
In HTML stehen uns derzeit 12 Steuerelemente zur Verfügung, die eine Interaktion durch die User ermöglichen. Das bedeutet im Vergleich zum Betriebssystem eine massive Einschränkung – Windows bietet zB. 76 Steuerelemente. Daher müssen fürs Web Schieberegler, Datumsauswahl oder Baumnavigationen über Umwege mit HTML, CSS und Javascript nachgebaut werden. Browser oder assistierende Technologien können die Bedeutung dieser nachgebauten Elemente natürlich nicht erkennen – die bleibt rein der optischen Wahrnehmung vorbehalten.
Über das Role-Attribute können nun solche nicht-nativen Elemente auch eine korrekte semantische Klassifizierung erhalten.
States and Properties geben darüber hinaus über gewisse Eigenschaften (zB. Pflichfeld, Auto-Vervollständigen) und Zustände (zB ausgewähltes Feld, ausgewählter Wert) Auskunft.
Live-Regionen
Live-Regionen unterstützen Browser und Hilfsmittel bei der Interaktion mit AJAX-Aktualisierungen. Über diese neuen Möglichkeiten erfahren Screenreader zB:
- welche Regionen aktualisiert werden können,
- ob der gesamte Inhalt oder nur aktualisierte Inhalte von Live-Regionen vorgelesen werden sollen,
- ermöglichen die Verknüpfungen zwischen Steuerelementen und Live-Regionen, und
- mit welcher Priorität Aktualisierungen behandelt werden sollen (gar nicht, zurückhaltend, unterbrechend etc.).
Jedes HTML-Element wird fokussierbar
Bisher war es Links und Formularelementen vorbehalten einen Tastaturfokus zu erhalten. Durch WAI-ARIA wird das Konzept von TABINDEX
auf alle Elemente erweitert. Geräte-unabhängige Eventhandler wie Focus und Blur werden damit bei jedem Element nutzbar.
Mit Hilfe dieser drei Konzepte bzw. mit WAI-ARIA sollte es daher in relativ naher Zukunft möglich sein durch sorgfältige Programmierung komplexe dynamische Web-Applikationen auch barrierearm zu gestalten. Dieser Entwicklung sehen wir schon seit längerer Zeit mit Spannung und großer Neugier entgegen und initiierten daher ein Forschungsvorhaben, dass sich mit dieser Thematik auseinander setzt.
Accessible Web 2.0 – eine Toolbox
WIENFLUSS und putzhuber.net werden sich in den nächsten Monate im Rahmen eines gemeinsamen Forschungsvorhabens mit Fragen der Zugänglichkeit von Web-Applikationen beschäftigen.
Einerseits sollen barrierefreie Techniken für typische Elemente einer modernen Web-Applikation entwickelt und andererseits aber auch wesentliche Aspekte für die Benutzerfreundlichkeit solcher internet-basierten Anwendungen untersucht und in einer Musteranwendung implementiert werden.
Es ist auch geplant die Rolle von Javascript-Libraries (prototype, script.aculo.us, jQuery, YUI, DoJo) in Bezug auf die Barrierefreiheit zu untersuchen und gegebenenfalls Verbesserungsvorschläge einzubringen.
Die Stadt Wien unterstützt dieses Projekt im Rahmen des Förderprogramms „Vienna Enabled“.
Hallo,
Arbeite zur Zeit an einem neuen cms Projekt wobei es darum geht im Backend barrierefrei zu sein und unterschiedliche Backendlayouts zu unterstützten. Es fehlen mir allerdings Informationen was die wai aria Richtlinien anbelangt. Also ganz praktische Beispiele woran es zur Zeit mangelt. Das was man bei der w3c Gruppe findet ist doch recht dürftig und schwierig zu durchblicken.
Tolles Projekt und ein Lob an die Stadt Wien für ihre Weitsichtigkeit! Dort wo ich herstamme interessiert das niemand.
JavaScript und Barrierefreiheit passen so schon schlecht zusammen.
@Webdesigner: Javascript und Barrierefreiheit haben nicht grundsätzlich ein Problem miteinander. Es kommt nur drauf an, wie mans nutzt (Stichwort „Progressive Enhancement“).
Was WCAG 1.0 sagt, ist heute – neun Jahre später – nicht mehr zu 100% gültig.
Hallo nochmal,
Die Praxis von Javascript ist doch sehr ernüchternd. Es funktioniert nicht immer so wie es eigentlich sollte. Habe einiges mit jQuery umgesetzt. Vor allem mit den unzähligen Extensionen hapert es doch zum Teil erheblich. Wer bei grösseren Projekten, wie etwa das Backend eines cms, auf Javasript setzt, steht vor der Aufgabe dieses über die Jahre funktionstüchtig zu halten. Also die Wartung ist sehr Zeitaufwändig. Es braucht nur eine neue Browsergeneration und plötzlich funktionieren einige Features nicht mehr. Mal ganz zu schweigen von der Frage ob einige Bibliotheken noch weiterentwickelt werden.
Deswegen sollte man sich überlegen, ob man diese Zeit für Wartung hat, und ob man nicht ganz darauf verzichten sollte und die zur Verfügung stehende Zeit anderwärtig in dem jeweiligen Projekt investieren sollte. Z.b. sauberes html, usability und accessibility. Vielleicht klingt das ein wenig konservativ: Aber mir ist immer noch ein stabiles System lieber als diese schöne heilsversprechende Javascriptwelt die einem das Leben zur Hölle machen kann.
Gruss,
Armand