Barrierefreie Web Applikationen

 

AJAX, Microformats und HTML5 - wie können die Anforderungen von Menschen mit Behinderung in diese Technologien eingebaut werden?
Shadi Abou-Zahra ist W3C Web Accessibility Spezialist für Europa (Wien/Österreich)

Ich bin, wie gesagt, vom W3C (World Wide Web Consortium). Ich habe gehofft, dass ich heute mit dem Thema Webapplikationen ein bisschen vom Thema WCAG 2.0 ablenken kann, aber es ist dann doch mehrmals hervorgekommen.

Wann kommen die Richtlinien endlich an?

Auch von zwei Sprechern wurde das angesprochen und ich verrate euch vielleicht ein Geheimnis, wenn ihr das für euch behalten könnt: es sind vom jetzigen Entwurf Nummer fünf Issues, Probleme offen, die bearbeitet werden müssen und wir sind wirklich ganz guter Hoffnung, dass wir Ende November, beziehungsweise Anfang Dezember einen nochmaligen Last Call Working Draft versuchen werden, mal schauen, ob es heuer klappt.

Letztes Jahr ist ein Last Call gekommen, zu dem es doch recht viele Kommentare gegeben hat und die Arbeit musste wieder in ein Arbeitsentwurfstadium zurückfallen. Wie gesagt, wir hoffen, dass wir wieder einen Aufstieg schaffen.

Heute aber ist das Thema, wie gesagt:

Barrierefreie Webapplikationen

Das lehnt sich sehr stark an die vorherige Diskussion an; allerdings liegt mein Thema viel mehr auf einer technischen Ebene: wie kann man diese Applikationen, die der vorherige Redner vorgestellt hat, barrierefrei gestalten, was gibt es da für Ansätze? Zuerst einmal: Was sind Web-Applikationen. Wir haben ja im letzten Vortrag viele Beispiele gesehen. Wir sehen eine Veränderung am Web heute, von Dokumenten in Anwendungen, in Applikationen.

Das ist eine langsame aber sichere Veränderung, die diese Dinge oder Widgets anpasst - ich werde ab jetzt das Wort Widgets verwenden, das ist mir ein bisschen lieber und hoffe ihr verzeiht mir, wenn ich da englische Wörter mit einbringe. Die Designer sind heute nicht mehr damit zufrieden, die eingebauten Elemente, die im Formular mitgegeben werden, die Checkboxen oder die Option Lists zu verwenden und wollen ihre eigenen Menüs kreieren. Oder es gibt es manche Elemente vielleicht noch gar nicht, wie diese Regler, diese Slider.

Da muss man sie kreieren, anpassen oder erstellen. Wir haben auch eine viel stärkere Laufzeit. Früher wurden Webseiten geladen, auch wenn sie auf der Serverseite aus Datenbanken und so weiter dynamisch generiert wurden, waren sie im Endeffekt doch eher statisch. Vielleicht wurde dann beim Absenden des Formulars ein kleines Skript gestartet, um zu checken, ob die verschiedenen Werte gestimmt haben oder nicht. Aber im Großen und Ganzen sind die Seiten eher statisch. Heute erleben wir aber eine viel stärkere Laufzeit, wo die Skripten teilweise das ganze Interface aufbauen und verschiedene Sachen kontrollieren, wie eben Vergrößern und Verschieben von Elementen, sogar Sachen wie Drag&Drop und andere.

Drag&Drop, also Austausch von Daten ist auch ein heißes Thema im sogenannten Web 2.0 Cloud (?), was immer Web 2.0 bedeutet. Aber der Austausch von Daten, das Einbinden von verschiedenen Modulen oder Applikationen miteinander, zum Beispiel, ich bette GoogleMaps oder Flickr in meine eigene Applikation ein und baue dazu ein eigenes Interface und so weiter.

Ein Beispiel zur Darstellung ist GoogleSpreadsheets, das ich hier zeige. GoogleSpreadsheets ist ein Teil eines Office-Paketes, das Google bereitstellt, eine Webapplikation, wo man online Tabellenkalkulationen machen kann. Die haben auch GoogleDocs, wo man Dokumente erstellen kann und so weiter. Das ist eine vollwertige Anwendung, eine vollwertige Tabellenkalkulation, wo man Sachen kopieren und pasten kann, wo man die verschiedenen Tabellenköpfe beschriften kann, speichern, abspeichern, nur alles online.

