26.02.2010
Auf dem ersten Workshop des 95plus-Kreises wurde die Überarbeitung des BITV-Tests vorgestellt und über den Umgang mit JavaScript im Prüfverfahren diskutiert.
Grundlage des Protokolls ist eine Tonaufzeichnung vom Nachmittag des Workshops am Vormittag wurde der BITV-Test vorgestellt und Fragen der Zusammenarbeit in der Erprobungsphase des 95plus-Kreises besprochen (siehe BIK-Meldung zum 95plus-Kreis). Die Ergebnisse wurden allerdings zusammengefasst und nach inhaltlichen Kriterien sortiert.
Die Überarbeitung des BITV-Tests gemäß der erwarteten BITV 2 läuft zur Zeit. Die bestehenden Prüfschritte werden nach der Nummerierung der WCAG 2.0 umsortiert. Einige Prüfschritte fallen wahrscheinlich weg, zum Beispiel:
Dann gibt es einige neue Prüfschritte, die durch die WCAG 2.0 hinzukommen, zum Beispiel:
Manche Prüfschritte werden auch ergänzt, besonders, um dem stärkeren Aufkommen dynamischer Web-Sites Rechnung zu tragen und generierten Content (Stichwort AJAX und WAI-ARIA) prüfbar zu machen.
Das Mapping der alten BITV-Test-Prüfschritte auf die WCAG 2.0 zeigt, dass sich die erprobte Gewichtung der Anforderungen nur schwer in einem Verfahren abbilden lässt, dass eine 1:1-Entsprechung zwischen den WCAG 2.0 success criteria und Prüfschritten anstrebt. Ein Versuch des Mappings zeigt zum Beispiel, dass allein dem success criterion 1.3.1 Info and Relationships insgesamt 7 BITV-Test Prüfschritte mit einem Gesamtpunktwert von 15 (also ca. 1/6 der gesamten Punkte) zufallen würden.
BIK muss durch praktische Vergleichstest der selben Website im alten und im neuen BITV-Test den Grad der Kontinuität des Prüfverfahrens überprüfen. Wenn in der neuen Fassung des Tests selten anzuwendende Prüfschritte wegfallen, in denen heute die zugeordneten Punkte bei Auswahl von "nicht anwendbar" quasi geschenkt werden, wird der Test schwerer. Dies wird zum Teil kompensiert durch das Hinzukommen neuer Prüfschritte, die häufig noch nicht anwendbar sind (z.B. Audiokontrolle, Fehlerbehandlung).
Der BITV-Test kann und wird wohl etwas schwerer werden, was auch in Ordnung ist, da der alte Test gut zu erfüllen ist.
Der Umgang mit Alternativ-Versionen muss noch geklärt werden. Versionen in Formaten wie Flash können auf absehbare Zeit nicht geprüft werden. Die Prüfung wird sich also auf die zugängliche Version konzentrieren und außerdem prüfen, ob diese gemäß den Zugangsregeln der Definition der conforming alternate version erreichbar ist. (Ob der Abschnitt Conformance mit der Anforderung 4. 4. Only Accessibility-Supported Ways of Using Technologies und die dazugehörige Definition im Glossar in die BITV 2 übernommen werden, ist uns zur Zeit nicht bekannt.)
Im neuen Verfahren wird die PDF-Prüfung ausgegliedert sein. Die PDF-Prüfung wird zur Zeit konzipiert und wird wohl nicht zeitgleich mit der neuen HTML-Prüfung fertig werden. Die Ergebnisse für die HTML- und die PDF-Prüfung werden getrennt verfügbar sein. Die Möglichkeit und Art der Zusammenführung der getrennten Ergebnisse von HTML- und PDF-Prüfung in eine Gesamtergebnis ist noch unklar.
Akzeptiert wird wie bisher der Ausschluss von alten PDFs aus dem Prüfgegenstand, wenn die Abgrenzung deutlich nachvollziehbar ist, nicht nur eine Alibifunktion hat, und ein klares Konzept für einen Workflow vorhanden ist, in dem Barrierefreiheit sichergestellt wird. Der Ausschluss von Altlasten muss außerdem bei jeder Nennung des Prüfergebnisses deutlich gemacht werden.
Wenn sehr viele PDFs angeboten werden, muss geprüft werden: stimmt die Aufteilung in barrierefreie / nichtbarrierefreie PDFs? Ist sichergestellt, dass die neueren PDFs barrierefrei sind? Wenn dies der Fall ist, werden in der Seitenauswahl PDF-Stichproben aus dem Bereich der als barrierefrei gekennzeichneten PDFs ausgewählt.
Die Seitenauswahl wird je nach Wichtigkeit von HTML und PDF beide Formate enthalten und in getrennten Prüfverfahren testen.
Eine wichtige Frage ist die Prüfbarkeit der Zugänglichkeit von JavaScript-Techniken, wenn der Test weiter ohne tiefere JavaScript-Kenntnisse angewandt werden soll. Eine grundsätzliche Haltung wäre, zu sagen: was im Quellcode steht, ist sekundär; was zählt, ist das Resultat, dass sich durch die Prüfungen z.B. der Tastaturnutzbarkeit ermitteln lässt.
Die Prüfung von versteckten Inhalten (ausklappbare Elemente, Lightboxes, usw) ist zu einem Gutteil schon über die bisherigen Prüfschritte abgedeckt (zum Beispiel die Prüfschritte zur Tastaturnutzbarkeit) da mit 'JavaScript an' geprüft wird, prüft der Test hier implizit auch die Zugänglichkeit der eingesetzten JavaScript-Techniken. Zum Teil müssen aber auch Prüfschrittbeschreibungen ergänzt werden.
Um dynamische Inhalte besser prüfen zu können, müssen die Prüfschritte um neue Werkzeuge und neue zusätzliche Anweisungen erweitert werden. BIK führt in naher Zukunft gemeinsam mit dem INCOBS-Projekt Screenreader-Tests durch, um zu prüfen, was bei dynamischen Inhalten und dem Einsatz von WAI ARIA bei den verbreiteten Hilfsmitteln wirklich 'ankommt'.
Die Unterscheidung von Kontextänderung und Content-Änderung etwa bei sich ausklappenden Formularen muss in den neuen Prüfschritt 3.2.1 "Keine Kontextänderung bei Eingabe und Fokussierung" (Entwurf) aufgenommen werden. Hier muss vielleicht auch an Beispielen erläutert werden, wie mit dynamischen Änderungen und Aktualisierungen von Seiteninhalten umgegangen werden sollte, damit diese für Nutzer von Hilfsmitteln sinnvoll und nachvollziehbar sind. Muss jede Änderung zuerst erst explizit von Usern bestätigt werden? Was kann akzeptiert werden?
Ein Problem ist der Einsatz von Scripting-Techniken, der nicht von den Angaben oder Beispielen im Prüfschritt abgedeckt ist. Sind Techniken bzw. Einsatzweisen, nicht dokumentiert sind und deshalb nicht ohne Praxistests prüfbar sind, schon deshalb fragwürdig? Wo werden sie negativ bewertet, wenn Prüfschritt 6.3.1 "Auch ohne Skripte nutzbar" wegfiele?
Es wurde darauf hingewiesen, dass der Einsatz von JavaScript-Libraries wie JQuery oft schon Barrierefreiheit mit sich bringt. Auch die Einbindung multimedialer Inhalte über Player wie JW FLV Player legt deren Tastaturnutzbarkeit nahe.
Nach Auffassung von BIK gehört zur Sicherstellung der Barrierefreiheit dazu, dass man die Barrierefreiheit belegen können muss. Also: Der Einsatz folgt einem anerkannten Konzept (z.B. "nur dynamische Änderungen auf der Seite unterhalb des augenblicklichen Fokus") oder die ist Technik bereits als barrierefrei dokumentiert, oder die Barrierefreiheit ist mit Praxistests belegt.
Die W3C ARIA Best Practices könnten hier hilfreich sein, da sie Widget-Typen auflisten und unter Bezug auf Konventionen des Betriebssystems diskutieren, welcher Einsatz sinnvoll ist.
Sinnvoll wäre eventuell eine Wissensbasis für Fälle neuer Scripting-Techniken unklar ist jedoch, ob und wie diese praktisch in den Prüfschritten nutzbar wäre.
Bei der Nutzung von Code-Inspektoren wie Firebug ist noch nicht klar, was bei verschiedenen Screenreadern ausgegeben wird.
Weiter erwähnt wurden zusätzliche Toolbars unter Firefox wie die Juicy Studio Accessibility Toolbar von Gez Lemon, mit der sich zum Beispiel WAI ARIA live regions prüfen lassen.
Es herrschte im Kreis (wie auch generell in der Accessibility Community) Konsens darüber, dass JavaScript-Techniken möglichst im Sinne des 'progressive enhancement' eingesetzt werden sollten. Dass Seiten also auch bei abgeschaltetem JavaScript funktionieren, wenn auch vielleicht nicht auf die gleiche Weise und mit demselben Komfort. Hierzu gehört auch die Regel, dass bei abgeschaltetem JavaScript Elemente, deren Funktion an der Verfügbarkeit von JavaScript hängt, versteckt sein sollten. (Beispiel: Ein JavaScript nutzender Print-Button wird bei abgeschaltetem JavaScript gar nicht erst angezeigt. Der Browser hält aber ohnehin die Print-Funktion vor, deshalb ist der Einsatz im Sinne des progressive enhancement.)
Es gibt jedoch auch Beispiele wie einen Flash Video-Player mit einem API, das über externe HTML-Buttons tastaturbedienbar ist: ein Fall, in dem JavaScript die praktische Zugänglichkeit verbessert und diese Funktionalität eben nur mit eingeschaltetem JavaScript verfügbar ist.
Grundsätzlich geben die WCAG 2.0 wenig Rückendeckung für die weitreichende Forderung des alten Prüfschritts 6.3.1 "Auch ohne Skripte nutzbar": dass alle Funktionen und Inhalte auch bei nicht aktivierten Javascript verfügbar sein müssen. Es gibt zwar eine Schnittmenge zwischen accessibility support und progressive enhancement (so etwa in den meisten bisher dokumentierten Scripting-Techniken der WCAG 2.0), aber keine Deckungsgleichheit. Eine Reihe von WAI Aria Techniken für custom controls etwa bieten accessibility support zumindest für Tastatur- und Screenreader-Nutzer, sind aber eben nicht im Sinne von progressive enhancement angelegt (zudem sind sie oft nicht nutzbar ohne CSS und mit eigenem Farbschema).
Laut WCAG 2.0 soll jede Version "so zugänglich wie möglich" sein. Die Frage ist, ob der Zustand bei "JavaScript aus" als eigene Version betrachtet werden kann. Dafür spricht, dass auf dynamischen Seiten zunehmend JavaScript-generierte Inhalte auftauchen, die ohne JavaScript gar nicht angezeigt werden. Deshalb werden beide Versionen immer unterschiedlicher, selbst wenn sie auf dem selben HTML-Quellcode aufsetzen. Konsequenterweise müsste jede Seite doppelt geprüft werden (JavaScript an, JavaScript aus). Das ist vom Aufwand her wohl nicht zu vertreten.
Es gab Uneinigkeit darüber, wie mit Fällen zu verfahren ist, in denen auch mit HTML umsetzbare Inhalte oder Funktionen mit JavaScript umgesetzt werden. Ein Beispiel ist der Submit-Button einer Suchfunktion, der durch einen JavaScript-Link ersetzt wird und bei abgeschaltetem JavaScript nicht mehr funktioniert.
Eine Position lässt sich zusammenfassen mit "JavaScript ist keine Behinderung", womit wohl gemeint ist, dass das Verbot der Aktivierung von JavaScript in einer Behörde vielleicht deren Mitarbeiter behindert, aber dass das nichts mit der Frage zu tun, ob die Nutzer der Inhalte behindert sind oder nicht. Für Insellösungen (etwa Intranet-Applikationen einer Behörde) müssten dann Lösungen geschaffen werden, die auf diese besondere Sicherheits-motivierte Anforderung ausgelegt sind. Generell können man aber davon ausgehen, dass man User, die JavaScript aus welchen Gründen auch immer abschalten, nicht berücksichtigt.
Eine Gegenposition betont, es ginge um "Seiten für alle", nicht nur um "Seiten (auch) für Menschen mit Behinderungen" und verweist darauf, dass bei Behörden im Einflussbereich des Bundesamts für Sicherheit in der Informationstechnik (BSI) immer noch aus Sicherheitserwägungen heraus JavaScript abgeschaltet werden muss. In dieser Sicht sollten Websites, wie bisher gefordert, generell auch ohne JavaScript nutzbar sein. Hierzu gab es im 95plus-Kreis verschiedene Meinungen.
Eine Position empfahl die fallweise Unterscheidung zwischen direkter Zugänglichkeit (JavaScript an) und indirekter (ohne JavaScript) und meinte, für "zentrale Funktionen" könne man letztere auch weiterhin fordern. Die Definition von "Basisfunktionen" oder "wichtigen Funktionen" ist aber problematisch: zumindest im Prüfkontext würden sich hier voraussichtlich häufig unterschiedliche Auffassungen zeigen, was als wichtig gelten muss.
Eine andere Position empfahl, die Forderung, das generell Inhalte auch ohne JavaScript zugänglich sein müssten, bis auf Weiteres beizubehalten mit Rücksicht auf die Nutzer, die JavaScript nicht anschalten wollen oder dürfen.
Es gibt zwar gute Argumente für ein umfassenderes, nicht auf Nutzer mit Behinderung eingeschränktes Verständnis von Behinderung. Es ist sicher in vielen Fällen einfacher, Unterstützung für die Einhaltung von Barrierefreiheitsanforderungen zu bekommen, wenn auch nichtbehinderte Nutzer davon profitieren. Aber auch die Gegenposition ist gut begründet. Die Zugänglichkeit für behinderte Nutzer soll kein Abfallprodukt sein, sondern sie ist das eigentliche Ziel.
Wenn die zukünftige BITV 2 den WCAG 2.0 darin folgt, dass das Funktionieren von Web-Angeboten bei abgeschaltetem Javascript nirgends gefordert wird, wird die Testentwicklung in der Neufassung des BITV-Tests voraussichtlich den Prüfschritt 6.3.1 "Auch ohne Skripte nutzbar" fallen lassen.
Die Prüfschrittbeschreibungen werden erweitert werden, um dynamische Inhalte besser zu erfassen. Dazu gehört die verstärkte Nutzung der elementweisen Prüfung, um bestimmte Skript-generierte Seitenzustände als Teil des Prüfgegenstands festzulegen. Außerdem wird die Testentwicklung prüfen, ob die Werkzeugliste um Toolbars ergänzt werden sollte, welche die Prüfung JavaScript-generierter Inhalte und Zustände zu erleichtern.
