BITV Reloaded – Anforderung 6

Bedingung 6.3: Auch ohne Skripte nutzbar (Prio. 1)

Es muss sichergestellt sein, dass mittels Markup-Sprachen geschaffene Dokumente verwendbar sind, wenn Scripts, Applets oder andere programmierte Objekte deaktiviert sind.«

Was heißt das?

Auch im aktuellsten Browser kann unter Umständen JavaScript abgeschaltet sein, sei es, weil eine Sicherheitsrichtlinie in einem Firmennetzwerk dies verlangt, oder auch einfach nur um lästige Werbeeinblendungen zu verhindern. Im Kontext dieser Richtlinie spielen solche Anwendungsfälle keine Rolle, da es hier ausnahmslos um den Zugang für Menschen mit Behinderung geht.

Für moderne Hilfsmittel wie halbwegs aktuelle Screenreader sind clientseitige Skripte meistens unproblematisch, sofern die Aspekte der barrierefreien Webentwicklung berücksichtigt wurden. Probleme treten hier eher aufgrund der ungewohnten Dynamik von Web-basierten Anwendungen auf. Diese Hürden lassen sich nicht durch Abschalten von JavaScript beseitigen, hierfür sind andere Bedingungen der BITV relevant, die in den Bereich der Gebrauchstauglichkeit (Usability) speziell für Menschen mit Behinderung gehen.

Trotzdem sollte beim Einsatz von Java, JavaScript und Flash darauf geachtet werden, dass diese nur optional sind, sofern Sinn und Zweck der Anwendung diese Einschränkung zulassen. Das im Fall von JavaScript für statische Alternativen vorgesehene NOSCRIPT-Element kann hier nur einen unzureichenden Ersatz bieten. Zum einen sind die Inhalte von NOSCRIPT selbst nicht änderbar, ohne dass man eine Seite neu lädt (was wiederum den Einsatz anderweitig verbotener Mittel voraussetzen würde). Zum anderen kann man in noscript> zwar einen Verweis auf eine statische Alternative ohne Skript-Funktionalitäten setzen — aber spätestens auf dieser Seite stellt sich dann das Problem, wie man adäquate statische Äquivalente für Inhalte bereitstellt, die ohne ein Mindestmaß an Dynamik prinzipiell nicht funktionieren können.

Einen Ausweg aus diesem Dilemma bietet die Bedingung 8.1, mit der die direkte Zugänglichkeit von Scripts, Applets oder anderen programmierte Objekten ermöglicht wird. Gerade aus Sicht von behinderten Menschen und damit im Sinne des barrierefreien Webdesigns ist letztere Variante sicher die attraktivere, weil sie keine Sonderwege festschreibt, sondern die integrierte Nutzung ermöglicht.

Wie geht es trotzdem?

Einen brauchbaren Ansatz, um diese beiden Bedingungen zu vereinen, bieten die Prinzipien der »Graceful Degradation« und des »Progressive Enhancement« bzw. »Hijax«. Die Begriffe beschreiben die schrittweise Verbesserung einer zunächst statischen Web-Anwendung durch Ajax.

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.

Stark verkürzt auf den Punkt gebracht:

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

Alles Wissenswerte zu diesem Thema finden sie in unserem Podcast vom 14. Juni 2006 zum Thema »Barrierefreiheit, Ajax und Web2.0«.

Positive Beispiele:

Ein hervorragend gemachtes Beispiel für diese Technik finden Sie bei der Amazon.com Diamond Search:

• Mit aktiviertem JavaScript erhalten Sie eine interaktive Anwendung inklusive der in HTML bisher nicht vorgesehenen und somit ohne JavaScript unmöglichen Schiebereglern (engl.: Slider). Bereits während der Bedienung der Schieberegler schickt der Server eine Liste der zu erwartenden Treffer auf Basis der ausgewählten Kriterien.
• Ohne JavaScript erhält man ein herkömmliches Formular, das zwar prinzipiell die gleiche Suche ermöglicht, jedoch mit den üblichen in HTML vorgesehenen einfacheren Formularelementen, dies jedoch ohne den zusätzlichen Komfort der AJAX-Version.

Universeller Fensteröffner