Das passiert alles in einem Webbrowser, das ist eigentlich der einzige Unterschied, aber sonst gibt es zur normalen Desktopanwendung eigentlich kaum einen Unterschied. Und das ist noch immer eine Webapplikation - wir reden hier noch immer von einem Web - hat aber mit einer statischen Seite, die wir jetzt lesen, die ja zum Lesen gedacht ist, nur mehr wenig zu tun. Das ist wirklich eine interaktive Applikation, wo man Aktionen und Sachen bewerkstelligen kann und diese Dinge vermehren sich, von dieser Art Anwendungen gibt es mehr.

Hier ein anderes Beispiel: Tupalo ist eine Webseite, die eine typische Community Network Applikation darstellt. Ich habe sie nur aus dem Grund gewählt, weil ich die Entwickler zufällig einmal bei einem Webmontag getroffen habe. Webmontag ist übrigens etwas, was ich sehr empfehle. Was hier passiert ist, das ist eigentlich eine eingebettete GoogleMap, wo man dann dazu anklicken kann, in GoogleMaps irgendeinen Ort anklicken kann, und einen Review schreiben; beispielsweise "ich war gestern in diesem Lokal und mir hat es geschmeckt oder es war schrecklich laut" oder was auch immer. Durch diese Reviews von den verschiedenen Personen steigen die guten Plätze, beziehungsweise gibt es hier eine Art Dynamik. Das wichtige daran, was ich hier damit illustrieren will ist eigentlich das Interface von diesem Objekt. Zuerst das Einbetten von anderen Daten, von GoogleMaps, hier einbetten und damit arbeiten. Das zweite ist auch, man sieht das hier nicht, weil das nur ein Screenshot ist, aber man kann zum Beispiel diesen Teiler in der Mitte verschieben und somit diesen Maps-Teil größer oder kleiner machen oder den Review-Teil, also diese Spalten und Kolumnen. Man kann das verschieben, man kann die einzelnen Reviews mit Drag&Drop herumbewegen durch den ganzen Schirm und man kann wirklich einen interaktiven Prozess an dieser Oberfläche machen.
Für Menschen mit Behinderung sind solche Applikationen eigentlich auch als eine Chance, eine Gelegenheit, anzusehen, weil das eigentlich intuitivere Oberflächen sind, die vielleicht irgendwie leichter zu verstehen und leichter zu verwenden sind. Die sind auch sehr oft benutzbarer oder haben die Möglichkeit benutzbarer zu sein. Aber es gibt natürlich auch viele andere Probleme beziehungsweise Herausforderungen, die sich dadurch ergeben, für manche Menschen mit Behinderung, wie eben angesprochen, Tastaturbedienung. Tastaturbedienung ist ein Riesenproblem, aber das eigentliche Problem der Tastaturbedienung und auch von Screen-Readern ist, dass die Semantik von diesen Widgets nicht aus dem Sourcecode erkennbar ist. Somit können diese assistierenden Technologien beziehungsweisen die Benutzeragenten diese Information nicht bearbeiten. Skripten werden auch von assistierenden Technologien sehr unterschiedlich bearbeitet, es hat bis jetzt immer den Gedanken gegeben, dass Screen-Reader zum Beispiel Java-Script nicht bearbeiten können. Das stimmt so gut wie gar nicht.

Die meisten Screen-Reader können Java-Script bearbeiten. Die Frage ist nur, wie bearbeiten sie es und zu welchem Teil und das ist sehr oft undokumentiert oder nicht ganz klar ersichtlich. Somit muss dann ein Entwickler eine Art Ratespiel machen und versuchen wo funktioniert es und dann etwas anderes probieren und so weiter. Das kostet Zeit und Mühe.

Zu guter Letzt hat auch mein Vorredner diese Benachrichtigung erwähnt: Was passiert, wenn sich etwas auf der Webseite verändert, wie benachrichtige ich das? Manchmal sehen wir die Veränderung auch visuell, manchmal sehen wir die Veränderung auch nicht. Manchmal entscheiden wir uns diese Veränderung zu ignorieren.

Wir nehmen zwar wahr, dass sich etwas auf der Website verändert hat, aber das interessiert uns nicht und wir schauen uns das nicht an. Zum Beispiel diese Stock-Ticker, die vorgestellt worden sind. Vielleicht interessiere ich mich gerade dafür, wie Compaq gerade steht, aber vielleicht auch nicht und ich kann mich entscheiden, das zu ignorieren oder auch nicht. Aber wie kann man das jetzt im übertragenen Sinne für einen blinden Menschen machen, diese Personen entscheiden lassen, ob sie diese Information zuerst wahrnehmen, dass sich etwas verändert hat und zweitens dass sie entscheiden können, ob sie diese Information auch anhören wollen oder nicht.

