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
67 stars 21 forks source link

5.2 BIK-Prüfschritt entspricht nicht der EN-Vorbedingung(?) #340

Closed Martina-XX closed 9 months ago

Martina-XX commented 1 year ago

Hallo, beim Schreiben eines anderen Issues ist mir gerade Folgendes aufgefallen:

In der EN steht als Vorbedingung zur Anforderung 5.2, dass nur bereits dokumentierte Features (also Funktionen, die auch wirklich in der Produktdokumentation benannt sind) betrachtet werden:

"Die IKT hat dokumentierte Barrierefreiheitsfunktionen, um ein bestimmtes Erfordernis zu erfüllen."

Habe ich also einen Kontrastschalter, der nicht dokumentiert ist, dürfte ich ihn gar nicht bei 5.2 bemängeln ... rein EN-theoretisch, oder? Was meint ihr? Den Schalter würde man ja dann bei 1.4.3 oder 1.4.11 einsortieren.

Im Prüfschritt hingegen steht

"Wenn die Webseite Funktionen für die Barrierefreiheit bereithält, die spezielle Bedürfnisse von Nutzern erfüllt, soll die Aktivierung dieser Funktionen für diese Nutzergruppe barrierefrei möglich sein."

Das ist schon ein Unterschied. 5.2 geht im BIK-Prüfschritt weiter. Ich persönlich finde das gut, aber wenn wir Konformität nachweisen müssen, würde man ggf. bei 5.2 zu streng bewerten. Oder habe ich da irgendwo einen Denkfehler? Freue mich über Aufklärung. 🙂

Kann mir gut vorstellen, dass es hier untschiedliche Meinungen zu gibt.

johannesFischer84 commented 1 year ago

Über den Begriff "documented accessibility features" in der EN-Anforderung 5.2 wurde tatsächlich bisher nicht diskutiert, soweit ich mich erinnern kann. Ich denke, dass es zur Definition des Begriffs verschiedene Meinungen geben kann. Die EN selbst definiert das nicht genauer, zumindest habe ich dazu nichts gefunden.

Angenommen, man interpretiert den Begriff in der gleichen Bedeutung wie den Begriff "product documentation" aus Abschnitt 12. Dann würde ich streng nach EN-Formulierung tatsächlich sagen, dass man eine Barrierefreiheitsfunktionalität wie den Kontrastumschalter in Anforderung 5.2 nicht negativ bewerten kann, sofern er weder in der Erklärung zur Barrierefreiheit noch auf einer Hilfe-Seite (oder einem beiliegenden Handbuch) genannt ist. Auch wenn einem das vielleicht widerstrebt.

Wie du sagst, kann eine Bewertung für einen Kontrastumschalter aber bei WCAG 1.4.3 / 1.4.11 setzen.

sprungmarker commented 1 year ago

@johannesFischer84 @detlevhfischer

Das mag formal womöglich korrekt sein - aber ich habe auch nichts dazu gefunden, was genau mit "documented accessibility features" gemeint ist. (Leider haben die keinen wirklichen Glossar für ihre Begrifflichkeiten ...)

Das würde ich gerne schon noch mal klären wollen. Wenn es bedeutet, dass wenn jemand Barrierefreiheitsfunktionen auf der Seite integriert und sie nicht dokumentiert, sie nicht geprüft werden sollen, finde ich das schon suboptimal.

Dieser Prüfschritt ist dann wohl eher "sinnlos" - weil die meisten Barrierefreiheitsfunktionen wie Kontrastumschalter werden nicht dokumentiert werden.

@johannesFischer84 wie geht man da vor, fragt man bei Etsi nach?

detlevhfischer commented 1 year ago

Ich habe einen PR https://github.com/BIK-BITV/BIK-Web-Test/pull/342 angelegt - vielleicht klärt das dieses Problem...

sweckenmann commented 1 year ago

Das würde ich gerne schon noch mal klären wollen. Wenn es bedeutet, dass wenn jemand Barrierefreiheitsfunktionen auf der Seite integriert und sie nicht dokumentiert, sie nicht geprüft werden sollen, finde ich das schon suboptimal.

Dieser Prüfschritt ist dann wohl eher "sinnlos" - weil die meisten Barrierefreiheitsfunktionen wie Kontrastumschalter werden nicht dokumentiert werden.

Wenn es Probleme mit den Funktionen gibt, würde diese ja bei entsprechenden anderen WCAG-Prüfschritten bewertet. Insofern reschließt sich mir der Sinn dieser Vorbedingung auch nicht.

johannesFischer84 commented 1 year ago

@sprungmarker Sylvia, ich stimme zu. Aber wie Sonja (sweckenmann) schreibt, gibt es ja noch die WCAG-Kriterien, das Problem geht also nicht unter, denke ich.

