Das Web zum Mitmachen: Barrieren in der Praxis

 

Welche AJAX Anwendungen gibt es überhaupt in freier Wildbahn und wie können sie möglichst barrierefrei eingesetzt werden?
Tomas Caspers, freier Berater (Much/Deutschland)

Eva Papst: Wir gehen in die nächste Runde. Wir haben den nächsten spannenden Vortrag für Sie. Es ist kein ganz Unbekannter, der hier ist: Jeder, der sich irgendwann einmal ernsthaft mit Accessibility auseinander gesetzt hat, kennt ihn - zumindest dem Namen nach, es ist Tomas Caspers. Vermutlich kennen alle auch die Website, die er betreut, und die vermutlich auch auf ihn zurückgeht. - das weiß ich jetzt gar nicht so genau - nämlich »einfach für alle«. Es ist auf jeden Fall jemand, der in der ersten Stunde der Accessibility in unserem Sprachraum bereits dabei war. Daher ist es auch kein großes Wunder, dass er immer mit Riesenschritten vorauseilt - nämlich in Richtung Web 2.0.
Der nächste Vortrag hat das Thema:
»Das Web zum Mitmachen. Barrieren in der Praxis.«

Tomas Caspers: Danke für die nette Einleitung. Erst einmal einen schönen Tag von mir. Wir haben gerade die erste Sprachbarriere erfahren: Die Dolmetscherinnen haben mich davon überzeugen können, dass mein Untertitel in Österreich nicht funktionieren wird.
Sie kennen alle das Sprichwort, dass das, was uns am meisten trennt, die gemeinsame Sprache ist.
Der Titel sollte sein: »Das Web zum Mitmachen. Barrieren in der Praxis.«
Und der erste Teil sollte sich um das Thema »Flash, AJAX und Barrierefreiheit« drehen: Wer hat vor fünf Jahren daran gedacht, dass man solche Sachen zusammen in einem Satz erwähnen darf?
Und der Untertitel sollte lauten: »Zehn Jahre alte Zöpfe abschneiden«. Und dann habe ich gehört: Dieses Sprichwort gibt es in Österreich so nicht! Dann übersetze ich es einmal vom Schriftdeutschen ins Österreichische. Das soll bloß heißen: »Mit zehn Jahre alten Vorurteilen aufräumen.«

Naja! Im zweiten Teil geht es dann um praktische Beispiele: Was man machen sollte, was man nicht machen sollte. Im zweiten Teil geht es um praktische Beispiele - was man machen sollte und was man NICHT machen sollte, wenn man Flash oder AJAX einsetzt.
Eine Bitte vorneweg: da meine Präsentation sehr grafiklastig ist, werde ich versuchen, Alternativtexte für Grafiken und Fotos anzusagen. Falls ich den Alternativtext einmal vergessen sollte, bitte sofort melden.
Kurz etwas zu mir: mein Name ist Tomas Caspers, ich wohne und arbeite im schönen Bergischen Land in der Nähe von Köln, berate Industrie, NGOs, also Nicht-Regierungsorganisationen, Behörden, mittelständische und kleine Firmen; baue Websites, schreibe Bücher darüber (demnächst wieder einmal eines), blogge zum Thema Web-Standards im Allgemeinen und besonders zur Web-Accessibility.
Ich verspreche Ihnen, dass ich heute ganz bestimmt keine blöden Witze über den österreichischen Fußball machen werde. Ich komme aus Köln und weiß daher, was Schmerzen bedeuten. Das können Sie vielleicht dann auch nachvollziehen. Aber die österreichischen Fans, die müssen nächstes Jahr sehr, sehr tapfer sein, denke ich.
Falls jemand Karten für das Endspiel Deutschland gegen England am 29. Juni besorgen kann, bitte melden! - Naja.

Wie bin ich beim Thema Web-Standards und Accessibility gelandet?
Ich habe Mitte, Ende der 90er Jahre in einer Agentur in Köln gearbeitet, da haben wir nach Anwendungen für den Interessensverband sehbehinderter Computerbenutzer gebaut und haben das getestet. Da saßen wir bei ihm am Schreibtisch und er wollte uns etwas vorführen und sagte: Da ist es! Aber da war kein Monitor! Und gab es für mich eine Barriere. Denn der hatte sein ganz normales Setup und konnte damit im Netz »herumturnen« und konnte alle möglichen Sachen auf seinem Computer machen. Er hatte auch eine Braillezeile und eine Sprachausgabe - und ich saß da und konnte nichts damit anfangen!
Das war so mein Einstieg in das Thema! Und dann kam irgendwann die Aktion Mensch mit »Einfach für Alle«, die Biene und ein kleines grünes Buch (das ich Jan Hellbusch, glaube ich, 5x laut vorgelesen habe - ich habe also einige Erfahrung als menschlicher Screenreader).
In meiner Freizeit mache ich blöde Witze über das W3C.
So wie diesen hier: »Eilmeldung: WCAG 2.0 fertiggestellt - Web Content Accessibility Guidelines 2.0, W3C Final Recommendation vom 01. April 2007«

Ja, damit ist der Witz schon verraten: am 1. April.- April, April!
Das ganze funktionierte nach Art eines Kettenbriefs: eine Reihe von Accessibility-Weblogs aus Deutschland, Schweden, England, Kanada und USA verlinkten alle miteinander und verkündeten die Fertigstellung der WCAG 2.0; jeder verlinkte auf den nächsten, bis man wieder am Ausgangspunkt angekommen war. Spätestens da dürfte den Nutzer klar geworden sein, dass er veräppelt worden ist.
Die Aktion fand (natürlich) am 1. April statt; sie war ein durchaus ernstgemeinter Seitenhieb auf die Endlosdebatte um diese wichtige Richtlinie.
Eine Richtlinie, die seit dem Jahr 2000 ganz bestimmt nächstes Jahr fertig wird.
Es werden noch Wetten angenommen, ob wir diesen Aprilscherz im nächsten Jahr wiederholen müssen.