Hier ist ein Ratespiel, damit ihr nicht einschlaft: Hier ist ein Code eingebettet, vernetzte div-Elemente und in der Mitte lauter einzelne Wörter, veggies, greens und andere Sachen. Was stellt das dar? Irgendwelche Vorschläge?

Ein Tabelle haben wir, andere? Verschachtelte Liste. Ein drittes noch? Eine Tree-Navigation, hundert Punkte. Genau, das ist eine Tree-Navigation. Nur war das natürlich vom Code her nicht ersichtlich, was das war. Das hätte wirklich genauso eine Tabelle sein können, es hätte genauso was auch immer sein können. Es ist eine Tree-Navigation. Jetzt gäbe es wirklich hundert Punkte für jeden, der sagen kann, welches div wozu gehört hat. Das wäre jetzt wirklich schwierig zu erraten.

Manche dieser divs sind wirklich bedeutsam, weil sie bestimmte Artikel zusammen verschachteln. Andere divs sind wirklich nur da, um die Umrandung oder den Button oder was immer zu ermöglichen, also die haben wirklich nur einen dekorativen Charakter. Wie unterscheide ich jetzt zwischen einem dekorativen div und einem semantisch wertvollen div?

Die Idee, die WAI ARIA mit sich bringt, WAI ARIA steht für Web Accessibility Initiative Accessible Rich Internet Applications, dass man Attribute verwendet, in HTML eingebettet kann man die sogenannte Rolle eines Elementes beschreiben. WAI ARIA bietet eine Taxonomie um Rollen zu beschreiben und in dieser Rolle habe ich zum Beispiel auch für Tree-View, für eine Baumansicht, verschiedene Wörter.

Das ganz oberste div-Element ist ein Baum, die Rolle davon ist ein Baum und dann habe ich Gruppen, divs, die als Gruppen ausgezeichnet sind und andere divs, die als Items ausgezeichnet sind. Damit kann ich jetzt klarer unterscheiden, was ist eine Gruppe von Sachen, die zusammen gehören, was ist ein Item und wie hängen sie alle zusammen und welche Bedeutung haben sie semantisch.

Das kann jetzt von einem Screen-Reader beziehungsweise von einem Benutzeragenten ausgelesen und verwertet werden, also Semantik hinzufügen. Neben der Rolle gibt es auch den Zustand, ich habe es hier fälschlicherweise als Status, als Übersetzung von "state" bezeichnet; ich bitte um Verzeihung, deutsch ist nicht meine erste Sprache. Hier ist zum Beispiel eine Checkbox, die Checkbox hat auch eine Rolle und dann sieht man auch, dass es andere Attribute gibt, die Werte beschreiben. Zum Beispiel dass die Checkbox gecheckt ist und dass es required, dass es benötigt ist, um dieses Formular überhaupt abschicken zu können und ob der momentane Wert valid ist oder nicht. Ich kann einem Element verschiedene Werte oder Eigenschaften zuordnen.

Das nächste Beispiel ist der Slider, dieser Regler, den auch der vorherige Sprecher vorgestellt hat, dieser Regler, den ich verschieben kann links und rechts und so. Hier kann ich direkt im Code drinnen schon diese Werte abfragen.

Wie das jetzt visuell dargestellt wird, ist eigentlich zweitrangig, ob es jetzt blau ist oder silber, ob es jetzt horizontal oder vertikal geregelt wird oder was auch immer, das sind wirklich Sachen der visuellen Darstellung. Aber die semantische Bedeutung dieses Elements, dieser Komponente kann ich hier mit WAI ARIA sehr gut beschreiben.

Falls es irgendwelche Fragen gibt, bitte mich zu unterbrechen, weil ich weiß - mein Tempo ist momentan vielleicht ein bisschen schnell - möchte ich Ihnen auch das Chat-Beispiel vorstellen, das der Thomas bereits vorgestellt hat. Wer sich nicht daran erinnern kann:

Es gab verschiedene Bereiche - das besondere an dem Chat-Beispiel ist, dass es verschiedene Bereiche gibt - die verschiedene Bedeutung haben und es ist eigentlich sehr viel los. Es gibt den zentralen Bereich, wo eigentlich die Texte hineingeschrieben werden, wo die verschiedenen Chat-Meldungen drinnen stehen, dann gibt es einen anderen Bereich, wo die Benutzer, die sich gerade im Chatraum befinden, dargestellt werden.

