Unter dem Begriff "Ajax" verstehen IT-Experten den Einsatz von Javascript und XML unter den Bedingungen des
Web 2.0.
Mit dieser Technik wird es möglich, Inhalte innerhalb einer Internet-Seite nach bestimmten Interaktionen zu ändern, ohne dass die gesamte Seite neu geladen wird.
Bei allen Diskussionen über Ajax und Web 2.0 befassen sich aber zu wenige Beiträge mit dem Thema "Barrierefreiheit".
Der bislang bekannteste Artikel in englischer Sprache findet sich unter
http://www.standards-schmandards.com/2007/rapid-accessibility-feedback/.
James Edwards weist in seinem Artikel unter
http://www.sitepoint.com/article/ajax-screenreaders-work darauf hin, dass die bisherigen Texte JavaScript eher ausblenden. Ferner unterstützen die browser-internen Screen-Reader JavaScript-Belange in der Praxis zu wenig. Wahrscheinlich meint er damit die Behandlung und Meldung von Ereignissen.
Edwards meint, dass einige Artikel fordern, der Benutzer solle von den dynamischen Veränderungen auf den Seiten informiert werden und diese sollen direkt zugänglich gemacht werden. Kein Artikel stellt jedoch dar, wie das aus Entwicklersicht umzusetzen sei. Daher will er mit seinem Artikel ein paar Lösungsvorschläge präsentieren, die diese Problematik eingrenzen sollen.
Edwards untersuchte mit Bob Easton, Derek Featherstone und Mike Stenhouse zusammen, wie sich bekannte Screenreader und andere assistive Techniken beim Einsatz von JavaScript verhalten und welche Event-Handler (Ereignisbehandlungsroutinen von JavaScript) diese unterstützen.
Insgesamt sei die JavaScript-Unterstützung sehr unbeständig und fragmentiert. Kein Problem seien für fast alle Screenreader das Generieren von Mausklick-Ereignissen oder Ereignissen, die bei der Formular-Bearbeitung ins Spiel kämen. Dagegen sei die Änderung von Inhalten, also dynamischer Content, noch ein sehr großes Problem: die Benutzer erfahren meist nicht, wann und wo sich Inhalte verändert haben.
Für Sehbehinderte gibt es noch die Möglichkeit, mit visuellen Effekten die Aufmerksamkeit zu erregen und auf die Veränderung der Inhalte zu lenken. Bei blinden Personen wird das jedoch nicht funktionieren, denn sie erarbeiten sich die Inhalte der Seiten linear.
Nun führte der Autor mit dem Team ein paar Tests durch:
Test 1: Aktualisierung eines Absatzes mit Text unter einem Link, wenn dieser Link angeklickt wurde.
Ergebnis: Fast alle Screenreader führen die Aktualisierung des Textes aus, aber keiner liest die Änderungen automatisch vor. Bei Windows Eyes wurde die Sprachausgabe nicht aktualisiert, wenn der Reader die Seite weiter vorlas, ohne dass der Benutzer weitere Tastaturbefehle eingab.
Ziel dieses Tests: Was kann getan werden, damit der aktualisierte Abschnitt automatisch ohne weitere Benutzerinteraktionen vorgelesen wird?
Test 2: Dieser Test entspricht dem ersten Test, nur dass der Absatz, der sich ändern wird, mit einem Anker versehen wird. In der JavaScript-Funktion wird der interne Fokus auf diesen Anker gesetzt, wenn die Aktualisierung erfolgt.
Die Ergebnisse von Test 2 sind unterschiedlich. Homepage Reader 3.02 liest den aktualisierten Text, hört aber nicht mit dem Vorlesen auf, wenn dieser Abschnitt zu Ende ist. Die Anker-Technik ist also dann geeignet, wenn die Änderungen auch am oder gegen Ende der Internetseite aufhören. In der Version 3.04 funktionierte diese Technik gar nicht mehr korrekt, denn der Screenreader bewegte sich immer zurück an den Anfang der Seite. Bei Hal 6.5 / Connect Outloud 2.0 wird eine Seitenaktualisierung angesagt, der geänderte Abschnitt wird übersprungen. Jaws 5 / 6.2 zeigt ein sehr uneindeutiges Verhalten: Manchmal wird der Link erneut gelesen, manchmal passiert nichts oder es tritt das selbe Verhalten wie bei Hal auf. Windows Eyes 5 liest den geänderten Abschnitt. Allerdings funktioniert es nur, wenn man die Seite bereits besucht hat und an der Stelle des Links ist.
Allen Screen-Readern gemeinsam war nach diesem Test, dass sie ab dem Abschnitt der aktualisierten Antwort weiterlesen. Edwards vermutet, dass es an HTML liegen könnte. Deshalb hat er den Code umgeändert. Neben dem Namen und einer id bekommt der Link als href das Nummernzeichen mit übergeben, das eigentlich auf einen Anker im selben oder in einem anderen Dokument verweist.
Ergebnisse Test 2 mit "leerem" Anker-Attribut bei Verweisen: Homepage Reader 3.02 / 3.04 zeigen keine Veränderung. Connect Outloud verhält sich nun wie im ursprünglichen zweiten Test. Hal und Jaws verhalten sich nun korrekt, wobei Jaws noch mal die Hauptüberschrift der Seite neu vorliest.
Der Link vor dem dynamischen Absatz wird also dann korrekt fokussiert, wenn er als Attribut ein href='#' enthält. Dieses Attribut bedeutet eigentlich: Verweise auf dich selbst, also ist dieselbe Datei gemeint.
Test 3: Statt den internen Fokus mit "document.location = #ankername" zu setzen, wird die JavaScript - Funktion "focus()" auf den Absatz mit dem aktualisierten Text angewendet. Diese Funktion wird auch gerne benutzt, um den Fokus auf Seiten mit Formularen sofort nach dem Laden direkt auf das erste Formularelement zu setzen.
Ergebnisse Test 3: Diese Technik versagt in allen Screenreadern außer Jaws 5 und Connect Outloud 2.0. Bei Windows Eyes 5 gibt es keine Veränderung.
Test 4: Der aktualisierte Text wird mit Hilfe eines Dialog-Fensters durch die JavaScript - Funktion "alert()" ausgegeben.
Ergebnis Test 4: Entgegen aller Erwartungen ist diese "brutale" Variante nicht die sicherste. Windows Eyes meldet das Dialogfenster nur manchmal und liest den Inhalt des Dialogfensters gar nicht vor.
Test 5: Ein Textfeld in einem Formular wird nach Absenden geändert. Mithilfe der "focus()" - Methode wird das Textfeld fokussiert.
Ergebnis Test 5: Jaws 6.2, Hal 6.5 und Homepage Reader 3.02 versagen hier. Jaws liest den Link erneut vor. Jaws 5.0 und Connect Outloud sagen das Element an, aber erst, dass es sich um ein Textfeld zum Editieren handelt und erst danach wird der geänderte Wert gemeldet. Windows Eyes 5 liest alle Inhalte nach dem geänderten Element vor, aber nicht das Element selbst (vergleiche Test 3).
Test 6: Wie Test 5, aber hier wird mit JavaScript der Text des geänderten Formular-Textfeldes automatisch komplett markiert.
Ergebnis Test 6: Exakt wie bei Test 5 mit der "focus()" - Methode.
Test 7: Die Beschriftung einer Formularschaltfläche wird geändert und mit "focus()" nach der Änderung angewählt.
Ergebnis Test 7: Es ergeben sich die selben Verhaltensweisen wie bei Tests 5 und 6, nur dass Jaws 5 und Connect Outloud 2 die neue Beschriftung vorlesen und dann die Schaltfläche als solche ansagen.
Fazit: Es scheint also keinen einzigen vernünftigen Weg zu geben, um Screenreadern eine eindeutige Ansage der Aktualisierung von Inhalten wie in den beschriebenen Tests beizubringen. Edwards fragt nun zynisch: "Sollte dieses Resultat davon abhalten, weiter Webanwendungen mit Ajax zu entwickeln?". Beantwortet man die Frage mit Ja, dann gibt es laut Edwards nichts in Ajax-Anwendungen, was man nicht auch mit den bisherigen POST oder GET - Request - Verfahren erreichen könnte (Gemeint ist der Einsatz von PHP, ASP oder JSP).
Edwards gibt dann noch einige Denkanstöße und Anregungen, was künftig verbessert und geändert werden müsste.
Abschließend fasst er jedoch zusammen, dass momentan Ajax als nicht zugänglich eingestuft werden müsse, da es keine allgemeingültigen Techniken gibt, um Inhaltsänderungen zuverlässig in Screenreadern ansagen zu lassen.
Edwards betont aber auch den Test-Charakter seiner Versuche und will seine Schlussfolgerung nicht überbewertet wissen. Man solle ruhig selbst experimentieren und versuchen, Mittel und Wege zu finden, um Ajax-Anwendungen zugänglich zu machen.