Eine Art Glossar für Begriffe gibt es schon. Das ist Abschnitt 3 der EN 301 549. Nur gerade dieser Begriff ist dort nicht beschrieben. Ja, man könnte bei Etsi nachfragen oder einen Hinweis z. B. an Klaus-Peter Wegge vom Siemens Accessibility Center geben, der mit dem DIN zusammen aus Deutschland Änderungen in der EN gibt. Etsi hat ein eigenes Gitlab mit Issues. Dort können nur Etsi-Mitglieder oder ähnlich kommentieren. Du könntest dich aber an die E-Mail-Adresse HFsupport@etsi.org wenden, die dort auf der Wiki-Seite verlinkt ist. Ich hatte da selbst schon mal wegen anderen Dingen Kontakt aufgenommen.

CarstenKaul commented 5 months ago

Sorry, dass ich das Issue wieder öffne, aber ich habe nicht verstanden wie jetzt der Stand der Dinge ist. Die Eingangsfrage lautete: "Darf ein Kontrastumschalter der nicht in der EzB aufgeführt ist unter 5.2 bewertet werden. Der Link auf #342 und #339 ist als Antwort auch nicht hilfreicher. In der aktuellen Prüfschrittbeschreibung heißt es: "Der Prüfschritt ist anwendbar, wenn die zu prüfende Webseite spezielle Barrierefreiheits-Funktionen bereithält, die im Angebot selbst, etwa in den Einstellungen, oder in einer zur Verfügung gestellten technischen Dokumentation dokumentiert sind.". Wenn ich die Formulierung "im Angebot selbst" richtig verstehe, dann gilt das also auch für undokumentierte und im Angebot vorhandene Funktionen. Bislang habe ich deshalb 5.2 auch dann auf Kontrastumschalter angewendet, wenn diese nicht in der EzB aufgeführt waren. Ich bitte um kurze Aufklärung. Danke.

Edit: Format

CarstenKaul commented 5 months ago

Ich wurde inzwischen auf folgenden BIK-Hinweis in Anforderung 12.1.1 - https://ergebnis.bitvtest.de/pruefschritt/bitv-20-web/bitv-20-web-12-1-1-dokumentation-von-kompatibilitaet-und-barrierefreiheit - aufmerksam gemacht: In Ziffer 3. Hinweis, Punkt 4 heißt es:

Manche Barrierefreiheitsfunktionen, etwa Kontrastschalter im Kopfbereich, ändern unmittelbar die Darstellung der Seite und können damit als selbsterklärend gelten. Sofern diese einfachen Schalter zugänglich umgesetzt sind (also z.B. einen programmatisch ermittelbaren Namen und Zustand haben) müssen sie nicht explizit in der Erklärung zur Barrierefreiheit dokumentiert sein.

Ich schlage vor, diese Information in 5.2 irgendwie zu erwähnen/verlinken/hinzuweisen oder abzugrenzen. Das Issue kann dann wieder geschlossen werden.

johannesFischer84 commented 4 months ago

In der aktuellen Prüfschrittbeschreibung heißt es: "Der Prüfschritt ist anwendbar, wenn die zu prüfende Webseite spezielle Barrierefreiheits-Funktionen bereithält, die im Angebot selbst, etwa in den Einstellungen, oder in einer zur Verfügung gestellten technischen Dokumentation dokumentiert sind.". Wenn ich die Formulierung "im Angebot selbst" richtig verstehe, dann gilt das also auch für undokumentierte und im Angebot vorhandene Funktionen. Bislang habe ich deshalb 5.2 auch dann auf Kontrastumschalter angewendet, wenn diese nicht in der EzB aufgeführt waren. Ich bitte um kurze Aufklärung. Danke.

@CarstenKaul Carsten, für "im Angebot selbst dokumentiert" ist als Beispiel "in den Einstellungen" angegeben. Damit eine Barrierefreiheitsfunktionalität "dokumentiert" ist, würde ich mindestens mal einen Satz erwarten, der die "Dokumentation" liefert. Ein einzelner Begriff kann aus meiner Sicht nur beschriften, aber nicht dokumentieren. Wie weiter oben in diesem Faden geschrieben wurde, ist der Begriff "documented accessibility features" aber nicht genauer definiert. Daher ist es meiner Meinung nach eine Grauzone, ob man 5.2 auf Kontrastumschalter anwenden kann, die in der Erklärung zur Barrierefreiheit (EzB) nicht genannt sind.

Die Prüfung in 12.1.1 scheint mir davon unberührt zu sein. Ich persönlich bin aber der Meinung, dass auch selbst erklärende Funktionen zumindest in der EzB erwähnt sein müssen,siehe hier.

sprungmarker commented 4 days ago

Ich habe mal ein Issue bei Etsi dafür angelegt - man kann individuell einen Account anlegen und Issues anlegen: Etsi: EN 301 549: 5.2 documented accessibility features

Die Antwort hilft derzeit nicht weiter, sie arbeiten wohl daran solche "Ambiguitäten" in der nächsten Version zu bereinigen. Aber das hilft derzeit halt nicht wirklich weiter.