Prüfung mit dem Styleswitcher

[ThomKoeh]

Hallo,

wir haben gerade eine Diskussion über den Test der Kontraste mit dem Styleswitcher.

Daraus ergeben sich mehrere kleinere Fragestellungen: 1) Warum wird der Syleswitcher explizit nur bei 9.1.4.3 erwähnt – bei den beiden anderen wird nur auf die WCAG bzw. auf Prüfung analog 9.1.4.3 verwiesen – ist es nicht sinnvoll eine analoge Aussage gemäß 9.1.4.3 (2.2 Styleswitcher-Prüfung, Prüfung der Textkontraste der alternativen Ansicht) einzufügen? 2) Die Information, welche Elemente/Textpassagen einen zu geringen Kontrastwert landen nach einem entwicklungsbegleitenden Test (ohne anschließende Zertifizierung erst einmal in der EzB (Erklärung zur Barrierefreiheit) – Der Link auf die EzB muss analog des Styleswitchers bereits vor der Verwendung des Styleswitchers hinreichend kontrastieren, da – wenn erst durch den Styleswitcher der Link auf die EzB hinreichend kontrastiert – dieser aber ebenfalls nicht hinreichend kontrastiert – finden seheingeschränkte Nutzende beides nicht…Vor allem, wenn das Bedienelement in einem Menü versteckt ist, kann es passieren, dass die Nutzenden erst in der EzB auf den Styleswitcher aufmerksam werden.

Wenn Ihr hierzu eine Meinung habt, könnt ihr gerne Beiträge schreiben. Beste Grüße Thomas Köhler

[johannesFischer84]

Zu 1: Mit anderen Prüfschritten beziehen Sie sich vermutlich auf WCAG-Kriterium 1.4.11 und vielleicht auch auf WCAG 2.4.7. Bei Ersterem stimme ich auf jeden Fall zu, dass ein Kontrast-Styleswitcher verwendet werden kann. Denn die Technik G142 bezieht sich klar auch auf WCAG 1.4.11. Dementsprechend wäre eine Ergänzung in der Prüfschrittanleitung sinnvoll. Bei WCAG 2.4.7 die Kontrastprüfung halte ich zwar nach wie vor von der Bewertung her dort nicht richtig, sondern sie gehört aus meiner Sicht auch zu 1.4.11. Aber wo man es bewertet, ist jetzt hier nicht so wichtig und bei 1.4.11 wäre der Styleswitcher ja eine passende Lösungsmöglichkeit.

Zu 2: Was Sie fordern, ist sehr wünschenswert und man kann das in Beratungen eindringlich empfehlen. Aber wenn beides nicht ausreichend Kontrast hat, kann man aus meiner Sicht nur den Kontrast-Prüfschritt mit nicht konform bewerten, egal in welcher Reihenfolge die Links/Schaltflächen stehen. So oder so ist die Seite dann aber nicht konform.

[CarstenKaul]

Ich möchte dazu anmerken, dass einige Prüfstellen bereits Prüfvorgehen mit/für Overlaytools ausgearbeitet haben. Ein Kontrastumschalter ist aus meiner Sicht ähnlich wie Overlaytools zu bewerten. Was immer man also hier also entscheidet, sollte einem Prüfvorgehen bei Overlaytools nicht widersprechen.

[detlevhfischer]

@CarstenKaul Ein Styleswitcher, der einen höheren Kontrast anschaltet (und damit im besten Fall Konformität eines Angebots herstellt, wenn sonst alles konform war bis auf den Kontrast) ist etwas anderes als ein Overlay, das zahlreiche verschiedene Einstellungsmöglichkeiten bietet (i.d.R. ohne dass irgend eine davon komplette Konformität herstellen würde). Die Anforderungen der WCAG an conforming alternative versions sind klar: Die konforme Version muss über einen barrierefreien Mechanismus erreichbar sein, etwa ein Link. Ein konventioneller barrierefreier Umschalter für Kontraste kann diese Bedingung ggf. erfüllen. Ein Widget, das zahlreiche verschiedene Einstellungsmöglichkeiten bietet, ohne dass klar ist, welche Kombination davon denn eine konforme Alternativversion erzeugt, kann dies nicht für sich in Anspruch nehmen.

Es ist aus meiner Sicht also unrichtig, einen Kontrastumschalter ähnlich wie ein Overlay-Tool zu bewerten, was immer das heißen soll.

[CarstenKaul]

Das sehe ich anders. Nicht jedes Overlaytool muss "zahlreiche verschiedene Einstellungsmöglichkeiten" haben. Meiner Meinung ist das zu kurz gedacht und es wäre ein Fehler Kontrastumschalter anders zu behandeln. Es wird früher oder später hier zu Diskussionen kommen.

Die Überwachungsstellen haben den Begriff Overlaytool hier definiert: https://www.bfit-bund.de/DE/Publikation/einschaetzung-overlaytools.html

Was sind Overlay-Tools?

Als Overlay-Tool wird in der Regel eine Softwarelösung bezeichnet, deren Ziel es ist, innerhalb eines Webauftrittes die Zugänglichkeit (Barrierefreiheit) zu verbessern. Dabei wird häufig Quellcode von Drittanbietenden (in der Regel Javascript) dem Quellcode der Webseite hinzugefügt. Die dadurch verursachten Veränderungen sind nur solange verfügbar, wie das entsprechende Tool im Webauftritt integriert ist. Die Funktionsvielfalt ist dabei sehr unterschiedlich.

Das ist aber ein Thema, dass hier im Thread Offtopic wird und wir hier nicht diskutieren müssen. Ich wollte nur darauf hinweisen, dass wenn BIK hier grundlegende Entscheidungen trifft, diese Entscheidungen den Bewertungen und Prüfvorgehen von Overlaytools nicht widersprechen sollten, wenn es heute (oder später) technisch kaum noch Unterschiede dazu gibt.

Edit: Format

[detlevhfischer]

@ThomKoeh Danke für den Hinweis, es stimmt, hier sollte analog zu 9.1.4.3 auch die Styleswitcher -Ansicht geprüft werden, falls sie ausreiched Kontrast für Grafiken und Text herstellt. Bestehen nach Aktivierung weiter irgendwelche Kontrastmängel, würden wir diese Ansicht nicht berücksichtigen. Siehe PR #409

Können wir das Issue schließen?

[detlevhfischer]

@CarstenKaul Der Punkt ist: Wenn es nicht einen klaren Mechanismus (Link, Taste) gibt, dessen Aktivierung die Alternativversion aufruft, kann diese nicht zur Erfüllung der Konformität herangezogen werden (im hypothetischen Fall, dass dann alle Mängel verschwinden). Wenn es ein Overlay-Tool gäbe, dass so einen Schalter prominent und klar beschriftet enthielte, läge der Fall anders. So sagt es im übrigen auch das Dokument der BFIT, auf das Du verweist:

Diese Einstellung soll z. B. durch eine Kennzeichnung leicht aufgefunden werden können, um eine einfache Handhabung im Sinne der Barrierefreiheit zu gewährleisten. Dies impliziert aus unserer Sicht, dass die barrierefreie Alternativversion über einen einzigen barrierefreien und verständlichen Schalter bzw. Link aufrufbar sein muss.

Sämtliche Overlays, die mir bislang begegnet sind, treten ja als mehr oder weniger vollgepackte Schweizer Messer auf und lassen so einen Mechanismus allesamt vermissen. Sollte sich das ändern (was unwahrscheinlich ist), müsste in einem Zwischenschritt geprüft werden, ob nach Aktivierung dieses Mechanismus noch Barrieren bestehen (was in der Regel der Fall sein würde). Dann kann das Overlay-Tool insgesamt vernachlässigt werden (es sei denn, die Einbindung selbst schafft Barrieren für die Seite schon vor Aufruf).

[detlevhfischer]

Ich hoffe, die Frage ist damit geklärt, und ich schließe dieses Issue. Sonst bitte wieder öffnen.