1999 - das Veröffentlichungsdatum der alten, aber nach wie vor gültigen Richtlinie - das muss so ungefähr die Zeit gewesen sein, als Austria Salzburg (die echten, d.h. die in violett) zum letzten einmal Meister war und Rapid nur Vize. So lange ist das her.
Die Zeit um 1997-2000 ist heute bekannt als der Browserkrieg. Da gab es also so ein neues Ding namens World Wide Web, in dem jeder tun und lassen konnte was er wollte.
Im Hintergrund werkelte damals schon das W3C und entwickelte Standards, bei dem sogar die tonangebenden Browser-Hersteller vertreten waren. Die saßen in den Arbeitsgruppen und entwickelten mit an den Standards, gingen nach Hause und machten: genau das Gegenteil.

JavaScript & Flash - Rückblick

In jeder neuen Browser-Version kamen irgendwelche Gimmicks dazu, mit denen man ganz wunderbar die Nutzer nerven konnte. Aber seien wir doch einmal ehrlich: Anfangs fanden wir das auch alle ganz cool.
Sachen wie: Aufklappmenüs! Die aktuelle Uhrzeit! Countdown bis Weihnachten! Frames! onMouseOver etwas in die Statuszeile schreiben! Pop-Ups! Browser-Chrome verstecken! Seitenübergänge! Hintergrundmusik! Ticker! Farbige Scrollbalken! Animierte Schneeflocken! Nachts andere Farben als tagsüber, das war auch supercool! Die IP-Adresse des Nutzers anzeigen! Ganz tolle Sache!

Nur: Was war, wenn der User Agent das alles nicht unterstüzte? Was war, wenn damit Nutzer ausgeschlossen wurden?
Mal abgesehen von den Kopfschmerzen, die Browser-Inkompatibilitäten uns Web-Entwicklern bescherten.
Macht nix, dafür gibt es ja Plug-Ins!
Mit Flash kann man ganz tolle Sachen machen und brauchte sich nicht mehr darum zu kümmern, ob der Browser das wirklich alles verstand:
Damit konnte man dann Aufklappmenüs machen! Die aktuelle Uhrzeit! Countdown bis Weihnachten! Frames! onMouseOver etwas in die Statuszeile schreiben! Pop-Ups! Browser-Chrome verstecken! Seitenübergänge! Hintergrundmusik! Ticker! Farbige Scrollbalken! Animierte Schneeflocken!

Das war aber noch immer »böse«, klar, keine Frage.
Einmal abgesehen von der generellen Plug-In-Problematik, aber die Probleme waren die gleichen:
Belanglose Inhalte und Funktionen, zu starker Fokus auf Gimmicks, kein standardisiertes Verhalten, ungewohnte Dynamik

Kurz: Die Seite übernahm das Kommando. Für Nutzer, die auf Hilfsmittel oder auf individuelle Einstellungen ihres Rechners angewiesen sind, war der »Skip Intro«-Link oftmals das einzige, was sie zu Gesicht bekamen.

Das mag der Grund dafür sein, dass beide Techniken - JavaScript und Flash - für lange Zeit in der Versenkung verschwunden sind bzw. ein tristes Nischendasein fristeten. Aus dieser Zeit stammen viele Vorurteile gegen diese Techniken - Vorurteile, die sich bis heute beharrlich halten.
Die aber gar nicht mehr sein müssen, wenn man diese Techniken sinnvoll einsetzt! Vorurteile, die sich - und das ist ein ganz wichtiger Unterschied - zwar gegen die Art der Umsetzung richteten, die aber bis heute dazu führten, dass die Techniken als solche in weiten Kreisen abgelehnt werden.
Unterstützt wird diese Haltung durch die nach wie vor gültige Version 1 der Richtlinien. Die Richtlinien kümmern sich bekanntlich in der Hauptsache um statische Dokumente - und für diese ist sie auch in weiten Teilen immer noch gut anwendbar.

Problematisch wird es mit der Richtlinie nur, wenn man dynamische Inhalte bewerten will, die eher Züge echter Anwendungen tragen.
Die weit verbreitete Checklisten-Mentalität hilft da nicht unbedingt weiter. Web-basierte Applikationen sind in ihren Funktionen so einmalig, dass sie sich nicht mehr in das starre Raster einer Checkliste a la WCAG 1 mit 66 Punkten pressen lassen.

Abhilfe soll nun die neue Version der WCAG 2.0 schaffen, die ja bekanntlich auf eine breitere Anzahl von Web-Techniken anwendbar sein soll als nur auf HTML und ein bisschen CSS.
Allerdings - ob diese Richtlinie jemals fertig wird? Zwischenzeitlich war sie sogar schon einmal im Status eines »Last Call Working Draft«, mittlerweile ist sie wieder bei »Working Draft« zurückgestuft worden, der ersten von insgesamt 5 Stufen bis zu einer fertigen Empfehlung. Was gerade aus Sicht meines heutigen Themas problematisch ist, denn wir brauchen dringend eine runderneuerte Richtlinie.

JavaScript & Flash - Mythen und Vorurteile

Mittlerweile ist es leider so, dass die größte Hürde auf dem Weg zu einem zugänglicheren Web diese Mythen sind, die auf veralteten Annahmen oder, schlimmer noch, auf Hörensagen beruhen (»Alle Screenreader-Nutzer machen das so und so...«)

