accessCast

Der Versuch einer Positionsbestimmung

Zurzeit machen eine ganze Reihe neuer Schlagwörter die Runde, mit denen umschrieben wird, wie wir alle in Zukunft das Web wahrnehmen und nutzen sollen. Web two point oh oder Web Zwei Punkt Null, das Schreib-/Lese-Web, Software als Service oder auch technische Details wie Ajax sind ein paar Beispiele, mit denen wir uns heute mal etwas intensiver beschäftigen wollen.

Was dieses Web zwei punkt null-Dings denn nun genau ist, darüber besteht weitestgehende Uneinigkeit. Der gemeinsame Nenner und gleichzeitig die Abgrenzung zur Versionsnummer Eins Punkt Null scheint aber zu sein, dass das Web nicht mehr nur als passives Einbahnstraßenmedium gesehen wird. Nutzer können und sollen sich aktiv an der Gestaltung der Inhalte beteiligen und erobern so das Netz zurück. Oder, wie ein Systemadministrator ausdrücken würde: chmod 777 Web.

Webseiten bieten Funktionen an, die bisher den klassischen Desktop-Anwendungen vorenthalten waren, oder für die man aufwändige Redaktionssysteme brauchte. Das geht bis zu ganzen Anwendungen aus dem Office-Bereich, die vollständig im Browser laufen. Gleichzeitig verschwimmt die Grenze zwischen Desktop und Web immer weiter. Der Anwender merkt bei vielen Angeboten und Diensten schon gar nicht mehr, ob er noch auf dem eigenen Rechner arbeitet oder auf einem entfernten Server.

Der Berliner Webdesigner Markus Angermeier hat vor einiger Zeit versucht, die vielen Schlagworte in einer absolut Web2.0-tauglichen Tagcloud darzustellen, den Link dazu finden Sie wie immer in der Mitschrift zu diesem Podcast. Darin sind die Gewichtungen und Zusammenhänge von Standardisierung und Einfachheit, von offenen Daten, Protokollen und Schnittstellen, und ganz wichtig, die Partizipation der Nutzer schön zu erkennen.

Genau diese Teilnahmemöglichkeit steht auf der Kippe oder ist für einige Nutzergruppen kaum vorhanden. Während die Urversion des Webs eine Ansammlung weitestgehend statischer Texte war und auch die Regeln zur Barrierefreiheit größtenteils auf diesen Typus von Webinhalten abzielen, prägt das neue Web sehr viel Dynamik. Genau diese Dynamik ist es, die Anbietern und Webentwicklern Kopfschmerzen bereitet, wenn sie ihre Websites für möglichst viele Nutzer zugänglich gestalten wollen.

Typische Anwendungsfälle

Schauen wir uns doch zunächst mal ein paar typische Anwendungsfälle für Techniken wie Ajax an:

Einfache Beispiele, an denen sich sehr schnell der Nutzen von dynamischen Inhalten erklären lassen sind Google Suggest und Yahoo! Livesearch. Bei diesen Webanwendungen werden Eingaben in die Suchbox per JavaScript abgefangen und automatisch an die Server zurückgeschickt bevor der Nutzer das Formular absendet. Die Server wiederum schicken fast in Echtzeit passende Treffer zurück, die sofort angezeigt werden. Nutzer bekommen also ein unmittelbares Feedback über die Erfolgsaussichten der eingegebenen Suchbegriffe, ähnlich lautende Treffer oder sogar Rechtschreibvorschläge bei Tippfehlern.

Der Nutzen aus Sicht der Anwender ist so offensichtlich, dass wir eine ähnliche Technik beim letzten Relaunch auch auf unseren Seiten eingebaut haben. Nutzer, die ausgefeilte Suchstrategien oder womöglich sogar die Verknüpfung von Suchbegriffe mit Operatoren nicht beherrschen bekommen direktes Feedback über mögliche bessere Suchbegriffe, Menschen mit Lese-/Rechtschreibschwäche dürfen sich schonmal vertippen, und das Beste: das ganze ist in modernen Screenreadern vollständig nutzbar.

