Eine häufigere Aufgabe ist es bei Ajax Requests den alten Content durch eine Animation zu verstecken, dann den Content auszutauschen und diesen dann durch eine weitere Animation anzuzeigen.

Hierbei stellt sich das Problem, daß die genaue Dauer der Ajax-Response unbekannt ist. Ist die Response deutlich kürzer als die Verstecken-Animation, kann der Inhalt nicht ausgetauscht werden, da der User dann während dieser Animation plötzlich bereits den neuen Content sieht.

Um dieses Problem zu lösen, eignet sich jQuery´s queue Methode sehr gut, welche bereits genutzt wird, um Animationen in eine Warteschlange zu stellen. Um diesen Animationsqueue zu nutzen, muß der Ajax-Callback sich zu diesem Queue hinzufügen. Wird die Animation noch ausgeführt, wird dessen Ende abgewartet ansonsten wird die Callback-Funktion sofort ausgeführt.

Eine kleine Funktion, die aus einer Callback-Funktion eine sich in die Effekt-Warteschlange “anstellende” Funktion macht, könnte wie folgt aussehen:

$.createQueueCallback = function(jElm, fn, type){
	type = type ||
		'fx';
	return function(){
		var that = this,
			args = arguments;

		jElm = $(jElm);
		jElm.queue(type, function(){
			fn.apply(that, args);
			jElm.dequeue(type);
		});
	};
};

Dieser Methode wird als 1. Parameter ein jQuery-DOM-Object, ein DOM-Objekt selbst oder ein CSS-Selektor, als 2. Parameter die Callback-Funktion und als 3. optionaler Parameter der Name der Warteschlange übergeben. Die Benutzung könnte so aussehen:

function requestContent(){
	var live = $('#live')
		.hide(500);

	$.ajax({
		url: 'htmlsnippet.txt',
		success: $.createQueueCallback(live, function(data){
			live
				.html(data)
				.show(200);
		}),
		error: function(){
			//immer errors handeln
		}
	});
	return false;
}

Folgend findet ihr eine Ajax-FX-Queue-Demo als Download.

Obwohl ich dem Artikel Stop using Ajax! von James Edwards (“Brothercake”) und dem „zur Seite springen” von Chris Heilmann inhaltlich nur zustimmen kann, hat mir der Artikel nicht gefallen. Neben einem kurzen Hinweis auf einen Lösungsweg für Übermorgen bzw. einen möglichen Workaround empfand ich ihn vor allem als de-konstruktiv. In vielerlei Hinsicht lenkt er auch vom eigentlich Hauptproblem für Javascripter und möglichen Lösungen ab. Zusammen mit dem Standard-Test in den vielen Barrierefreiheitschecklisten (Schalten Sie JavaSript im Browser aus und überprüfen Sie, ob die Seite immer noch funktioniert) sorgt er für ein vollkommen falsches Bild von den Barrierefreiheitsproblemen. Jede Zuwiderhandlung gegen diesen Checkpunkt wird in der Regel mit dem größtmöglichen Punktabzug bestraft. Dabei sagt dieser SEO-Test kaum etwas über die Zugänglichkeit von JavaScript aus.

Nicht AJAX, sondern JavaScript ist „unreif” für Screenreader