Das liegt unter anderem daran, dass es bisher keine großen Untersuchungen zu dem Thema gibt - die Beobachtug von 2-3 Nutzern gibt bestenfalls zufällige Ergebnisse.

Wenn Sie ein Versuchskaninchen vor einen roten und einen grünen Knopf setzen, dann drückt es mit 50%iger Wahrscheinlichkeit den grünen Knopf - daraus könnte man ableiten, dass Versuchskaninchen keine roten Knöpfe drücken - das entspricht in etwa dem aktuellen Stand der Accessibility-Forschung. Es fehlen uns wirklich Zahlen, die einem ein Statistiker nicht sofort um die Ohren haut.

Ich möchte im Folgenden einmal mit ein paar Mythen aufräumen, die sich beharrlich um die Themen AJAX und Flash und insbesondere um die Kombination von AJAX, Flash und Barrierefreiheit ranken.

Besonders verbreitet sind solche Mythen unter Vertretern der Standardistas, insbesondere der Subspezies Standardistus Maximus. Diesen erkennt man unter anderem daran, dass er immer bereit ist, seine Position zu verteidigen - selbst dann wenn auf der gegenüberliegenden Position schon längst keiner mehr steht, der zuhört.
Falls Sie den Film »Das Leben des Brian« kennen: das sind die, die auf dem Sockel vor der Tempelmauer stehen und predigen, egal ob ihnen jemand zuhört oder nicht.
Was Sie letztendlich von diesen Leuten immer wieder hören werden, ist, dass Java-Skript von Natur aus böse ist. Aber ich denke, das Argument zählt nicht. Damit können sie nicht richtig punkten, ganz einfach schon deshalb, weil Java-Skript ganz einfach da ist. Dass lässt sich auch nicht mehr per Verordnung hinausdefinieren.

Ich erinnere mich da an Zahlen: Man hat das bei Google einmal untersucht und hat den gesamten Google-Index von 2005 und nochmals von September 2006 untersucht: Basis waren mehrere Milliarden Seiten aus dem Google-Index.

Ungefähr 75 Prozent davon enthielten Skript-Tags. Es gab also eine Abstimmung mit den Füßen. Java Skript ist ganz einfach da. Wir können es nicht hinausdefinieren, sondern wir müssen dafür sorgen, dass es zugänglich eingesetzt wird.

Ja, kommen wir zu den eigentlichen Mythen:

Mythos Nr. 1: Flash & AJAX sind nix für Suchmaschinen

Ich denke einmal, 850.000 Treffer alleine für den Suchbegriff »Skip Intro«, eingeschränkt auf den Dateityp Swiff spricht für sich: Google indiziert sehr wohl Flash!
Leider hat sich das noch nicht bis zu vielen Flash-Entwicklern herumgesprochen, sonst gäbe es diese unbrauchbaren Suchergebnisse nicht.

Das gleiche gilt für JavaScript. Sie hören immer wieder diesen Mythos: Der größte blinde Nutzer ist Google, der kann kein Java-Skript... Wenn Sie eine der gängigen Bibliotheken wie Prototype oder script.aculo.us einsetzen, dann werden Sie bei der Analyse Ihrer Logfiles unter Umständen feststellen, dass der Googlebot auf Seiten rumturnt, die etwa nur über bestimmte Methoden von script.aculo.us erreichbar sind. Also irgendwie muss der Googlebot Java-Skript ausgeführt haben. (Frage: der Thomas Fuchs sitzt nicht zufällig im Publikum? Das ist nicht der Fall? Sonst hätte ich einige Fragen an ihn gehabt.)

Wobei natürlich die Frage gestellt werden darf, ob Sie Ihre Web-basierte Applikation wirklich von Suchmaschinen indexiert haben wollen. Welchen Sinn soll es machen, wenn ein Besucher per Google auf den dritten Schritt eines komplexen Formularablaufs kommt, und die ersten beiden Schritte auslässt? Gerade in komplexen Formularabläufen ist es unter Umständen sinnvoll, die Maschinen herauszuhalten, zumal deren Fähigkeiten immer besser werden

Mythos Nr. 2: Flash ist nicht barrierefrei

Wird auch immer wieder gerne gehört. Gegenargument: Der Pharmakonzern Pfizer hat im vergangenen Jahr eine BIENE mit einer ausschließlich Flash-basierten Site gewonnen. Ok, die Seite hatte gestalterisch noch etwas Luft nach oben (deswegen zeige ich die jetzt hier nicht, sonst heisst es gleich wieder, dass barrierefrei gleich hässlich ist), aber technisch war sie hervorragend umgesetzt und vor allem: Sie war hervorragend mit modernen Screenreadern zu benutzen.

Ein anderes Beispiel ist dieser Flash-basierte Feedreader (wobei mich da Jan Hellbusch vor zwei Tagen noch zurückgepfiffen hat, weil es in seinem Jaws 7.1 doch nicht so ganz funktioniert, ich war davon ausgegangen) - dem Vernehmen nach ist es mit halbwegs aktuellen Screenreadern gut nutzbar, da zum Beispiel die Ordner-Struktur, die sie hier sehen in HTML einfach nicht nachbilden lässt, weil es keine entsprechenden Elemente dafür gibt! Es ist mittlerweile in Flash [möglich], weil es die MSAA-Schnittstelle bei Windows vollständig unterstützt.

Frage ans Publikum: Vielleicht wissen nicht alle, was die MSAA bzw. eine Accessibility-API ist, soll ich das kurz erklären?
Das ist im Prinzip eine Schnittstelle, die das Windows-Betriebssystem bereitstellt - die alle Betriebssysteme bereitstellen, sie heißen nur anders unter Linux ist es ATK bei MacOS gibt es eine ähnliche Schnittstelle - worüber sich Hilfsmittel, die am Computer hängen oder darauf laufen, mit Informationen versorgt werden.
Das ist die Schnittstelle, über die der Screenreader gesagt bekommt, was er jetzt vorlesen soll, grob vereinfacht gesagt.
Das sind Standardfunktionalitäten des Betriebssystems, und findet sich zum Beispiel eine Ordner-Struktur.