Das sind typische Funktionen von einfachen Ajax-basierten Anwendungen, zumindest aus technischer Sicht:

• Daten zum Server schicken,
• Daten vom Server empfangen und in bereits bestehende Inhalte einbauen und
• Inhalte umsortieren

Die dahinter stehenden Techniken sind nicht wirklich neu: XML, ECMAScript (vulgo: JavaScript) und das XMLHTTP-Objekt sind robuste Techniken, die von allen modernen grafischen Browsern unterstützt werden. Diese Techniken sind standardisiert oder befinden sich im Prozess der Standardisierung durch das W3C.

Der Nutzer braucht eine Zugangssoftware, die diese Techniken beherrscht um Ajax-basierte Anwendungen vollständig nutzen zu können. Gleichzeitig muß der Webdesigner Vorkehrungen treffen für den Fall, dass eine der eingesetzten Techniken nicht genutzt werden kann, auch um die Regelwerke der Barrierefreiheit BITV bzw. WCAG zu erfüllen. Im Fall der Livesuche ist das noch ganz einfach zu bewerkstelligen: wenn JavaScript nicht ausgeführt wird, kann der Nutzer trotzdem immer noch googeln – die Kernfunktionalität ist also gegeben, wenn auch nicht so unmittelbar und so komfortabel wie in der dynamischen Variante.

Das Prinzip dahinter ist ganz einfach und wird wohl am treffendsten von Jeremy Keith beschrieben, der gleich das passende Buzzword dazu kreiert hat: Hjijax. Am besten lassen wir ihn selbst beschreiben, was er damit gemeint hat:

Der Begriff Hijax bedeutet soviel wie die Progressive Enhancement, die schrittweise Verbesserung einer Webseite durch Ajax. Um eine Ajax-Anwendung zu bauen, solltest du anfangen mit einer ganz normalen Webseite, die Links und Formulare benutzt, um Daten an den Server zu schicken. Der Server schickt ganze Seiten zurück.

Du kannst diese Links und Formulare dann abfangen, oder hijacken. Statt die Daten an den Server zu schicken, schickst du die zum XHR-Objekt. Der Server liefert dann nur den Teil der Seite, die aktualisiert werrden muss. Das Resultat ist Ajax-Anwendung. Gewisse Teile der Webseite werden aktualisiert, ohne die ganze Seite neu laden zu müssen. Sie ist aber eine Ajax-Anwendung mit Abwärtskompatibilität, oder: Graceful Degradation.

Oder, um das Ganze noch weiter zu verkürzen:

• Planen Sie Ajax von Anfang an mit ein.
• Implementieren Sie Ajax erst am Ende.

Die Vorteile für Anbieter liegen auf der Hand: die Serverlast wird teilweise dramatisch reduziert. Bei kleineren Angeboten fällt dies kaum ins Gewicht; bei einer Auktionsseite, bei der die zu versteigernden Sachen von jedermann eingestellt werden können, ist die Serverlast erheblich. Die Erfahrung hat gezeigt, dass der dabei produzierte Code so groß ist, dass das Laden der Seiten zu Qual wird. Kurz vor Ablauf einer Auktion drücken alle Interessenten auf Reload, um zu erfahren, wer das Höchstgebot abgegeben hat. Bei großen Auktionshäusern mit vielen gleichzeitigen Auktionen bedeutet das nicht nur ein bisschen mehr Bandbreite, sondern ein ganzes Rechenzentrum um so etwas abzufedern. Dabei wird eigentlich nur eine Zahl ausgetauscht.

Sie merken - der Einsatz von Ajax ist auch aus ökonomischer Sicht durchaus sinnvoll, da hiermit nur, um beim aktuellen Beispiel zu bleiben, das aktuelle Höchstgebot ausgetauscht wird. Und mit dem oben skizzierten Ansatz funktioniert das sogar abwärtskompatibel bis hin zum reinen Textbrowser.