Damit Sie auch bei dieser Bedingung etwas zum Mitnehmen haben hier ein Programmierbeispiel für eine Funktion, die bei eingeschaltetem JavaScript Links in neuen Fenstern öffnet, deren Aussehen und Position Sie frei bestimmen können. Das Skript benötigt keine Inline-Event-Handler (onclick o.ä.) im HTML, sondern ›beobachtet‹ von aussen die Interaktionen mit den Links (a mit Attribut href) und fängt Klicks auf Elemente mit ganz bestimmten Attribut-Wert-Paaren ab. Ohne JavaScript bleiben die Links das, was sie schon immer waren: ganz normale Links.

Der Einfachheit halber haben wir das Skript in die folgende Datei eingebettet: fensteroeffner.html. Im Regelbetrieb sollten Sie Skripte wie diesen in externe .js-Dateien auslagern.

Applet und Object

Nicht nur für Skripte muss die direkte Zugänglichkeit sichergestellt werden oder zumindest für Alternativen gesorgt werden, sondern auch für »Applets oder andere programmierte Objekte«. Der Vorteil des (allerdings veralteten) APPLET und des moderneren OBJECT-Elementes sind die eingebauten Alternativen für den Fall, dass ihre Inhalte nicht unterstützt werden oder aus anderen Gründen nicht augeführt werden können. applet> kann mit einem alt-Attribut versehen werden und kann zwischen Start- und End-Tag auch ganz normales HTML enthalten, das (zumindest in der Theorie) angezeigt wird, wenn z. B. Java deaktiviert ist.

OBJECT bietet darüber hinaus den Vorteil, dass man mehrere Elemente mit unterscheidlichen Inhalten ineinander verschachteln kann. Die Browser versuchen zunächst das äussere object> auszuführen, schlägt dies fehl, wird das nächste innere object> genommen usw.:

1. <object classid="java.class" width="300" height="200">
2. <object data="film.mp4" type="video/mpeg">
3. <object data="bild.png" type="image/png">
4. <object data="bild.gif" type="image/gif">
5. Text als letzter Notanker
6. </object>
7. </object>
8. </object>
9. </object>

Negative Beispiele:

Bei aller Begeisterung für die Möglichkeiten Web-basierter dynamischer Anwendungen gilt es, einige grundlegende Dinge zu beachten:

• Viele Seiten im Netz benutzen Menüs, die beim Überfahren mit der Maus ein Untermenü aufklappen. Um dies zu erreichen, ist normalerweise ein buntes Gemisch aus HTML, JavaScript und CSS nötig. Wenn nun JavaScript im Zielbrowser deaktiviert ist, klappt nichts auf und dem Benutzer bleiben wesentliche Teile der Navigation verborgen. Das heißt aber nicht, dass Sie auf diese Ausklappmenüs verzichten müssen, oftmals sind diese die bessere Lösung, um komplexe Hierarchien abzubilden. Seit geraumer Zeit gibt es im Netz gut dokumentierte Lösungen, die auch mit abgeschaltetem JavaScript funktionieren oder gänzlich ohne auskommen und zudem mit der Taststur bedienbar sind.
• Unbedingt vermeiden sollten Sie Methoden, die statische Inhalte per JavaScript in Ihre Seiten schreiben. Ähnlich wie bei generiertem Content per CSS (Bedingung 6.1) haben Sie keine Kontrolle darüber, ob der Nutzer diese Inhalte tatsächlich wahrnehmen kann.
• Vermeiden sollten Sie Links, deren Wert keine gültige Webadresse (URL) ist, sondern ein JavaScript-Schnipsel. Diese werden oft benutzt, um neue Fenster zu öffnen und zusätzliche Parameter für diese zu definieren.

Wie können Sie das testen?

Auch diese Bedingung kann relativ einfach in den gängigen Browsern getestet werden. In den Schnelleinstellungen von Opera geht dies noch am einfachsten: hier können Sie auch ohne Browser-Erweiterungen direkt über einen Menübefehl Java, JavaScript und Plug-Ins ausschalten. In anderen Browsern müssen Sie hierfür unter Umständen die Voreinstellungen ändern, oder Sie benutzen die hinlänglich bekannten Toolbars für Webentwickler, die es mittlerweile nicht mehr nur für Firefox, sondern auch für den Internet Explorer und Opera gibt.

Deaktivieren Sie in diesen alle optionalen Elemente (also Java, JavaScript und Plug-Ins) und testen Sie, ob noch alle Inhalte (nun jedoch in anderer Form) vorhanden, erreichbar und verständlich sind und ob es für alle ausführbarem Funktionen eine Fallback-Lösung gibt. Dies gilt insbesondere für die Navigation und andere Links sowie Formulare.