11. November 2007, von Eva Papst

Der K(r)ampf mit AJAX

Seit Beginn der Blog Parade frage ich mich, wo denn die ExpertInnen in Sachen Flash oder AJAX geblieben sind. Ich vermisse die Wortmeldungen all der vorwärtseilenden Geister, die sich – zu Recht oder zu Unrecht – beklagen, dass modernste Techniken, z.B. AJAX, von Screen Readern so schlecht unterstützt werden. Ich könnte hier gut ein wenig Nachhilfe gebrauchen.

Denn auch, wenn ich oft als Expertin bezeichnet werde – ich mag diese Definition absolut nicht, weil sie falsche Assoziationen auslöst – bin und bleibe ich die “mit einigen Wassern gewaschene” Webanwenderin, unterstützt durch mehrere Screen Reader – also nur Expertin in eigener Sache.

Als interessierte und neugierige Anwenderin werde ich natürlich immer wieder mit AJAX & Co. konfrontiert – in Tests genauso wie auf freier Wildbahn.

Und weil ich es schade finde, dass aus der echten Expertenecke für diese Techniken kein Input gekommen ist, schreibe ich zum Abschluss der Blog Parade eben einen Anwenderbericht – aus Sicht des Frontends, über das ein Screen Reader gestülpt ist und ohne nennenswerte Kenntnis der Technik unter der Motorhaube.

Ich stelle hier zwei Beispiele von AJAX-Anwendungen vor, die mir in letzter Zeit begegnet sind. Die fundierte technische Analyse, warum mich meine Screen Reader in einem Beispiel im Stich lassen, während sie mich im anderen ausreichend unterstützen, muss ich aus Mangel an Kenntnis den wahren ExpertInnen auf diesem Gebiet überlassen und hoffe auf entsprechende Aufklärung.

Zwei Beispiele

Im Chat auf Webdesign Weisshart werden die Nachrichten mittels AJAX in die Seite geschrieben. Schreibe ich selbst eine Nachricht und sende sie ab, so wird durch das Absenden der Nachricht und Neuaufbau der Seite automatisch aktualisiert und ich kann die Nachricht danach auch lesen. Beim Einlangen einer Nachricht ist das Verhalten meiner Programme anders, wie Sie der kleinen Anwenderanalyse entnehmen können.

Das zweite Beispiel kennen vermutlich viele: Tippe ich in das Suchfeld auf Einfach für alle z.B. “zug” ein, wird via AJAX eine Liste mit möglichen Suchbegriffen eingeblendet. Das ist sehr komfortabel, weil AnwenderInnen nun entscheiden können, ob in den Vorschlägen der von Ihnen gesuchte Begriff bereits enthalten ist. Ist dies nicht der Fall, wird einfach weiter eingetippt.

Diese mittels AJAX eingeblendete Liste ist mit keinem von mir verwendeten Screen Reader “sichtbar”.

Kleine Anwenderanalyse

Gemeinsam ist diesen Beispielen auf den ersten Blick nur, dass es sich um AJAX-Anwendungen handelt.

Was machen nun Screen Reader mit solchen Techniken? Anders als beim Neuaufbau einer Seite reagieren Screen Reader nicht unmittelbar auf die Änderung mittels AJAX. Was auf den ersten Blick wie ein Bug aussieht, ist aber eigentlich ein Feature, denn die einzige Möglichkeit wäre, den Focus an jene Stelle zu setzen, an welcher die hinzugekommene Information erscheint. Das ist aber in den meisten Fällen nicht im Sinne der NutzerInnen, die vielleicht zuerst ihre eigene Eingabe beenden oder einen begonnenen Absatz in Ruhe zu Ende lesen möchten.

Betrachten wir also das Schreiben von Nachrichten im Chat etwas näher. Beim Absenden der eigenen Nachricht weiß ich natürlich, dass sich der Bildschirminhalt geändert haben muss und kann mich auf die Suche nach der Neuerung machen.

Beim Einlangen von Nachrichten anderer Chat-Teilnehmer reagiert der Screen Reader nicht aktiv auf den geänerten Seiteninhalt. Es muss vielmehr vom Nutzer selbst aktualisiert werden, der irgendwie Kenntnis von der Änderung erlangen muss.