Die kann ich mit bestimmten Tastatur-Befehlen handhaben. Ich kann Ordner auf- und zuklappen, kann mich innerhalb der Ordner bewegen, so wie das auch im Windows-Explorer gängig ist. Das wird über die Schnittstelle auch als Ordner-Struktur ausgegeben, damit ein Screenreader das entsprechend aufbereiten kann und erkennt: Das ist eine Ordnerstruktur, und da ist ein Ordner, der ist zugeklappt und einer, der ist aufgeklappt, da sind fünf Objekte drin - und ähnliches.
Das ist eine ganz normale Standard-Funktionalität des Betriebssystems!
In diesem Fall können Sie das in Flash anzapfen und dann wirklich echte Ordnerstrukturen machen und nicht nur irgendwelche GIFs.
Bisher funktionierte sowas nur im IE, ab Flash Player 9 geht das auch in Plug-In-basierten Browsern wie Firefox.

Eines der wenigen Probleme, die tatsächlich noch bestehen, ist die Zusammenarbeit von Flash und Screenreadern, wenn Firefox als Browser verwendet wird (z.B. Tabben zwischen HTML und Flash), aber auch das wird - aller Voraussicht nach - in der Version 3 behoben sein.
Behaupten kann man viel, aber wie testet man denn nun, ob ein Flash-basiertes Angebot wirklich barrierefrei zu nutzen ist?
Ein einfacher Test ohne große technische Voraussetzungen ist einer, mit dem man generell Webangebote schnell kann: Mausstecker ziehen. Das ist wirklich der einfachste Test, um herauszufinden, ob der Webentwickler vom Thema Web-Accessibility überhaupt schon einmal gehört hat! Achten Sie dann darauf, ob sich per Tastatur sinnvoll durch die Anwendung navigieren lässt.

Wenn Sie es genauer wissen wollen: Tools wie inspect32 von Microsoft oder ähnliche Tools z.B. für GNOME (dort heisst das »Accerciser Accessibility Explorer«) messen, was an der Schnittstelle (MSAA oder ATK im Falle von Linux) übergeben wird und geben das aus. Im Screenshot zu sehen sind Dinge, von denen heute noch öfters die Rede sein wird, wie Roles, States, und Properties, also die Frage nach »Was ist dieses Ding?«, »In welchem Zustand ist es?« oder »Welche Eigenschaften hat es?«

Hier sehen Sie das genannte Prüftool unter Linux.
Diese Tests betreffen nicht nur Bedien-Elemente, sondern auch Accessibility-Klassiker wie Alternativtexte für Grafiken etc.
Die Tools sind auch nicht auf das Testen von Flash beschränkt, ebensogut können Sie damit auch die Barrierefreiheit von AJAX-Anwendungen testen, denn auch da bekommen Sie eine ziemlich gute Vorstellung davon, was bei einem blinden Nutzer aus dem Lautsprecher kommen müsste.

Müsste deshalb, das noch einmal als Warnhinweis: Solche Tools ersetzen natürlich keinen echten Test mit tatsächlichen Nutzern, es kann aber schon während der Entwicklung helfen, spätere Probleme zu verhindern. Und wenn etwas in Orca unter Linux funktioniert, heißt das noch lange nicht, dass es das auch in JAWS oder Window Eyes unter Windows tut. Aber wenn es schon da nicht funktioniert, dann liegt es nicht am Format, sondern tatsächlich am Entwickler. Wenn der Entwickler das nicht gemacht hat, muss er noch einmal zurück und von vorne anfangen.

Mythos Nr. 3 Die Steigerung von »Flash ist nicht Barrierefrei« ist »Flash und AJAX sind nix für Screenreader«.

Frage an das Publikum: Was wären die passenden HTML-Elemente, um diese Dinge zu beschreiben? Insbesondere solche Dinge wie den Ordner-Baum oder den Schieberegler, um einen Wert von 0 bis 100 einzustellen. Das gibt's in HTML nicht!

Der Trick daran: diese ganzen Widgets werden vom Accessibility-Schnittstelle des jeweiligen Betriebssystems als das erkannt, was sie sind - denn sie sind echte Schieberegler HTML-Formulare stellen das nicht zur Verfügung. Betriebssysteme stellen das zur Verfügung, da gibt es das an allen Ecken und Enden! In HTML muss man dafür Tags benutzen und muss dafür Hilfsmittel benutzen, HTML-Hacks mit irgendwelchen DIVs, die man per JavaScript rumschiebt - und es ist trotzdem kein richtiger Schieberegler!

Lösungsansätze: Wir müssen entweder warten, bis HTML5 fertig ist (ersatzweise geht auch XHTML2 - aber da haben schon sämtliche relevanten Browser-Hersteller signalisiert, dass sie dies nie und nimmer umsetzen werden)
Oder eben WAI Aria benutzen, das gleich vorgestellt wird oder in diesem Fall gleich einmal Flash benutzen! Was Sie hier sehen, sind Fenster, Slider, Menu Trees, Tabs und eine ganze Reihe weiterer vorgefertigter Components aus OpenLaszlo - einer OpenSource-Plattform, mit der sich sowohl Flash- als auch DHTML-basierte Rich Internet Applications bauen lassen, die auch relativ gut zugänglich sind.

Mythos Nr. 4: Flash ist nix für Sehbehinderte