Seien wir mal ehrlich nicht AJAX selbst oder das „Nicht-Vorhandensein von JavaScript” ist aus Zugänglichkeitsgesichtspunkten „unreif”. JavaScript und vor allem seine Unterstützung in assistiven Technologien sind höchst problematisch und sehr schwer zusammen zu bringen. AJAX ist lediglich eine gewisse Verschärfung des eigentlichen Problems, da zwischen User-Aktion und Content-/Style-Änderung eine größere Verzögerung liegt. Nehmen wir zum Beispiel die DOMTabs. Diese bestehen nicht nur die meisten standardisierten Checkpunkte, sondern gehen sogar etwas darüber hinaus. Dies ist angesichts des Know-Hows des Entwicklers auch kein Wunder, aber wirklich barrierefrei arbeiten diese im Screenreader nicht.
Das, in den meisten aktuellen Screenreadern, wohl am häufigsten auftretende „Fehlverhalten” dürfte sein, dass der Screenreader-User auf einen Tab-Link klickt und erwartet, entweder auf eine neue Seite zu kommen bzw. zum ausgewählten Inhalt zu springen. In den meisten Fällen wird jedoch erstmal nichts passieren bzw. der Screenreader wird stur die nächsten Tab-Links vorlesen (Obwohl der Inhalt des ausgewählten Tabs korrekt in der Sprachausgabe upgedatet wurde.). Noch problematischer wird es, wenn man zum einfachen Wechsel ein bisschen Animation hinzufügt. Hier kann es passieren, dass der neue Inhalte nicht upgedatet wird oder der alte Inahlt ebenfalls noch im Screenreader-Buffer schlummert. Man bedenke, dass es sich bei diesem Tab-Switch um ein relativ einfaches Gebilde handelt. User Interfaces, die heutzutage mit JavaScript realisiert werden, sind nicht selten wesentlich komplizierter und die Berücksichtigung aller möglichen unterschiedlichen Barrieren erfordert viel Arbeit (Lösungsansätze für die eine Barriere können nicht selten eine neue befördern). Mit diesen JavaScript-Barrieren werden Entwickler bei ihrer Arbeit wesentlich häufiger konfrontiert als mit den AJAX-Barrieren.

JavaScript ist nicht tot zu kriegen

JavaScripter, denen Zugänglichkeit am Herzen liegt, müssen sich trotz der Probleme nicht in einer Höhle verkriechen. Dies hat vor allem drei Gründe:

