BITV Reloaded – Anforderung 8

Bedingung 8.1: Zugängliche Alternativen für programmierte Objekte (Prio. 1)

Programmierte Elemente (insbesondere Scripts und Applets) sind so zu gestalten, dass sie entweder direkt zugänglich oder kompatibel mit assistiven Technologien sind.«

Was heißt das?

In Anforderung 1 wurden ja bereits die alternativen Inhalte zu eingebetteten statischen Objekten diskutiert. Diese Anforderung kümmert sich nun um die Zugänglichkeit von nicht-statischen Inhalten, die üblicherweise per OBJECT oder EMBED in eine Seite eingebunden werden und ein zusätzliches Plug-In benötigen, um im Browser ausgeführt zu werden.

Nach dieser Anforderung müssen sämtliche Inhalte eines Web-Angebotes genauso zugänglich sein wie der Rest der Seite, gleichgültig welche Technologie eingesetzt wird. Folgerichtig gelten also für Flash- und Java-Anwendungen, aber auch AJAX- und JavaScript-basierte Web-Anwendungen die gleichen Kriterien für die Ausgabe und Bedienung mit assistiven Hilfsmitteln. Eingebettete oder verlinkte PDF-Dokumente können ebenfalls »Programmierte Elemente« sein, da auch in diesen zum Beispiel in Formularen Berechnungen angestellt werden oder andere Skripte ausgeführt werden können.

Nicht ganz so einfach ist die Abgrenzung bei multimedialen Inhalten, angefangen von reinen Flash-Videos über komplexere Präsentationen bis hin zu Angeboten mit echtem Anwendungscharakter. Auch ein einfaches Video bietet bereits eigene »eingebettete Benutzerschnittstellen« im Sinne dieser Anforderung und kann im Ernstfall auch »programmierte Elemente« enthalten. Somit fällt dieses gegebenenfalls auch unter die Bedingung 8.1 und ist entsprechend zu testen.

Wie können Sie das testen?

Im Prinzip handelt es sich um eine sehr allgemein gehaltene Bedingung, die lediglich den Rahmen für die Zugänglichkeit bestimmter Web-Inhalte absteckt. Was im Detail zu beachten und zu testen ist, wird in einer Vielzahl anderer Anforderungen und Bedingungen der BITV festgehalten. Für eingebettete Objekte und programmierte Elemente gelten die bekannten Meßkriterien zu (Text-)Alternativen, Skalierbarkeit, Farben und geräteunabhängiger Bedienung, zu Bewegungen und automatischen Aktualisierungen sowie zu Flackern bzw. Blinken und vieles mehr.

Die hier ausdrücklich erwähnten assistiven Werkzeuge, die z. B. von blinden oder sehbehinderten Menschen, motorisch behinderten Menschen oder Menschen mit Lernbehinderung benutzt werden, sind sehr vielfältig. Daher können Sie ohne Tests mit echten Benutzern nicht davon ausgehen, dass Ihr Web-Angebot mit diesen Hilfsmitteln auch tatsächlich bedienbar ist.

Aber auch bereits in der Entwicklung von Web-basierten Anwendungen können Sie eine ganze Reihe Tests durchführen um die Erfüllung dieser Bedingung zu überprüfen, ohne sich gleich in die zugegebenermaßen sehr komplexe Bedienung eines Screenreaders einarbeiten zu müssen.

In begrenztem Maße geht dies bereits mit einem sogenannten DOM-Inspector, der für Browser wie Firefox, Internet Explorer, Safari oder Opera nachrüstbar ist. Besonders wenn Sie Client-seitige Skripte zur Manipulation der Inhalte oder Funktionen einsetzen geben diese Werkzeuge einen guten Überblick, in welchem Zustand sich ihr Angebot nach einer Interaktion durch den Benutzer befindet, welche geänderten Elemente verfügbar sind, welche Attribute diese besitzen usw.

Da die weitaus meisten assistiven Werkzeuge nach wie vor unter Windows laufen und dort auf den Internet Explorer aufsetzen beschränken wir uns hier auf Testwerkzeuge, mit denen Sie die Zugänglichkeit Ihrer programmierten Objekte auf dieser Plattform testen können. Diese Hilfsmittel werden vom Betriebssystem über die sogenannte Microsoft Active Accessibility-Schnittstelle (MSAA) mit Informationen über die vorgefundenen Inhalte, ihre Rollen und mögliche Zustände versorgt. (Andere Betriebssysteme bieten ähnliche Schnittstellen, auf die wir hier nicht eingehen. Entsprechende Dokumentationen finden Sie bei Interesse auf den Seiten von Apple, Sun und GNOME)

Ein Bestandteil der frei erhältlichen Active Accessibility Software Development Kit Tools von Microsoft ist das Werkzeug inspect32.exe. Mit dieser Anwendug lässt sich beobachten, welche zusätzlichen Accessibility-Informationen einer Anwendung über die MSAA-Schnittstelle nach ›aussen‹ durchgereicht werden.

Ein weiteres Werkzeug ist das mittlerweile als Open Source veröffentlichte MSAAVerify, mit dem Sie testen können, ob die Properties und Methoden ihrer Schnittstellen wie zum Beispiel Taststurkürzel den Richtlinien der MSAA entsprechen.