Das ist in weiten Teilen richtig, liegt aber auch wieder nur daran, dass die Entwickler da wieder alles falsch gemacht haben und daran, wie Flash eingesetzt wird. Das liegt nicht am Format selbst. Zwei wichtige Dinge für stark sehbehinderte Nutzer sind die Skalierbarkeit und benutzerdefinierte Farben, bei allem, was nicht HTML- Text ist. Möglicherweise werden von den Nutzern Kontrastschemata benutzt, die dann gelben Text auf schwarzem Hintergrund anzeigen und sich dann alles außer Grafik und Flash.

Hier können sie mit Flash umschalten und es ist dann so gemacht, dass es gleich auch noch vergrößert wird, invertiert wird und die ganzen Bedien-Elemente auch in so einem quasi Hochkontrast-Schema dargestellt werden. Also, das wäre eine ganz einfache Sache, wie Sie in Ihrer Flash-basierten Applikation auch sehbehinderten Nutzern entgegenkommen können. Das ist das Spaßige daran: das sind im Actionscript fünf oder sechs Zeilen Code: mit einem Farbfilter.

Das ist also wirklich von einem guten Actionscripter in fünf Minuten geschrieben, feine Sache!

Anderes Problem: Flash skaliert nicht mit: Sie kennen sicher zwanghaft eingeklemmte Flash-Filme, und sobald sie dort die Schrift vergrößern, verrutscht es höchstens, es passiert aber sonst nichts.
Kurze Demo: ich zeige Ihnen jetzt ein Beispiel. Ich drücke nichts anderes als Apfel+ oder für die Windowsbenutzer Strg+. Und das ist tatsächlich ein Flash-Player, den man sauber programmiert hat. Das ist kein HTML und skaliert im Prinzip mit.

Übrigens, mit Flash lässt sich auch abfragen, ob der Screenreader läuft. Mit Flash können Sie richtig abhören, am anderen Ende der MSAA-Schnittstelle ein assistives Programm wie z.B. ein Screenreader hängt, der die jeweilige Accessbility-API unterstützt. Versuchen Sie das einmal mit HTML!

Mythos Nr. 5: Flash & AJAX sind Schuld an ...

...eigentlich allem: Seiten mit automatischer Hintergrundmusik, Werbebannern, albernen Videos, Popups und anderem Klickibunti ...

Einmal abgesehen davon, dass es auch schon in den Zeiten vor Flash Seiten gab, die automatisch irgendwelche MIDI-Sounds durchs Modem drückten - Flash ist nur ein Format, das in Webseiten eingebettet wird - was man damit macht, liegt einzig und allein in der Verantwortung des Anbieters. Mit HTML kann man genau den selben Murks veranstalten wie mit Flash, nur ist es da ungleich aufwändiger.
Allerdings sind gute Web-basierte Applikationen, das ist mir ganz wichtig, dass sie den Unterschied verstehen: ich rede jetzt nicht über Werbebanner oder ähnlichem! Und gerade diese web-basierten Applikationen sind alles andere als dieser Murks. Sie sind echte Innovationen, bei denen es doch eigentlich im ureigensten Interesse der Menschen mit Behinderungen liegen müsste, dass sie das auch barrierefrei nutzen können.
Dass es bei Innovationen immer ein Bruch mit bestehenden Techniken und Werkzeugen kommt, zwangsläufig kommen muss, liegt in der Natur der Dinge und da machen Screenreader keine Ausnahme - das Modell nach dem diese gestrickt sind lässt gar nichts anderes zu. Hilfsmittel werden in Zukunft nachziehen, da bin ich mit ganz sicher. Zum Teil sind sie ja schon soweit - erste Implementierungen von WAI-ARIA in aktuellen Versionen von JAWS und Window Eyes zeigen ja, dass es geht.

Mythos Nr. 6: Flash & AJAX sind abgeschaltet

Im Netz sind viele Statistiken unterwegs, wer etwas hat oder kann und wer etwas nicht hat oder nicht kann. Alle diese Statistiken haben einen gemeinsamen Nenner: Sie sind bestenfalls geraten. Was Ihr Zielpublikum an technischer Ausrüstung hat oder nicht hat können Sie immer nur für den eigenen Server herausfinden, indem sie dort in die Logfiles sehen. Deswegen möchte ich mich hier auch erst gar nicht auf irgendeine Diskussion über Marktanteile oder etwas auch immer einlassen. Was zählt, sind Ihre ganz speziellen Nutzer: Wenn Sie herausfinden, sie können diese Techniken ihren Usern nicht zumuten, dann können Sie sie auch nicht einsetzen!

Mythos Nr. 7: Flash & AJAX sind viel Arbeit, wenn man es zugänglich machen will

Stimmt. Aber hat hier irgendwer behauptet, dass Webdesign einfach ist?

Der Praxisteil

Womit wir endlich beim eigentlichen Praxisteil angelangt wären - vielen Dank an alle die bis hierhin ausgehalten haben.

Wie vielleicht einige hier wissen, mache ich ein paar Sachen für die Aktion Mensch. Die Aktion Mensch veranstaltet seit dem Jahr 2003 den Biene-Award (bzw. seit letztem Jahr nur noch Biene, nachdem sich viele Menschen mit Lernbehinderung über das neudeutsche »Award« beschwert hatten).

Das Testverfahren der BIENE basierte seit 2003 in weiten Teilen auf den WCAG 1.0 bzw. deren deutschen Ableger BITV. Das Verfahren hatte einen starken Fokus auf den klassischen Accessibility-Fallen: Semantik, abwesende oder unbrauchbare Textalternativen, Kriterien der Wahrnehmung, Bedienbarkeit, Verständlichkeit, halt das übliche Accessibility-Programm.