Dann gibt es einen Control-Bereich, wo man den Text hineinschreiben und abschicken kann und dann gibt es ganz unten eine Statusleiste, Sie sind offline oder Sie sind unsichtbar oder was auch immer, die den momentanen Status anzeigt. Das stellt hier große Herausforderungen dar: Wenn ich jetzt chatte, beziehungsweise wenn ich das jetzt nebenbei laufen habe und etwas anderes mache, wann will ich benachrichtigt werden, dass sich etwas verändert hat und auf welche Art sollte das gemacht werden? Da gibt es zwei Seiten dazu.

Das eine ist, was der Autor sozusagen vorgibt, was passieren soll, was der Autor als wichtig empfindet. Man sieht hier im Source-Code drinnen, für alle, die diese spitzen Klammern gerne lesen, das sogenannte Attribut AAAlive. Das sind die sogenannten live regents(?), da gibt es verschiedene Werte, die hier man eingeben kann. Es gibt vier Werte: Das "polite" ist eine höfliche Form, das heißt, die Benachrichtigungen werden an den Screen-Reader-Benutzer weitergeleitet, werden aber in einen Puffer eingestellt. Also wenn ich mich jetzt woanders auf der Webseite befinde und gerade einen anderen Teil dieser Seite lese, werde ich nicht unterbrochen, weil sich woanders etwas geändert hat, sondern es wird in einem Puffer abgelegt. Ich kann dann abfragen, was sich geändert hat, seit ich das das letzte Mal angeschaut habe, was hat sich da alles geändert und der Puffer wird dann ausgelesen. Es gibt dann einen anderen Wert, da sehen wir in der Liste der Personen, die sich im Chatraum befinden den Wert "off".

So werde ich gar nicht benachrichtigt, ob sich etwas verändert hat oder nicht, es wird aber sehr wohl gespeichert oder mitregistriert. Der Screen-Reader weiß, dass das hier eine aktive Zone ist, die sich verändern kann. Ich kann somit explizit diese Zone abfragen, was der aktuelle Wert ist, aber es gibt keine Benachrichtigung. Es gibt insgesamt vier Werte, die ich jetzt nicht alle im Kopf habe.

Off, polite, assertive, das heißt, es ist eine wichtigere Meldung, das heißt, ich benachrichtige den User, dass sich etwas geändert hat, aber der User muss sich auf dieser Seite befinden. Dann gibt es noch ein sogenanntes "rude", ein unhöfliches, das heißt, es wird eine Alertbox oder irgendetwas hochgestartet, das ist wirklich für sehr wichtige Sachen zu verwenden und hoffentlich nicht durch Spammer. Das ist eines der Dinge, die noch ausgefeilt werden müssen.

Die andere Sache, der andere Teil dieser Gleichung sind die Einstellungen im Browser. Es ist nicht nur das wichtig, was der Autor vorgibt, sondern auch der Benutzer kann bestimmte live-regents anklicken oder selektieren und sagen, das ist jetzt etwas für mich sehr wichtiges. Dieses Feld "Compaq" ist für mich jetzt momentan wichtig. Ich will jetzt jedesmal, auch wenn der Autor denkt, das ist nicht wichtig, wenn sich das ändert, eine Benachrichtigung bekommen.

Die Frage, die ich an dieser Stelle immer gestellt bekomme ist: "Wer soll diese ganze extra Information, diese ganze Semantik hinzufügen, wer hat Zeit, diese ganzen Attribute hinzuzufügen und sich zu überlegen, was die richtigen Werte sind?" Es ist schon Aufgabe des Entwicklers, für den richtigen Source-Code zu sorgen, dass der Code stimmt, dass das auch semantischen Sinn hat.

Aber wir hoffen hier sehr stark auf Autorenwerkzeuge, dass die Autorenwerkzeuge hier helfen, eigentlich nicht nur mehr Autorenwerkzeuge, sondern sogar Entwicklungswerkzeuge. Web Applikationen, die jetzt mehr Code drinnen haben und mehr Laufzeit benötigen auch andere Werkzeuge zur Entwicklung, jetzt generell, abgesehen von Accessibility, es wird einfach immer komplizierter. Wir sehen auch mehr, dass zum Beispiel Tools wie Eclipse heutzutage für komplexere Webapplikationen eher verwendet werden, weil einfach die normalen HTML -Editoren nicht mehr ausreichen: um den Skript zu debuggen, für die Laufzeit, um zu sagen, wenn ich jetzt diesen Input eingebe, was passiert dann.