Tja, wenn da nicht der Typ Anwendungen wäre, bei dem konzeptionsbedingt nichts mehr gehen kann, wenn zum Beispiel JavaScript nicht vorhanden ist oder nur unzureichend unterstützt wird?

Das sind die Problemfälle

Neben den genannten Beispielen, wo Ajax ausschließlich als Sahnehäubchen zur Verbesserung der Benutzerfreundlichkeit eingesetzt wird gibt es einen anderen, ganz neuen Typus von Web-basierten Applikationen, die bestimmte Techniken zwingend voraussetzen. Techniken, ohne die systembedingt nichts mehr geht.

Den Anfang machten E-Mail-Dienste wie gmail, komplette Textverarbeitungen wie Writely und ajaxWrite, Kalenderdienste wie Kiko oder Google Calendar. Richtig viel Rauschen in der Blogosphäre verursachten auch die Entwickler von AjaxLaunch.com, die nicht nur ein Zeichenprogramm, eine Textverarbeitung und eine Tabellenkalkulation mit allen wichtigen Funktionen komplett im Firefox nachbildeten, sondern gleich auch noch das passende Betriebssystem mitlieferten. Bei Diensten wie Ning oder Zoho kann der Anwender sich seine Anwendungen sogar mit ein paar Mausklicks selbst zusammenbasteln.

Der berühmte Fallback auf statische Techniken, wie ihn die BITV fordert ist in dem Fall nicht anwendbar, es sei denn man wertet einen Doppelklick auf ein vorhandenes Office-Paket als möglichen Fallback. Allerdings kostet diese Alternative den Anwender hunderte Euros, während die Web-basierten Angebote üblicherweise frei zu nutzen sind.

Hier ist die spannende Aufgabe nicht mehr, wie man diese Anwendungen auch für den Fall benutzbar macht, wenn der Client bestimmte Techniken nicht mehr unterstützt. Gerade im Sinne von Menschen mit Behinderungen, die vielfach auf assistive Hilfsmittel beim Umgang mit Webbasierten Inhalten angewiesen sind sollte die direkte Zugänglichkeit dieser Anwendungen sichergestellt werden.

Auftritt Barrierefreiheit 2.0 - biologisch abbaubares Ajax

Was sind die besonderen Probleme, denen Menschen mit Behinderung bei der Nutzung von dynamischen Web-Applikationen gegenüberstehen? Und welche Richtlinien lassen sich anwenden? Die Antwort auf diese Fragen hängt von den speziellen Bedürfnissen der Menschen mit Behinderungen ab.

Für motorisch behinderte Menschen, die auf Hilfsmittel zur Steuerung und Eingabe angewiesen sind, reichen eigentlich schon die Vorgaben der BITV zur Geräteunabhängigkeit. Unser Tipp: stellen sie einfach sicher, dass Ihre Anwendung komplett mit der Tastatur bedienbar ist. Weitere Hilfen wie die bekannte Yellow Fade-Technik zur Hervorhebung geänderter Bereiche helfen wiederum allen Nutzern, die sich optisch orientieren. Für Menschen mit Lernbehinderung, gehörlose oder schwerhörige Nutzer besteht das Zugangsproblem weniger auf der technischen Ebene, sondern auf der Seite der Inhalte - hier sind bereits die Konzepter und Redakteure gefragt, bevor es an die technische Umsetzung der Anwendung geht.

Bleiben noch blinde und sehbehinderte Menschen. Blinde Nutzer sind generell und stark sehbehinderte Nutzer sind oftmals auf spezielle Software angewiesen, die den Zugang und die Bedienung zu Webinhalten jeglicher Art überhaupt erst ermöglichen.

Dabei muss man sehr deutlich zwischen vollblinden Nutzern und Nutzern mit Sehrest unterscheiden, denn Letztere orientieren sich nach wie vor visuell. Ein für blinde Screenreader-Nutzer vollkommen zugängliches Formular kann für Sehbehinderte unmöglich zu bedienen sein und andersrum. Ein Formular, in dem Fehlermeldungen mit dem Ort des Eingabefehlers sinnvoll verknüpft sind, ist im Screenreader sehr gut nutzbar, da beides per Hyperlink innerhalb der Anwendung oder des Formulars erreichbar ist.