Bei dynamischen Inhalten wurde das Testen schon schwieriger, weil es eine ganze Reihe von Einreichungen gab, die schon in Richtung web-basierter Applikationen gingen und damit nicht mehr von den Richtlinien abgedeckt waren.
So grundlegende Fragen der Nutzung von echten interaktiven Inhalten wie: »Wo bin ich eigentlich?«, »Was ist das für ein Ding?«, »Was macht das Ding, bzw. was kann ich damit machen?« Das sind Grenzbereiche, die mit dem WCAG1-basierten Test-Verfahren nicht zuverlässig getestet werden können.
Genau diese bisherigen Grenzbereiche rücken aber immer mehr in den Mittelpunkt - Stichwort Web 2.0.
Daher nimmt sich die BIENE bekanntlich eine Auszeit. Zur Zeit läuft eine Studie, die das Verhalten echter Nutzer untersucht. Das Ergebnis wird eine Neufassung BIENE-Kriterien 2008 sein.

Bei der Beobachtung echter Nutzer zeigt sich immer wieder: Ein riesiges Problem ist, dass die Modelle, nach denen Hilfsmittel wie Screenreader gestrickt sind, für moderne Webanwendungen einfach nicht geeignet sind.

Auch bei den Grundlagen für das klassische Prüfverfahren für größtenteils statische, auf der Dokumenten-Metapher basierende Websites mussten bei der BIENE Abstriche gemacht werden - so wurden im letzten Jahr eine ganze Reihe Kriterien gestrichen, die auf den berüchtigten »until user Agents«-Checkpunkten beruhten oder Prüfschritte, bei deren Nicht-Erfüllung keine nachweisliche Barriere entstand.
Viele Richtlinien sind darüber hinaus nicht verifizierbar, ohne dass man den Kontext kennt. Zum Beispiel Inline-Scripts und Inline-CSS - wenn Sie einen Standardista fragen wird der Ihnen antworten, dass man Skripte und Styles brav auslagern sollte.

Yahoo hat das einmal untersucht: Ungefähr sechzig Prozent der Nutzer bei Yahoo kommen mit leeren Cache: Da werden alle vermeintlich ausgelagerten und deswegen im Cache des Benutzers bereits vorhandenen CSS und Java-Skript-Dateien immer noch einmal gesucht - und noch einmal... Auslagern ist hier also eher kontraproduktiv - ein entsprechender BIENE-Prüfschritt hat also bei der anstehenden Überarbeitung nur eine sehr geringe Überlebenschance.

Dazu kommt das Problem der Bewertung bei der Beobachtung: Lag das jetzt wirklich an der eingesetzten Technik oder hat der Nutzer das wirklich nicht verstanden? Dazu muss man wissen, dass bei vielen blinden Nutzern auch die eine oder andere Form der Lernbehinderung zu diagnostizieren ist.
Dr. Arne Harder, selbst ein Blinder und promovierter Psychologe in Köln, hat auf diesen Umstand neulich noch einmal in einer Veröffentlichung hingewiesen, dass bis zu sechzig Prozent der Geburtsblinden auch die eine oder andere Form einer Lernbehinderung haben - ein Umstand, der in der Diskussion viel zu wenig Beachtung findet - wie übrigens der gesamte Themenbereich Lernbehinderung und kognitive Behinderung.
Das ist ein Umstand, der in der Diskussion zu wenig Beachtung findet, der aber auch Auswirkungen auf Prüfverfahren, Bewertungen und der Testergebnisse hat - so, wie der gesamte Bereich der Lernbehinderungen immer wieder zu kurz kommt.

Das Problem ist oftmals auch, so blöd das jetzt klingt, und so scheinbar das den Ideen der Barrierefreiheit zu widersprechen scheint, ein Problem des Nutzers. Diese gehen oftmals an Web-basierte Applikationen heran als wären dies Dokumente und erwarten die gleichen Verhaltensweisen oder sind überfordert, wenn irgendetwas nicht so funktioniert, wie sie es gewohnt sind. Das liegt unter anderem auch daran, dass eben die Hilfsmittel teilweise so strikt sind!

Was sich in Tests auch immer wieder zeigt: Viele Nutzer von Screenreadern haben massive Probleme durch für sie ungewohnte Dynamik. Insbesondere Screenreader sind lineare »Wesen«, die sich immer nur an einem Ort in der Zeit aufhalten. Was sich da auch zeigt - und damit schließt sich der Kreis wieder zu dem Thema »Flash, AJAX...«, dass das Problem nicht in der Art liegt, wie die Änderung zustande gekommen ist, sondern in der Änderung als solcher: Wir hatten in Tests nahezu vergleichbare Probleme der Nutzer von Screenreadern in punkto Orientierung auf dynamischen Inhalten - also: Wo hat sich etwas geändert? - Wie komme ich dorthin - und wieder weg? Wie kann ich das selbstbestimmt steuern?

Wir hatten also die gleichen Probleme bei den Tests, egal, ob das jetzt über AJAX (also es wird eine Seite ohne Neuladen dynamisch geändert und die Inhalte von außen hineingeschrieben) oder über einen statischen Reload, also über eine rein statische HTML-Seite ohne Java-Skript oder irgendetwas anderes.
Es waren im Prinzip durchaus vergleichbare Probleme, was die Vermutung, denke ich, zulässt: Das Problem ist nicht die Dynamik, sondern die Änderung allgemein!

Beispiele sortiert nach den 4 Prinzipien: POUR

Bei aller Kritik an den Richtlinien, die Grundlagen sind schon sehr gut und man kann sie auch heute bereits zur Bewertung von Web2.0-Anwendungen hernehmen. Deswegen möchte ich Ihnen jetzt ein paar praktische Beispiele zeigen von Dingen, die man machen sollte und Dingen, die man tunlichst nicht machen solte - das ganze sortiert nach den vier Prinzipien der WCAG 2.0

