search

BIK-BITV / BIK-Web-Test

Testverfahren zur Prüfung der Barrierefeiheit von Webanwendungen anhand der Kriterien der WCAG 2.1, EN 301 549 und BITV 2.0
70 stars 21 forks source link

12.2.4 Vom Support bereitgestellte Dokumentation - Geltung für Drittinhalte #198

Closed detlevhfischer closed 2 years ago

detlevhfischer commented 3 years ago

Im Zuge einer QS stellt sich die Frage, wie mit der möglicherweise bereitgestellten Dokumentation von Drittanbietern umgegangen werden soll. Bindet ein Anbieter Drittinhalte bzw. Funktionen (ReadSpeaker, Webex Konferenzen o.ä.) direkt auf den Seiten ein, werden diese ja als Teil der Seite mitgeprüft / bewertet. Wenn die Dokumentation für diese Funktionen aber außerhalb des Angebots liegt, lässt sie sich kaum mitprüfen. In meinem Verständnis sollte dann dieser Prüfschritt auf "nicht anwendbar" gestellt werden. In den Anmerkungen zu Prüfauftrag könnte (oder sollte?) vermerkt werden, dass die Barrierefreiheit der ggf. bereitgestellten Dokumentation von Inhalten/Funktionen von Drittanbietern im Test nicht erfasst werden kann und ggf. getrennt ermittelt werden muss. Richtig befriedigend ist das nicht, aber ein "nicht erfüllt" für 12.2.4 müsste ja voraussetzen, dass entsprechende Dokumente der Drittanbieter tatsächlich als Teil der Seitenauswahl im Test erfasst wurden - und das scheint mir unsinnig.

sweckenmann commented 3 years ago

Bei 12.2.2 haben wir neulich beschlossen (?) https://github.com/BIK-BITV/BIK-Web-Test/pull/188, dass der Prüfschritt nur anwendbar ist, wenn es einen Support gibt (es geht dort darum Fragen zu den Barrierefreiheitsfunktionen zu stellen). Ich fände es konsistent, wenn wir hier bei 12.2.4 unter Anwendbarkeit ebenfalls aufnehmen, dass er nur anwendbar ist, wenn ein Support zur Verfügung gestellt wird. Wir waren uns an anderer Stelle soweit ich weiß einig, dass mit "Support vorhanden" ein expliziter Support gemeint ist und nicht nur ein normaler Kontakt zum Website-Anbieter. Somit hätte sich das Problem bei der Einbindung von Drittanbietern auf "normalen" Websites schon gelöst (und im obigen Fall wäre der Prüfschritt "nicht anwendbar"). Denn ein Support wird eher bei Webanwendungen/Fachanwendungen zur Verfügung gestellt werden.

MarcHaunschild commented 3 years ago

Man läuft da tatsächlich auch in praktische Probleme und in Konflikte. Zuerst zu dem Konflikt, den du schon beschrieben hast: eigentlich kann es nicht sein, dass keine Dokumentation besser bewertet wird (nicht anwendbar, keine Abwertung) als eine fast perfekte (in Teilen nicht zugänglich für jeden mit entsprechenden Abwertungen). Insofern müsste das Fehlen einer Dokumentation zu einer Abwertung führen (ist das so? - Habe die neuen Prüfschritte noch nicht alle im Kopf)... Andererseits sollten abgrenzbare Module jeweils unabhängig voneinander getestet werden. Sonst muss man beim Testen einer Website, die mit einem CMS erstellt wurde und einen (technisch vielleicht auf einem anderen System basierenden internen Bereich) die öffentlichen und nicht öffentlichen Teile der Website, die beiden Backends, die Dokus für beide Backends und die Dokus für beide Seiten testen (wenn diese Programmcharakter haben). Wie viele Seiten müsste man denn für solch einen Test auswählen und wie lange sollte der dauern? Das meine ich mit praktischen Problemen.

MarcHaunschild commented 3 years ago

Denn ein Support wird eher bei Webanwendungen/Fachanwendungen zur Verfügung gestellt werden.

Aber nicht ausschließlich und wenn Support oder Doku angeboten werden, bleibt es dabei, dass man in praktische Probleme läuft.

Mein letzter Beitrag hat leider noch keine Lösungen. Er wirft weitere Fragen auf: ab wann darf man eine Doku verlangen? Aus dem Bauch raus würde ich sagen: nie.

