protofunc()

Start Using Accessible JavaScript

Tags: accessibility, ajax, deutsch, javascript

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:

Written May 1, 2008 by
protofunc
newer posts »