Sie sehen hier die vier grundlegenden Prinzipien aus dem aktuellen Entwurf - Perceivable, Operable, Understandable und Robust. Das sind die Prinzipien, die Sie im Design und in der technischen Umsetzung ihrer Webangebote beherzigen sollten, nicht mehr und nicht weniger.
Hier das ganze nochmal auf Deutsch: Wahrnehmbar, Bedienbar, Verständlich und Robust.

P - Wahrnehmbar

Ein paar Beispiele aus dem Bereich der Wahrnehmbarkeit: Eine typische Einstellung für stark sehbehinderte Nutzer sind die Windows-Kontrastschemata. Zur Vermeidung von Blendeffekten und Überstrahlung werden radikal alle Farben nach Vorgabe des Nutzers geändert. Viele Angebote werden aber offensichtlich nie mit benutzerdefinierten Farben getestet.

Zu sehen ist hier ein Screenshot von Basecamp, einer Ur-Web2.0-Anwendung.

Problem Nr.1: nahezu sämtliche Formatierungen sind weg (außer Positionierung und Ränder) d.h. Farbflächen und andere Farbinformationen, die zur Orientierung diesen, können nicht mehr wahrgenommen werden.

Problem Nr.2: wenn der Benutzer eine eigene Hintergrundfarbe einstellt, dann meint er oder sie das auch so. Wenn Textgrafiken mit Transparenzen verwenden, dann sind diese Transparenzen auch weiterhin da. Das Resultat: schwarzer Text auf schwarzem Hintergrund.

Trick Nr.1: Ränder- auch Sehbehinderte haben ein Recht auf Gestaltung. Im Umkehrschluß haben Sie als Anbieter auch eine Pflicht zur Gestaltung für die Bedürfnisse Sehbehinderter. Übrigens ohne dass man das in der »Normaleinstellung« sieht!

Trick Nr.2: (der eigentlich kein Trick ist) Textgrafiken nicht freistellen oder zumindest soviel Fleisch zugeben, dass der Text darin lesbar bleibt.

Ein weiteres Problem der Wahrnehmbarkeit bzw. der Orientierung: Was passiert, wenn sich 'zig Sachen gleichzeitig ändern? Bei »Dow Jones Marketwatch« kam jemand auf die kluge Idee, hinter alle Firmennamen die Börsenkurse einzublenden und diese in Echtzeit per AJAX zu aktualisieren.
Hier werden auch die WAI ARIA Live Regions nicht helfen, denn auch damit stellt sich immer noch die Frage: Will der Nutzer alle zwei Minuten über neue Kurse informiert werden? Beim Lesen eines Artikels? Ich möchte nicht wissen, was dabei im Screenreader passiert. Die richtige Antwort auf die Frage wäre hier: so einen Unsinn sein zu lassen.

O - Bedienbar

Ein paar typische Barrieren aus dem Bereich der Bedienbarkeit
Hier ein schönes Beispiel, über das ich bei der Flugbuchung für die heutige Veranstaltung gestolpert bin: bei Germanwings habe ich die Wahl, am Ersten, am Ersten oder am Ersten zu fliegen. Ich hatte das Beispiel neulich bei einer Schulung in einer Agentur verwendet. Was ich nicht wusste, war, dass einer der Entwickler mit am Tisch saß. Der hat das gleich am nächsten Tag geändert.

Auf der Startseite von Germanwings findet man nun einen anderen Kalender, aber weiter hinten im Buchungsprozeß sieht's immer noch genau so aus wie im Screenshot.

Fazit: unbedingt alternative Plattformen und vermeintlich exotische Browser testen, oder gleich etwas Vernünftiges nehmen - wie im folgenden Beispiel.
Live-Demo (in CAMINO):

Es nennt sich: »Unobtrusive Date-Picker Widget Update« (www.frequency-decoder.com/2006/10/02/unobtrusive-date-picker-widgit-update/) »Widgets« lässt sich nicht übersetzen - in Köln sagt man dazu »Dingens«, ich weiß nicht, wie man in Wien dazu sagt...

Ich gehe jetzt einmal mit der Tab-Taste durch, gehe ins erste Feld. Da blinkt es, und dann kann ich ganz normal mit Standard-Tastatur-Befehlen dann tage-, wochen- und monatsweise weitergehen. Mit control shift geht dann sogar das Datum weiter. Da können Sie sich einmal damit ´rumspielen, es macht richtig Spaß, dieses Ding!

Das ist barrierefrei nutzbar, in diesem Fall - mit Java Script, und hilft sehr vielen Leuten, die sich sonst das Datum selbst ausdenken müssen.

Statement aus dem Publikum: Und mit einem Screenreader? Wie läuft da die Auswahl?

Tomas Caspers: Das ist dann eine echte Datentabelle. Da kann man die entsprechenden Vorkehrungen treffen, dass die Tage dann etwa als Freitag, der 13. angesagt werden.

Ein anderes Beispiel für mangelnde Bedienbarkeit ist diese Demo-Seite, mit der Yahoo sein neues Finanz-Portal erklärt. Mit der Maus ist das alles wunderbar zu bedienen: Da geht dann so ein Fähnchen auf, und in diesem Fähnchen stehen dann noch weitere Informationen. Wenn ich aber bei Tastaturbedienung mit der Tabtaste durchzugehe, passiert gar nichts.