Wodurch wir wieder bei dem genannten Problem sind, dass eine rudimentäre, nicht vollständig barrierefreie Doku besser ist als gar keine, aber schlechter bewertet werden muss...

Das betrifft natürlich viele Dinge. Ich habe schon Betreiber kennen gelernt, die sagen: "Barrierefreie PDFs sind uns zu kompliziert. Dann schmeißen wir die einfach raus und die durchaus wertvollen Infos da drin bekommt dann halt keiner mehr." und haben das dann auch durchgezogen.

Heute empfehle ich so etwas zumindest als Teil einer Remediation-Strategie sogar selber (alle PDF-Dokumente durchgehen und alle irrelevanten oder veralteten entfernen).

Da Dokus oft im portable document format abgelegt werden, schließt sich hier der Kreis zum ursprünglichen Thema.

detlevhfischer commented 3 years ago

Dass inhaltliche Fragen ausgeklammert werden (z.B. muss es Dokumentation, muss es Hilfe geben?) findet sich an vielen Stellen der WCAG und hat wohl damit zu tun, dass hier Grauzonen und damit auch die immer subjektiven PASS/FAIL Entscheidungen vermieden werden sollen. Siehe z.B. das geplante WCAG 2.2 Kriterium Findable Help https://www.w3.org/TR/WCAG22/#findable-help - nicht, dass Hilfe geboten wird wird hier geprüft, sondern ob Links dazu konsistent in gleicher Reihenfolge angeboten werden (was eigentlich ja bereits in (9.)3.2.3 Einheitliche Navigation geprüft wird). Deshalb scheint mir hier ziemlich klar, dass wir nicht die inhaltliche Bereitstellung von Dokumentation fordern können.

MarcHaunschild commented 3 years ago

Dass inhaltliche Fragen ausgeklammert werden (z.B. muss es Dokumentation, muss es Hilfe geben?) findet sich an vielen Stellen der WCAG

Du hast absolut recht, mir ist das auch klar. Dieser Konflikt begleitet uns alle (Prüfer, Entwickler, Auftraggeber...) seit den ersten Überlegungen zur Barrierefreiheit.

Dabei ist es eigentlich einfach: Geprüft werden kann nur, was vorhanden ist.

johannesFischer84 commented 3 years ago

zur Anwendbarkeit: In Anhang C der EN in der Precondition für die Anwendbarkeit von 12.2.4 steht, dass die Prüfung anwendbar ist, wenn vom Support Dokumentation bereitgestellt wird:

Documentation is provided by the ICT support services.

Dies steht aber auch bereits in der Prüfschrittanleitung, hab eben nachgelesen. Eine Abwertung bei fehlender Dokumentation ist nirgendwo erwähnt. Also kann ggf. eine vorhandene relativ barrierefreie Dokumentation auch schlechter bewertet werden als gar keine. Das gleiche Problem haben wir zum Beispiel bei entwicklergestaltetem Fokus, der zumindest noch nach WCAG 2.1 bei schlechtem Kontrast schlechter bewertet wird als die Nutzung allein des Browser-Standard-Fokus.

Man muss den Support erst kontaktieren und nach Dokumentation fragen. Auch wenn die Dokumentation auf einem externen Auftritt liegt, ist sie für die Prüfung relevant, denn der Support des Webseitenbetreibers verweist auf sie. Ich würde auch bei Kriterium 12.1.2 (Barrierefreie Dokumentation) sagen, dass verlinkte Dokumentation bei einem Vorleseprogramm relevant zur Prüfung ist.

Aber man muss bei den externen Dokumentationen nicht unbedingt für jedes Kriterium der WCAG eine Bewertung angeben. Es reicht, wenn man bei 12.1.2 bzw. 12.2.4 eine Bewertung abgibt. Eventuell ist es im Einzelfall ein Kompromiss, wenn man die externen Dokumentationen nicht in die Seitenauswahl aufnimmt und für 12.1.2 bzw. 12.2.4 nur stichprobenartig prüft.

detlevhfischer commented 2 years ago

Die Bedingung, das "Documentation provided by support services" überhaupt vorhanden ist, damit dieser Prüfschritt anwendbar ist, habwen wir ja unter 1. Anwendbarkeit des Prüfschritts, "Der Prüfschritt ist anwendbar, wenn Support Services eine technische Dokumentation zur Nutzung des Angebots bereitstellen..." erfasst.

Ich denke, wir können dieses Issue damit schließen. (Wer anderer Meinung ist, möge es wieder öffnen).