1. Die Barrierefreiheit von reinen HTML & CSS Webseiten ist alles andere als „gottgegeben” und erfordert ebenfalls gewisses Know-How. Den Entwicklern, die sich etwas mit Zugänglichkeit beschäftigt haben, werden auch ein paar Beispiele einfallen, die zu dem Schluss führen könnten, dass Screenreader für bestimmtes, theoretisch vollkommen korrektes HTML noch nicht reif sind.
2. JavaScript ist die Sprache des Web. Trotz der oben genannten Probleme gehört JavaScript korrekt eingesetzt zur Lösung von Barrieren im Netz und nicht umgekehrt. (beispielhaft: Denn Sie tun es – CSS und Javascript
3. Die Zugänglichkeit von JavaScript wird derzeit deutlich vorangetrieben (dazu später mehr)

Ein Beispiel: Entgegen allen Behauptungen Flyout-Menüs wären böse, sollten wir uns darüber im klaren sein, dass in bestimmten Fällen ein Drop-Down-Menü oder ähnlich dynamisches Menü (Accessibility im Schatten der Usability und Neue Studie zur Usability unterschiedlicher Naviagtions-Methoden, die beste und gebrauchtauglichste Möglichkeit ist, eine Navigation zu erstellen. Jedoch gerade die falsche Ansicht, dass solche Menüs auch in veralteten Browsern ohne JavaScript funktionieren müssen, hat Entwickler dazu gebracht Techniken einzusetzen, die weder gebrauchstauglich sind noch ein Mindestmaß an Barrierefreiheit erfüllen. Diese CSS-Only-Lösungen können nicht richtig mit der Tastatur bedient werden, sie passen sich weder „Fehleingaben” des Users noch seiner Bildschirmgröße an und sie sind aufgrund fehlerhaft verschachtelter Links (gut versteckt in konditionellen Kommentaren) ein Showstopper für Screenreader. Für so etwas ist JavaScript schlichtweg die sauberste und barriereärmste Lösung.

WAI – ARIA – die Lösung für zugängliches JavaScript

In Sachen barrierefreies JavaScript tuen sich mit ARIA (Accessible Rich Internet Application) bereits heute und vor allem morgen nutzbare Möglichkeiten auf, seine „Widgets” erheblich barrierefreier zu gestalten. Hierbei bekommen typische “JavaScript-Widget-Elemente” (häufig Navigations- oder andere Eingabeelemente) zusätzliche semantische Attribute, welche ihre Rolle und Eigenschaften in maschinenlesbarer Form über den Browser dem Screenreader zugänglich machen können. Es existieren beispielsweise Rollen und zusätzliche Eigenschaften für Slider, Tabs, Grids, Menüs u.v.m.. Hierbei sind ebenfalls sog. Eigenschaften für live regions enthalten, welche die Zugänglichkeit von AJAX erhöhen, allerdings werden diese noch nicht ausreichend unterstützt. Die Unterstützung der zuvor genannten Widget-Rollen, die der W3C-Entwurf in der Praxis dagegen hat, ist trotz einiger Wandlungen des Entwurfs in jüngster Zeit sowie unterschiedlicher Implementierungen, atemberaubend. Mozilla hat bereits mit Firefox 1.5 eine inzwischen veraltete und mit Firefox 3 überarbeitete Implementierung begonnen (zu dem unterschiedlichen Support in den Browsern: http://learningtheworld.eu/2008/wai-aria-update/, http://blog.namics.com/2008/03/sxsw-2008.html ). Gleichzeitig besteht in folgenden Screenreadern/Vergrösserungssystemen grundlegender Support: Window Eyes 5.5+, Jaws 7.0+, ZoomText, Orca 2.20+. Die meisten deutschen Screenreader-Nutzer (angeblich 70%) nutzen Jaws. Häufig liegen sie ein bis zwei Versionsnummern zur aktuellen Version zurück. Derzeit ist die aktuellste Jaws-Version bei 9.0 angelangt. Gleichzeitig wird der Support in den Browsern erweitert: Opera 9.5 unterstützt ARIA ähnlich wie Firefox 3, Microsoft hat dem IE8 eine etwas abweichende Implementierung spendiert und Webkit (Safari) haben mit der Umsetzung begonnen. Dies ist für JavaScripter eine extrem erfreuliche Nachricht. Die neuesten Browser, von denen hier die Rede ist, können kostenlos genutzt werden bzw. werden zumindest kostenlos mitgeliefert. Bei den verhältnismäßig teuren Screenreader taugen bereits die älteren Modelle. Spätestens mit Erscheinen der nächsten Generation dieser Browser steht die Implementierung (formaler Standard hin oder her) fest und kann genutzt werden. Ich kann nur jedem Entwickler raten sich mit ARIA näher zu beschäftigen und neben den anderen Techniken für barrierefreies JavaScript bald bald einzusetzen .

weiterführendeLinks:

• WAI-ARIA Grundlagen
• Martin Kliehm / Barrierefreie Web 2.0 Anwendungen mit WAI ARIA
• W3C / WAI-ARIA Overview
• Firefox Accessibility Extension zur Überwachung von ARIA-Rollen, -Eigenschaften, Eigenschaftsänderung sowie einem Focus-Inspector
• ARIA: Accessible Rich Internet Applications von mozilla mit Beispielen
• ARIA Examples von Illinois Center for Information Technology Accessibility
• WAI-ARIA Live Regions

Nicht selten wünscht man sich, von seinen AJAX-Responses , dass sie in der gleichen Reihenfolge ankommen, in der die Anfragen abgesendet wurden bzw. zumindest in der selben Reihenfolge in der sie beim Server verarbeitet wurden (z.B.: Warenkorb). In anderen Fällen ist dagegen klar, dass eine Antwort auf eine Anfrage keinen Sinn mehr macht, da der User sich – während der Verarbeitung des XHR-Requests – entschieden hat einen anderen Beitrag auszuwählen.

Aufgrund der Asynchronität von AJAX, schwankender Latency sowie unterschiedlich langer Verarbeitung durch serverseitige Scripte kann dies jedoch nicht vorausgesetzt werden. Um derartige sowie ähnliche AJAX-Anfragen zu behandeln, habe ich ein kleines jQuery-Plugin zum managen von AJAX geschrieben.

Mit diesem Script lassen sich AJAX-Anfragen queuen, abbrechen blocken sowie AJAX-Antworten synchronisieren. Zum $.ajaxManager.