02.12.2008
Anders als die WCAG 1.0 akzeptieren die WCAG 2.0 nicht nur HTML und CSS, sondern grundsätzlich jede Technologie, die gewissen Mindestanforderungen in Sachen Zugänglichkeit entspricht - auch Javascript. Was heißt das für den BITV-Test? Wie werden Javascript-gesteuerte Inhalte in Zukunft geprüft und bewertet?
Auf dieser Seite:
Die WCAG 1.0 verlangen, dass Webseiten auch ohne Javascript vollständig nutzbar sein sollen. Damit darf Javascript zwar genutzt werden, allerdings nur als Zusatz.
Falls also wesentliche Inhalte unter Einsatz von Javascript angezeigt werden, muss ein gleichwertiges Alternativangebot ohne Javascript bereitgestellt werden. Wenn beispielsweise neue Fenster mit Javascript geöffnet werden, muss der Link auch dann funktionieren, wenn Javascript nicht aktiviert ist. Wenn Formulareingaben mit Javascript geprüft werden, bevor Sie zum Server geschickt werden, darf das nicht dazu führen, dass das Formular ohne Javascript überhaupt nicht genutzt werden kann.
Das heißt allerdings nicht, dass alles ganz genau so funktionieren muss wie mit Javascript. Es muss zum Beispiel nicht unbedingt auch ohne Javascript ein neues Fenster geöffnet werden, wichtig ist nur, dass der Link überhaupt aufrufbar ist, zumindest im selben Fenster. Entsprechend wird im BITV-Test in Prüfschritt 6.3.1 geprüft, ob alle wesentlichen Inhalte und Funktionen auch ohne Javascript verfügbar sind.
Darüber hinaus verlangen die WCAG 1.0 in verschiedenen Checkpunkten, dass skriptgesteuerte Webinhalte selbst zugänglich sind. Insbesondere darf der Einsatz von Javascript die Tastaturbedienbarkeit nicht beeinträchtigen.
Im BITV-Test wird daher in vielen Prüfschritten implizit die praktische Zugänglichkeit von Skripten mitgeprüft - und zwar dadurch, dass grundsätzlich mit aktiviertem Javascript getestet wird. So wird beispielsweise in Prüfschritt 9.2.1 (Ohne Maus nutzbar) mitgeprüft, ob Skripte die Tastaturbedienbarkeit beeinträchtigen. Ein Mangel im Skript führt genau so zum Punktabzug wie ein Mangel im HTML-Code. Die Tatsache, dass Tastaturnutzer theoretisch Javascript abschalten könnten, um die Tastaturbedienbarkeit wieder herzustellen, spielt bei der Bewertung keine Rolle.
Einer der wesentlichsten Unterschiede zwischen den WCAG 1.0 und 2.0 ist die Akzeptanz von Formaten und Techniken über HTML und CSS hinaus. Während sich die WCAG 1.0 vor allem auf HTML und CSS beziehen und für fast alle anderen Techniken im Grunde immer eine HTML-Alternative verlangen, akzeptieren die WCAG 2.0 grundsätzlich jede Technologie, die gewissen Mindestanforderungen in Sachen Zugänglichkeit entspricht. Zu diesen akzeptierten Technologien zählt aus Sicht der WCAG 2.0 auch Javascript.
Die grundsätzliche Akzeptanz von Javascript bedeutet in der Praxis eine wesentliche Neuerung: es muss nicht mehr zwangsläufig eine Fallback-Lösung bereitgestellt werden, wenn Inhalte mithilfe von Javascript angezeigt werden (siehe zum Beispiel im Vergleich zwischen den WCAG 1.0 und 2.0: "There is no longer a requirement that pages work without script or other programmatic objects").
Klarer als bisher ist in den WCAG 2.0, dass skriptgesteuerte Inhalte selbst zugänglich sein müssen. Auf keinen Fall kann Barrierefreiheit allein dadurch erreicht werden, dass es eine zugängliche Fallback-Lösung ohne Skripte gibt. Vielmehr gelten die Erfolgskriterien der WCAG 2.0 grundsätzlich genau so für Javascript wie für HTML. Entsprechend gibt es in der Liste der "Techniques for WCAG 2.0" nicht nur HTML-Techniken, sondern auch Javascript-Techniken, die beschreiben, wie die Zugänglichkeit praktisch erreicht werden soll.
Für Menschen mit Behinderungen ist die Akzeptanz von Javascript - und damit die Verpflichtung, Javascript-gesteuerte Inhalte zugänglich zu machen - sicher begrüßenswert. Denn mit Javascript kann die Nutzerfreundlichkeit wesentlich verbessert werden, zum Beispiel beim Ausfüllen von Formularen. Und Screenreader und andere assistive Technologien sind inzwischen durchaus in der Lage, mit Skripten umzugehen.
Allerdings hinkt die Entwicklung von barrierefreiem Javascript hinter HTML hinterher. Es gibt weniger eingebürgerte Verfahren, weniger kollektives Wissen, kaum vorbildliche komplexere Anwendungen. Zudem ist Javascript schwerer zu testen, insbesondere bei komplexen Javascript-gesteuerten Webangeboten kommt man aktuell wohl kaum um praktische Tests mit Screenreadern oder anderen Hilfsmitteln herum, wenn man die Zugänglichkeit beurteilen will.
Auch die bisher recht dürftige Sammlung von WCAG 2.0-Techniques für Javascript zeigt, wie viel Entwicklungsbedarf beim Thema barrierefreies Javascript noch besteht. Einige der ohnehin wenigen Techniques sind praxisfern und wenig nützlich, zum Beispiel die Technique SCR14, die verlangt, dass der Benutzer unwichtige Meldungen in Javascript-Alert-Boxen deaktivieren kann (aber warum sollte ein Anbieter überhaupt unwichtige Meldungen in Javascript-Alert-Boxen ausgeben?).
Andere Techniques entsprechen Anforderungen, die auch bisher schon im BITV-Test geprüft werden. Dazu gehört zum Beispiel die korrekte Nutzung von Event-Handlern oder das richtige Öffnen von neuen Fenstern via Javascript.
Eine Reihe von Techniques beschäftigt sich mit der dynamischen Anzeige von Inhalten mithilfe von Javascript. Hierbei kommt es vor allem auf die Linearisierbarkeit und Tastaturbedienbarkeit an, außerdem muss sichergestellt sein, dass Screenreader-Nutzer es mitbekommen, wenn sich irgendwo auf der Seite die Anzeige ändert. Diese Anforderungen sind sinnvoll, allerdings sind in diesem Bereich die Methoden zur Umsetzung und zur Prüfung noch lange nicht so ausgereift wie bei HTML.
Praktisch ändert sich zunächst nicht viel. Der BITV-Test prüft auch jetzt schon viele Prüfschritte mit aktiviertem Javascript - und damit letztlich auch die Zugänglichkeit der Skripte. Das betrifft insbesondere die Tastaturbedienbarkeit und die Linearisierbarkeit.
Bei der Prüfung wird in Zukunft stärker auf ein- und ausblendbare Inhalte geachtet werden müssen. Hier wird es vor allem darum gehen, ob Screenreader-Nutzer ausreichend über Änderungen der Ansicht informiert werden und ob die wechselnden Inhalte auch bei anderer Darstellung - zum Beispiel linearisiert - verständlich und gut navigierbar bleiben.
Der Prüfschritt "Ohne Javascript nutzbar" wird sicherlich nicht unverändert bestehen bleiben. Ob er abgeschwächt oder sogar ersatzlos gestrichen wird, hängt davon ab, wie schnell und wie klar sich Javascript als "accessibility supported" Technologie durchsetzt.
Insgesamt ist der Entwicklungsstand bei barrierefreien Javascript-Techniken noch lange nicht so weit, wie man es sich wünschen würde. Die Weiterentwicklung der Prüfanforderungen an Javascript-gesteuerte Inhalte ist daher sicher eine Aufgabe für die kommenden Jahre.
Denn einen Freibrief für die Verwendung von Javascript geben die WCAG 2 nicht. Wer Javascript einsetzen und barrierefrei sein will, muss sich auf aus Sicht der Barrierefreiheit bewährte und allgemein anerkannte Javascript-Techniken beschränken oder selbst intensiv in die Thematik einsteigen.