Um das Einlangen einer neuen Nachricht auch AnwenderInnen von Screen Readern mitzuteilen, hat daher der Autor mit diesem Ereignis einen Sound verknüpft, (der anwenderseitig natürlich aus- und eingeschaltet werden kann). Auf diese Weise erfahre ich, wenn jemand eine Nachricht geschrieben hat und kann mich entscheiden, ob ich meine eigene Nachricht noch abschicken (und somit gleichzeitig die Seite aktualisieren) oder zuvor die neu eingegangene Nachricht lesen möchte. In letzterem Fall ist dann allerdings eine händische Aktualisierung erforderlich. Der Sound macht das Handling aber sehr komfortabel.

Im Beispiel der Suche gibt es keine Information, wann die offerierte Liste auftaucht und sie wird in den unterschiedlichsten Screen Readern auch nicht angezeigt.

Das ist auch verständlich und nicht lösbar?, denn um die Liste einzublenden, müsste die Seite aktualisiert werden, was das Leeren des Formulars zur Folge hätte.

Zugänglich und nutzbar

Es wäre nun völlig verfehlt, aus dem bisher Gesagten den Schluss zu ziehen, dass es sich um ein “gutes” und ein “schlechtes” Beispiel für den Einsatz von AJAX handelt, denn ganz so ist es nicht.

Während das Lesen der Nachrichten im Chat zur Grundfunktionalität desselben gehört, handelt es sich bei den in der Suche eingeblendeten Begriffen um keine Grundfunktion, sondern ein hilfreiches Feature, das jedoch für die Nutzung der Suchfunktion absolut nicht erforderlich ist.

Auf den Nutzen kommt es an

Gleichgültig, welche Techniken man anwendet, der von Jan Eric Hellbusch ins Spiel gebrachte Begriff der Gebrauchtstauglichkeit sollte dabei nie aus dem Blickfeld verschwinden. Was genau ist aber darunter zu verstehen?

Zur Verdeutlichung hier wieder zwei Beispiele aus dem Weballtag:

• Wird eine Telefonnummer als Grafik präsentiert und nicht mit einem gleichwertigen Alternativtext beschriftet, so kann jemand, der die Grafik nicht erkennt, die Nummer auch nicht anrufen. Bei einer Hotline oder einer Notrufnummer wäre dies besonders schlimm.
• Ist eine Schaltfläche zum Absenden eines Formulars nicht mit der Tastatur erreichbar oder nicht erkennbar, wo genau sich der Focus befindet, können auf Tastaturnutzung angewiesener AnwenderInnen die Aktion nicht auslösen.

Auf die beiden eingangs skizzierten Anwendungen im Chat und der erweiterten Suchfunktion könnte man also sagen:

Ein Chat, dessen Nachrichten mit assistiven Programmen nicht lesbar sein sollten, wäre natürlich unbedienbar und somit nicht gebrauchstauglich, während die Suchfunktion auch ohne die zusätzlich angebotene Hilfestellung voll funktionstüchtig, also gebrauchstauglich bleibt.

Eine beispielsweise mit Screen Reader nicht nutzbare Technik stellt nicht zwangsläufig automatisch eine Barriere dar. Sie wird aber dann zu einer solchen, wenn dadurch BesucherInnen von der Benutzung bestimmter Dienste ausgeschlossen werden oder ihnen diese Nutzung deutlich erschwert wird.

Und dennoch: Ich wüsste zu gerne, ob es tatsächlich nur auf die fehlende aktive Aktualisierung der Seite zurückzuführen ist, dass meine Programme AJAX einmal unterstützen und dann wieder nicht. Ich hoffe nur, dass ich auf die Antwort nicht bis zur nächsten Accessibility blog-Parade warten muss.

Bleibt mir noch MAIN und Nur ein Blog für die Initiative zur Accessibility Blog Parade und die gewährte Gastfreundschaft zu danken.

11. November 2007 · Eva Papst · Thema: Barrierefreiheit, Blog Parade, Internet · Tags: accessibility, accessibilityblogparade, blog, Blog Parade, web
· Sie können einen Kommentar schreiben, oder einen Trackback auf Ihrer Seite einrichten.