Für Nutzer von Lupensoftware ist dies nicht automatisch gegeben, da je nach Grad der Vergrößerung sowohl der Fehler als auch die Fehlermeldung weit außerhalb des Bildschirmausschnittes liegen, den der Benutzer wahrnehmen kann. Unser Tipp: platzieren Sie Fehlermeldungen oder Hinweise auf Fehleingaben in unmittelbarer Nähe des Absenden-Buttons oder realisieren Sie diese als modalen Dialog (Alert).

Für Screenreader ist es ausgesprochen schwierig, dynamische Änderungen an mehr als einer Stelle im Dokument zu verfolgen und dem Nutzer angemessen wiederzugeben. Dies liegt in der Natur von Screenreader-Programmen, die immer nur linear eine Sache nach der anderen abarbeiten können. Einzelne Änderungen, die mit Ajax realisiert werden, sind für moderne Screenreader hingegen kein Problem mehr. Wie eigene Tests und Testreihen wie die von James ›Brothercake‹ Edwards, Gez Lemon, Bob Easton sowie Joe Clark gezeigt haben kommen die aktuellen Versionen von JAWS, WindowEyes & Co. hervorragend mit modernen Scripting-Techniken zurecht.

Problematisch wird es für Screenreader, wenn Inhalte an mehreren Stellen im Dokument gleichzeitig ausgetauscht werden und wenn sich diese Stellen im Dokumentenbaum vor der Stelle befinden auf der der aktuelle Fokus liegt. Typische Anwendungszwecke sind die Manipulation tabellarischer Daten z. B. durch Neuberechnungen oder zeitabhängige Aktualisierungen wie bei Börsenkursen. Generell ist die Wahrnehmung und Bedienung solcher Inhalte und Funktionen kein Problem, sobald der Screenreader in den Formularmodus geschaltet wird.

Die Wahrnehmung des Ergebnisses hängt jedoch stark vom verwendeten Screenreader ab: so vertüddelt sich WindowEyes schon mal gerne oder ignoriert auch kurzerhand sämtliche Hinweise, die ein gewissenhafter Webentwickler in die Anwendung eingebaut hat. Bisher ebenfalls unbefriedigend gelöst sind Fälle, in denen sich eine Datentabelle innerhalb eines Formulars befindet (was bei vielen Web-basierten Anwendungen eher die Regel als die Ausnahme ist). Wenn aufgrund von Nutzereingaben im Formular die Daten in der Tabelle geändert werden, so wird dies nach unserem Kenntnisstand nicht an den Benutzer weitergereicht. Zur Bedienung des Formulars muss der Screenreader im Formularmodus sein, zum Lesen der Tabelle hingegen im Tabellenmodus – ein Problem gegen dass der Anbieter streng genommen nichts machen kann.

Einen Tipp zur Lösung dieser Probleme können wir hier nicht abgeben – dazu ist dieses Gebiet noch zu neu. Eine empfehlenswerte Lektüre zu diesem Thema sind aber auf jeden Fall die Authoring Tool Accessibility Guidelines des W3C (ATAG) - der Sinn der meisten Web 2.0-Anwendungen besteht in den Interaktionsmöglichkeiten für den Nutzer, also fallen diese Anwendungen in die Kategorie Autorenwerkzeuge, und damit sind die ATAG viel eher anwendbar als die WCAG bzw. die BITV.

So, das war die dritte Ausgabe unseres wöchentlichen Podcasts zum Thema barrierefreies Webdesign. Weitere Meldungen zum Thema der heutigen Sendung finden Sie im Weblog von ›Einfach für Alle‹ unter dem Tags Ajax, Web 2.0 und Hilfsmittel. Die Links zu allen Anwendungen und Artikeln finden Sie wie üblich in der Mitschrift zu diesem Podcast.

Wenn es Ihnen gefallen hat hören wir uns nächste Woche wieder.