03.12.2010
Beim zweiten Workshop des 95plus-Kreises trafen sich Agenturen und BIK-Prüfer zum Erfahrungsaustausch über das gemeinsame Testen, aber auch, um Änderungen am BITV-Test wie die neue ausgegliederte PDF-Prüfung und offene Fragen der Testentwicklung zu besprechen (Stichwort: Prüfung von JavaScript).
Der neue BITV-Test ist im Rohbau fertig. Zu den neuen und geänderten Prüfschritten gab es im Workshop keine unmittelbaren Fragen oder Kommentare.
Es ist mit einer weiteren Verzögerung der BITV 2.0 zu rechnen. Deshalb plant BIK einen WCAG-2-Test (angestrebte Fertigstellung: Ende Februar 2011), um dem vielfältig geäußerten Bedarf nach einer Überprüfung von Angebote auf der Basis des BITV 2 Entwurfs bzw. den WCAG 2.0 entgegen zu kommen.
Einige Fragen betrafen die Rolle der BIK Selbstbewertung und die unterschiedliche Bewertung (dreistufig in der Selbstbewertung gegenüber fünfstufig im vollen Test).
Wenn eine Agentur die Selbstbewertung als Einreichung für die Liste 95plus nutzt, wird das Ergebnis strenger als bei dem vollen Test mit seiner begrenzten Seitenauswahl nachgeprüft: Die von der einreichenden Agentur gemachten Bewertungen müssen ja auf alle Seiten des Angebots zutreffen.
Mehrere Agentur-Teilnehmer zeigten sich irritiert über die abweichende Bewertungssystem bei der Selbstbewertung. BIK erläuterte die Ursachen und brachte das Argument, dass der höhere Detaillierungsgrad bei einer Bewertung, die die ganze Site betrifft, nicht so sinnvoll schien. Allerdings nutzen Agenturen die Selbstbewertung durchaus auch für einzelne Seiten: indem pro geprüfte Seite einen Test angelegt wird.
Die Agentur-Teilnehmer sprachen übereinstimmend dafür aus, die Bewertung an den BITV-Test anzugleichen (also fünfstufige Skala auch bei der Selbstbewertung). Für die Agenturen ist das sinnvoll, weil so die Selbstbewertung als relativ aussagekräftiger da ähnlicher Vortest vor dem eigentlichen BITV-Test eingesetzt werden kann. Die Möglichkeit späterer Überraschungen wird verringert.
BIK nimmt diese Anregung auf und wird die neue Selbstbewertung im WCAG-2-Test und dem späteren BITV-2-Test fünfstufig umsetzen.
Die (erfolgreich nachgeprüfte) Selbstbewertung gilt weiterhin erstmalig als Eintrittskarte in die 95plus-Liste. Als Werkzeug für weitere Einreichungen der Agenturen, die schon drin sind, soll die Selbstbewertung nicht mehr genutzt werden. Bei Prüfung großer Sites ist der Selbsttest (alles überprüfen) nicht mehr machbar, die Nachprüfung zu aufwändig.
Durch die Zusammenführung der Agenturliste 95plus und der Liste 90plus ergibt sich die Möglichkeit für Agenturen, auch 90plus-Angebote als aktuelle Referenzen zu verwenden (die neue Liste wird in Kürze fertiggestellt).
Für Agenturen, die schon länger keinen aktuellen Eintrag hatten, gibt es eine Archivlösung mit älteren Referenzen. Dies verhindert, dass etwa bei alphabetischer Sortierung Agenturen ohne aktuelle Referenzen, die zufällig weit vorn sind im Alphabet, vor Agenturen mit frischen Referenzen auftauchen.
Über den Sinn, mit IE7 zu prüfen, wurde länger gesprochen. Der Marktanteil ist nicht hoch, IE7 wurde schnell von IE8 abgelöst. Es gibt Rendering-Fehler, die man auch als IE7-Browserbugs betrachten kann und die zur Zeit zu Punktabzügen bei Skalierbarkeit führen können.
Im neuen WCAG-2-Test (voraussichtlich Ende Februar verfügbar) wird IE 8 statt wie bisher IE7 in der Werkzeugliste vorgeschrieben. Firebug wird zur Prüfung generierter Inhalte in die Werkzeugliste aufgenommen. Wie der Einsatz genau beschrieben wird, ist noch unklar (etwa im DOM-Scripting-Prüfschritt).
BIK stellte den Ansatz des PDF-Prüfverfahrens vor, das zur Zeit entwickelt wird.
Die PDF-Prüfung (bisher enthalten in Prüfschritt 11.1.1) wird ausgegliedert und als zweite Säule des BITV-Tests etabliert. Auch hier werden maximal 100 Punkte vergeben, wobei viele Prüfschritte nicht anwendbar sind (für diese werden die Punkte also automatisch vergeben). Manche Prüfschritte sind auf PDF nicht anwendbar, einfach weil sie nicht prüfbar sind (etwa versteckte Hilfstexte bei Formularen, siehe unten).
Prüfschritte, die vorläufig nicht gebraucht werden, aber relevant werden könnten, wie etwa die Prüfung von Medienalternativen für in PDFs eingebundene Videos, können dann bei Bedarf ergänzt bzw. "aktiviert" werden.
Hierzu wurde von Agenturseite bemerkt, das schon bald PDFs mit Video-Elementen auftauchen werden.
Durch die Auslagerung ist die Prüfung differenzierer. Auch bei der PDF-Prüfung gibt es eine Seitenauswahl nach Wichtigkeit der PDFs. Kurze PDFs werden ganz geprüft (etwa < 20 Seiten), bei langen PDFs gibt es auch eine Seitenauswahl innerhalb des PDF-Dokuments.
Es muss in der Darstellung von Prüfungen deutlich werden, ob PDFs ausgeklammert wurden. Wenn Web-Angebote verschiedene Typen von PDFs enthalten (etwa zum Einen Broschüren, und zum Anderen Formulare) muss deutlich gemacht werden, dass nur die Broschüren, nicht aber die Formulare geprüft wurden.
Eine Validitätsprüfung von PDF scheint BIK nicht sinnvoll, da nicht sehr relevant für die Barrierefreiheit und schwer umsetzbar. Es ist schwer zu durchschauen, wie auf Basis von etwa MS Word erstellte PDFs valide zu machen wären.
Auch PDFs mit Formularen sind grundsätzlich prüfbar. Agentur-Teilnehmer meinten, technische Kriterien sollten hier in jedem Fall geprüft werden. Enthaltene Formulare müssen dann ausgeklammert werden, und die Abgrenzung muss klar definiert werden.
Die Schwierigkeit entsteht bei PDF-Formularen, die zum Teil versteckte Label und Hilfstexte enthalten, die nur bei Screenreader-Nutzung ausgegeben werden, aber keine nicht ohne Weiteres sichtbar und damit prüfbar gemacht werden können (etwa als Ausgabe in Acrobat Pro). Solche Formulare sind komplex, weil im Erstellungswerkzeug Interaktionen definiert werden, die in der Vorlesen-Funktion nicht interaktiv erprobt werden können.
Die Frage in die Runde erbrachte keine klaren Hinweise auf Werkzeuge, die solche versteckten Texte anzeigen. Zu prüfen ist in dieser Hinsicht der PDF Accessibility Checker (PAC) von access-for-all (CH).
Bei der Prüfung von PDFs kann zuerst geguckt werden, ob PDFs getaggt wurden. Nicht getaggt bedeutet nicht zugänglich, die Prüfung wird abgebrochen wie bisher. Wie dies in der Bewertung reflektiert wird, ist noch nicht klar.
Die "zweite Säule" PDF-Prüfung hat auch Auswirkungen für die Darstellung der Prüfergebnisse eines Angebots. Zukünftig muss klar sein, auch im Prüfsiegel, worauf sich das Ergebnis bezieht. Ergebnisse für HTML- und PDF-Prüfung werden getrennt dargestellt werden, das Prüfsiegel soll einen Zeitstempel enthalten. BIK ist zur Zeit dabei, einen Vorschlag für ein angepasstes Prüfsiegel zu entwickeln.
Von Agentur-Teilnehmern wurde vorgeschlagen, im Prüfergebnis klar zu machen, dass Formularaspekte extern in Praxistests geprüft werden sollten. Es kam auch die Frage auf, ob die Prüfung von Formularen in PDFs deren Verwendung nicht sogar fördert. Das wäre das falsche Signal, ein HTML-Formular ist allemal zugänglicher.
Es kam auch der Vorschlag, entwickelte Techniken bzw. deren Prüfung als WCAG 2.0 Techniques einzureichen, da hier erst wenig Konkretes existiert.
Viele der in der Agenda vorgeschlagenen Sachthemen für die Diskussion waren schon in dem Erfahrungsaustausch über die gemeinsamen Prüfungen zur Sprache gekommen. Eigentlich wurde dann nur über den DOM-Scripting-Prüfschritt noch ausführlich gesprochen.
Viele Fragen des zugänglichen Einsatzes von JavaScript werden schon implizit etwa im Tastaturprüfschritt geprüft: Bei Einfügungen (etwa Lightboxen über AJAX) Prüfung, ob die Einfügung im Quelltext nach der auslösenden Stelle gemacht wird und damit automatisch in die Tabreihenfolge aufgenommen wird. Und generell die Tastatur-Erreichbarkeit und -Schließbarkeit von Layers / Lightboxen, und die Wiederherstellung der alten Fokusposition.
Die Prüfung der Trennung von JavaScript und HTML (keine inline Scripts) ist ansatzweise aus der Prüfung am Ende der WCAG 2.0- Technik SCR21 ableitbar (Vermeidung von document.write(), innerHTML, outerHTML, innerText und outerText) und mit einem Bookmarklet umsetzbar. Ob dies allerdings sinnvoll ist, blieb unklar, denn die Barrierefreiheit lässt sich auch ohne DOM-Scripting sicherstellen.
Schwierig ist die Prüfung, ob der Fokus etwa bei dynamisch eingeblendeten Inhalten wirksam versetzt wird: selbst wenn dies als Fokusverschiebung an der verschobenen blinkenden Einfüge-Marke beobachtbar ist, ist damit noch nicht sichergestellt, dass auch gleichzeitig der interne Screenreader-Buffer aktualisiert wird. Dieser Buffer-Refresh kann über einen setTimeout()-Script erreicht werden. Dass man so etwas einen Workaround für einen Screenreader-Bug - prüfen sollte, ist eher abwegig. Unklar bleibt bislang, wie eine wirksam geskriptete Fokusverschiebung im Prüfschritt geprüft werden soll.
Agentur-Teilnehmer betonten die Wichtigkeit der Funktionsprüfung des eingesetzten JavaScripts und den Bezug auf die WAI Aria Best Practices etwa bei der Tab-Reihenfolge (Pfeiltasten-Navigation). Dazu wurde von BIK kritisch bemerkt, dass es hierfür bislang keine Konventionen gibt: Tabben ist etabliert für die Navigation von horizontalen Menüs, warum sollen dann anderswo die Pfeiltasten genommen werden? Das ist nicht leicht nachzuvollziehen. Es haben sich hier noch keine wirklichen Konventionen etabliert.
Auch ist für ältere Screenreader die Verständlichkeit nicht gegeben. Um Konflikte zwischen inhärenter und über WAI-ARIA zugewiesener Semantik zu vermeiden, kommen etwa bei Tab Panels unsemantische Elemente zum Einsatz. Ältere Screenreader begreifen dann nicht, dass es sich um Pfeiltasten-navigierbare Tabs handelt, die Rolle wird nicht mitgeteilt.
Die dynamische Verwendung von Hilfetexten bei der Fokussierung auf Formularfelder ist fragwürdig: Texte werden über WAI-ARIA live regions vielleicht gerade dann vorgelesen, wenn ein Nutzer das Feld ausfüllt und das akustische Feedback braucht.
Was den Einsatz von Live Regions angeht, kann man im Prüfschritt vielleicht beschreiben, dass bei inhaltlichen Änderungen die Zugänglichkeit der Änderung geprüft wird (auch über die Live Regions Toolbar - hier sollte WAI ARIA alleine aber bislang nicht ausreichen, wegen mangelndem accessibility support). Wege zur Umsetzung wären entweder Änderungen unterhalb der Fokusposition im Prozess oder, falls Inhalte (etwa ein Preis) oberhalb der Position aktualisiert werden, die redundante Wiederholung auf der nächsten Seite oder zusätzlich unterhalb der Fokusposition.
Hier muss nach Praxisbeispielen Ausschau gehalten werden, um eine sinnvolle Prüf- und Bewertungspraxis solcher Fälle zu etablieren.
Von Agenturseite wurde über neue potentielle Probleme der Tastaturnutzbarkeit und der semantischen Struktur bei HTML5 berichtet. Ein Mobilhersteller möchte etwa eine grafische Oberfläche plus Script über das neue canvas-Element realisieren.
Außerdem wurde auch die Umsetzung komplexer Techniken wie Drag-and-Drop (Email-verschieben) angesprochen. Das kam bisher nicht vor: wenn es auftaucht, wird in den üblichen Prüfschritten geprüft (und wahrscheinlich bei Nutzung mit eigenen Farben, Ohne CSS, usw. Punktabzüge erzeugen).
BIK wird sich vorrangig auf die JavaScript-Prüfungen konzentrieren, die in den bestehenden Prüfschritten schon impliziert sind und die leicht handhabbar sind.
Bei dem DOM-Scripting Prüfschritt wird BIK das versammeln, was nicht schon in den anderen Prüfschritten geprüft wird. Hinweise von den Agenturen an BIK wären hier sehr wertvoll und willkommen.
Angestrebt wird eine Sammlung von skriptbasieren Änderungen, die OK (barrierefrei) sind und solchen, die Schwierigkeiten verursachen.
Von Agenturseite kam auch der Hinweis, dass man von Entwicklern den Nachweis verlangen sollte, dass die von ihnen eingesetzte Skript-Umsetzung accessibility-supported ist. Ein Abgleich mit einer Sammlung akzeptierter JavaScript-Techniken ist aber schwierig (verschiedene Varianten in verschiedenen JavaScript UI-Libraries) und ist im Prüfkontext wohl eher nicht praktikabel.
Was den Einsatz von AI-ARIA angeht, stimmten die Teilnehmer der Agenturen größtenteils der von BIK favorisierten Position zu, dass man sich noch nicht auf die Unterstützung von WAI-ARIA verlassen sollte, um Inhalte für ScreenreaderNutzer zugänglich zu machen.
Nach dem Erfahrungsaustausch über die gelaufenen Tandemprüfungen zwischen BIK und den Agenturen sollten nun weitere gemeinsame Prüfungen folgen. Im März ist dann ein weiterer Workshop zum Ende der Erprobungsphase des 95plus-Kreises geplant. Hier wird BIK dann einen Vorschlag für die geplanten BIK-Prüfstellen bei den Agenturen vorlegen, in dem die Anforderungen und Abläufe genauer definiert sind. (Zusätzlicher Hinweis: Solche Prüfstellen kann es grundsätzlich nicht nur bei Agenturen, sondern bei ebenso bei anderen Institutionen, etwa den Verbänden, geben. Die festzulegenden Anforderungen betreffen etwa die Mindestanzahl gemeinsam erfolgreich abgeschlossener Prüfungen, Regeln für Außendarstellung des Prüfangebots der Prüfstelle, die Rollenverteilung (BIK hat als Qualitätssicherung das letzte Wort), und finanzielle Regelungen bei Angeboten, die von BIK bzw. von der Prüfstelle akquiriert wurden.)