Der einfache Grund: der oder die Entwickler haben schlicht vergessen, dieses Nutzungszenario zu berücksichtigen. Ich zeige Ihnen einmal kurz, wie man das mit ein paar Zeilen Code nachrüsten kann:
Live-Beispiel: bei help.yahoo.com/tours/finance/pagetour.html :focus einbauen.

Bei der Diskussion von Barrieren im Web2.0 darf natürlich flickr nicht fehlen. Den Herrn hier im Bild kennen Sie vielleicht, er war ja auch einmal in Wien (wenn auch beim falschen Verein), jetzt ist er wieder da, wo er hingehört. Bei flickr werden die Bilder zunächst einmal so benannt, wie sie von der Digitalkamera kommen.
Dann kann man die Bilder umbenennen - das muss man erst einmal entdecken und verstehen - Barriere Nummer 1. Zum Ändern muss man dann mit der Maus auf den Titel klicken - Barriere Nummero 2.

Diese kognitive Ebene ist also erst einmal zu begreifen. Das ist aber eher so ein spielerisches Element. Wenn man da in der Anwendung herumklickt und sie für sich erkundet, kommt man dann drauf. Aber geräteunabhängig bedienbar ist das tatsächlich nicht.
Die einzige mögliche Lösung: weil solche Funktionen unmöglich für alle Nutzer funktionieren können hat flickr die problematischen Funktionen nochmal statisch hinterlegt. In diesem Fall ist es, denke ich, wirklich legitim, es so zu machen!

Nächster Punkt aus dem Pour:

U - Verständlich

Kommen wir zum Bereich Verständlichkeit: Ich bitte um Verständnis, dass ich zu dem Thema nicht viel sagen werde. Das ist nicht gerade mein Fachgebiet und andere können das viel besser.
Ob solche Dinge wie dass die Erklärung von Abkürzungen »programmatisch determinierbar« sind, oder ob Sprachauszeichnungen wirklich irgendwem nützen sind auch unter Anwendern umstritten sind. Wichtige Punkte wie die Integration von Nutzern mit kognitiven Behinderungen sind hingegen noch weitgehend unerforschtes Neuland - auch in den Richtlinien. Es bleibt abzuwarten, ob die BIENE-Studie hierzu ein paar genauere Aussagen macht.

R - Robust

Das vierte Prinzip: Robust. Unter Robustheit wird gemeinhin Standard-Konformität (also valider Code und ähnliches) verstanden. In den Richtlinien steht aber auch, dass ein Angebot mit aktuellen und zukünftigen assistiven Werkzeugen funktionieren muss. Und das ist es, was im Kontext der Web-Accessibility eigentlich mit dem Begriff »Robustheit« gemeint ist.

Wenn man sich ein wenig mit den gängigen Hilfsmitteln beschäftigt, dann gibt es zwei Kernbereiche bzw. zwei Problemfelder, die immer wieder auftauchen: Bedienelemente und Dynamik. Gerade die ungewohnte Dynamik ist etwas, dass Hilfsmitteln wie Screenreadern und damit deren Nutzern immer wieder Probleme bereitet.

Bei Aktualisierungen von Inhalten innerhalb der Anwendung treten übrigens die gleichen Probleme in Hilfsmitteln auf, egal ob dies in einer Flash-basierten Seite oder per AJAX geschieht. Das Problem entsteht auch hier wieder im Hilfsmittel: die Seite wird einmal in den Speicher eingelesen, irgendwelche Events, die nach dem Laden (in den Speicher des Screenreaders) geschehen, werden zumindest im JAWS »virtual PC cursor mode« oder in Window-Eyes im »browse mode« komplett ignoriert. Selbst wenn die Aktualisierung durch einen kompletten Relaod einer ansonsten statischen Seite zustande gekommen ist, gibt es kein einheitliches Muster, wie der Nutzer in verschiedenen Hilfsmitteln auf die Änderungen aufmerksam gemacht wird.

Abhilfe schafft da in Zukunft, zumindest für den rein technischen Teil der Probleme die WAI-ARIA-Empfehlung und gibt dem Nutzer damit die Kontrolle zurück, sich dort über Änderungen zu informieren.

Damit kann man Bereiche definieren, in denen sich öfter einmal etwas tut. Das ist jetzt eine komplett designfreie Demo, das ist ein AJAX basierter Chat von Charles Chen, den kennen Sie vielleicht von Fire Vox.
Das ist eine Erweiterung von FireFox, das ist so eine Erweiterung für JAWS, da bekommen Sie also sie also in FireFox etwa so den Output, wie in JAWS vorlesen würde. Das ist alleine deshalb so spannend, weil wir ja gerade im Web2.0 sind spielt der soziale Aspekt der Barrierefreiheit hier mit rein. Dadurch werden Menschen mit Behinderungen Wege der Kommunikation eröffnet, die Ihnen ohne Barrierefreiheit verschlossen blieben.
Passend dazu ein schönes Beispiel, in dem das schon eingebaut ist: der AJAX-Chat von Charles Chen, den einige vielleicht von seiner Fire Vox-Erweiterung für Firefox kennen.
Eine Live-Demo macht keinen Sinn, weil ich hier auf meinem Mac leider keinen Screenreader habe, mit dem das funktioniert - da sind Macs leider hinterher - deswegen gibt's nur eine Bildschirmfoto. Sie können das aber gerne einmal selbst ausprobieren: accessibleajax.clcworld.net

Wie das technisch genau vonstatten geht, sehen sie gleich im nächsten Vortrag.
Danke fürs Zuhören.

Applaus

Eva Papst: Vielen Dank für diesen sehr spannenden Vortrag. Ich glaube, es ist niemandem von uns bewusst gewesen, dass es fast eine Stunde gewesen ist!

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

(Transkription auf Basis eines Textes des Autors von Gerhard Wagner, www.freak-online.at)

---