Wir hoffen auch auf fertige Komponenten und sogenannte Design-Patterns, wo ich mit Cut and Paste oder durch Hinzufügen von fertigen Modulen dann Sachen vorgearbeitet haben kann, zum Beispiel dieses Tri-View. Dass ich genauso wie in einer Entwicklungsumgebung für eine normale Programmiersprache einen Tri-View in mein Arbeitsfeld hineinziehe und dann die verschiedenen Werte eingebe, die ich dann haben will, aber die ganzen Accessibilitymerkmale, also die ganzen strukturellen Merkmale werden von der Programmiersprache oder von der Programmierumgebung, von der Entwicklungsumgebung übernommen.

Dann auch Bibliotheken und Entwicklertools, die dann auch zum Einsatz kommen. Das sind alles Werkzeuge, die nötig sind, egal ob für Accessibility oder nicht, aber wir hoffen, dass wir da Accessibility stark mit einbauen können. Es bleibt jetzt zu erwähnen, dass der Content nicht alleine ist, im gesamten Bild von Accessibility, sondern auch die Tools gehören zur Accessibility.

Im W3C sehen wir es als sehr zentral, wir haben ja eigentlich drei Richtlinien: die WAI-Richtlinien sind auch die Autorenwerkzeug-Richtlinien, das A-Tag, und die Benutzeragenten-Richtlinien weil auch die Benutzeragenten und Autorenwerkzeuge ihren Teil verrichten müssen, damit es wirklich einen allgemeinen Zugang gibt. Es hat keinen Sinn, dass man bestimmten Content erzeugt, der aber nicht von den Benutzeragenten unterstützt wird, siehe zum Beispiel das Longdesk-Attribut, das nicht unterstützt wird.

Es macht es auch sehr viel schwieriger, wenn die Autorenwerkzeuge Accessibility nicht unterstützen, das im Inhalt zu gewährleisten. Apropos Unterstützung, welche Unterstützung gibt es für WAI ARIA? Für WAI ARIA gibt es schon eine ziemlich breite Unterstützung, Benutzeragenten wie zum Beispiel Firefox, Internet Explorer ? da sind es noch anfängliche Tests und Proben und Opera bietet da auch ziemliche Unterstützung. Bei verschiedenen assistierenden Technologien gibt es auch schon Unterstützung, Jaws, Orca, Window Eyes und ZoomText, Bibliotheken, wie das Dojo Toolkit für AJAX und es gibt verschiedene Firmen, die da schon versuchen erste Demos zu haben, AOL, Google, IBM und Yahoo und so weiter.

Man sagt, das sind ja nur die Großen, die fangen halt damit an, weil sie sich das auch leisten können das zu probieren, aber wir sind ziemlich zuversichtlich.
Wie hängt das jetzt alles mit XHTML und HTML zusammen und so, warum ist das nicht direkt in HTML eingebettet und die Frage dazu ist: Ja, wir sind großer Hoffnung, dass HTML 5.0 vielleicht viele dieser Dinge abnehmen könnte, aber HTML 5.0 ist momentan in der Entwicklung. Wir erwarten nicht, dass HTML vor 2009 oder 2010 öffentlich verfügbar sein wird.

Aber Menschen mit Behinderung brauchen heute eine Lösung, eigentlich hätten sie es gestern schon gebraucht. Aber WAI ARIA ist wirklich eine schnelle Lösung, die es jetzt schon gibt. Ich verrate euch jetzt noch ein Geheimnis: Heute Abend, spätestens Montag sollte ein neues working draft von WAI ARIA herauskommen und die Geschwindigkeit von WAI ARIA ist wesentlich höher und es ist eine sofortige Lösung, eine umgehende Lösung, die jetzt schon eine breite Unterstützung hat.
Letztes Slide, Zusammenfassung, WAI ARIA ist eine Taxonomie, die die Rolle und Eigenschaften von Elementen oder von Widgets generell beschreibt und diese festlegt. Es ist sehr ähnlich vorzustellen, wie diese MSAA oder so ein Accessibility API, nur ist es ein Accessibility API für Browser, wo diese Veränderungen oder die Rollen und der Status an dieses API exportiert werden und die dann von assistierenden Technologien herausgelesen werden können. Natürlich können auch assistierende Technologien direkt an den DOM gehen und sich diese Informationen holen, aber es gibt somit eine einheitliche Möglichkeit und eine einheitliche Methode für assistierende Technologien um an die Accessibility-Informationen heranzugehen und diese herauszulesen und auch für Applikationen um Accessibility anzubieten.
Das war alles von mir, die Webseite von WAI ARIA, um mehr Informationen zu holen, ist auf den Slides online verfügbar.

Übersicht aller MP3s und Transkriptionen im Artikel von Freak-Radio aktuell: <A-Tag>07: Barrierefreie Medien

(Transkription: Christine Schubert und Julia Karrer, www.freak-online.at)

---