9.1.4.3 Kontraste von Texten ausreichend

[Sommerli2]

Hallo zusammen, bei den Kontrasten von Texten sollten wie im Prüfschritt vermerkt alle Zustände berücksichtigt werden. Leider sind die Browser an dieser Stelle bei der Darstellung von Standard-Elementen noch nicht wirklich barrierefrei.

Beispiel: bei einem "Select" wird in Nutzung die Selektion im Chrome mit weißer Schrift auf hellblauen Hintergrund im Chrome dargestellt. Gleiches gilt für Standard-Kalender. Dieses Verhalten wird durch den Nutzer-Agenten (Browser) gesteuert und ist nicht mit CSS konfigurierbar.

Da nach Möglichkeit HTML5-Standard-Elemente verwendet werden sollen, sehe ich hier eine Diskrepanz. Im Gegensatz zu anderen Prüfschritten (bsp. 9.1.4.13 Eingeblendete Inhalte bedienbar) gibt es aber auch eine Ausnahmeregelung von der Gebrauch gemacht könnte.

Wie ist dies zu händeln? Muss hier entsprechend des Prüfschritts abgewertet werden, was dazu führt, dass Standard-Komponenten mit besseren Kontrasten nachgebaut werden müssten?

Besten Dank und viele Grüße Janina

[sweckenmann]

Wenn Standard-HTML-Elemente verwendet werden, dann gilt das als Ausnahme.

Nur wenn benutzerdefinierten Bedienelemente eigesetzt werden, beispielsweise "nachgebaute" Selects mit eingenen Styles, dann müssen für diese Custom Controls Kontrastanforderungen erfüllt werden.

[ElVariablo]

@sweckenmann können Sie das im BIK BITV Test im Prüfschritt unter "Fragen zu diesem Prüfschritt" aufnehmen?

[mitchellevan]

(See below for English translation.)

Bitte schreiben Sie keine Ausnahme in BITV, die die WCAG in Europa schwächt. Wenn wir das tun, schaffen wir einen schrecklichen Präzedenzfall: Wir sagen den Browser-Entwicklern, dass wir einfach die Regeln ändern, wenn sie die Barrierefreiheit brechen.

Verwenden wir standardmäßige, ansonsten gut unterstützte Browsersteuerelemente. Wo CSS die Browserprobleme nicht behebt, verwenden wir die Erklärung zur Barrierefreiheit, um dem Browser die Schuld zu geben. Dies sollte dazu beitragen, den Druck auf Browser-Entwickler aufrechtzuerhalten, ihre Bugs zu beheben.

Beispiel:

"Die nachstehend aufgeführten Inhalte sind aus folgenden Gründen nicht barrierefrei:
(a) Nichteinhaltung der Barrierefreie-Informationstechnik-Verordnung (BITV) 2.0
In einigen Formularfeldern, wie Optionslisten oder Datumsfeldern, hat die aktuelle Auswahl einen unzureichenden Farbkontrast im Chrome-Browser. Es ist derzeit nicht möglich, dass der Website-Inhaber dieses Problem behebt. Bis Google das Problem im Chrome-Browser selbst behebt , müssen wir den Benutzern empfehlen, zu einem anderen Browser zu wechseln."

Mitchell Evan

(Englische Übersetzung:)

Please do not write an exception into BITV which makes WCAG weaker in Europe. If we do that, it sets a terrible precedent: we tell the browser developers that when they break accessibility we simply change the rules.

Let's use standard, otherwise well-supported browser controls. Where CSS does not fix the browser problems, let's use the accessibility statement to blame the browser. This should help sustain the pressure on browser developers to fix their bugs.

Example:

"The content listed below is non-accessible for the following reason(s):
(a) non-compliance with [the national legislation]
In some form fields, such as option lists or date fields, the current selection has insufficient color contrast in the Chrome browser. It is not currently possible for the website owner to fix this problem. Until Google fixes the problem in the Chrome browser itself, we must recommend that users switch to a different browser."

Hi all, For text contrast all states should be taken into account, as noted in the test step. Unfortunately, browsers are not actually accessible when displaying standard elements. Example: When a "select" element is used, the selected [option element] is displayed in Chrome with white letters on a light blue background. The same is true in standard calendars. This behavior is controlled by the user agent (browser) and is not configurable with CSS. Since HTML5 standard elements should be used whenever possible, I see a discrepancy here. In contrast to other test steps (e.g. 9.1.4.13 Content on Hover or Focus), there is an exception that could have been used. How can this be handled? Does the test step [9.1.4.3 Contrast (Minimum)] need to be weakened, [or must] standard components be rebuilt with better contrast? Best regards, janina

[detlevhfischer]

Hi @mitchellevan Ich habe ein WCAG Issue https://github.com/w3c/wcag/issues/3039 zur Diskussion der Frage angelegt, um Meinungen der Working Group dazu einzuholen.

Bitte schreiben Sie keine Ausnahme in BITV, die die WCAG in Europa schwächt.

Die EN, die sich auf die WCAG bezieht, gilt unabhängig vom BIK BITV-Test. Es gibt für beide Formen des Umgangs mit dem Problem Argumente. Wir finden es Kunden gegenüber schwer vermittelbar, sie mit einem Ergebnis "nicht konform" für Mängel zu bestrafen, für die sie nichts können - und sie ggf. indirekt damit zu zwingen, Custom Controls zu basteln, die Mühe und Zeit kosten und andere Nachteile mit sich bringen.

Mal abwarten, was die Diskussion ergibt.

[MarcHaunschild]

Das ist ein spannender Aspekt. Ich bin ja auch gar nicht mit den Standard-Fehlermeldungen oder title-Attributen zufrieden. Konkret, dass wir darauf bestimmte SCs nicht anwenden wie z.B. 9.1.4.4 Text auf 200 % vergrößerbar, 11.7 Benutzerdefinierte Einstellungen oder 9.1.4.13 Eingeblendete Inhalte bedienbar. Vielleicht könnte man das in einer allgemeinen Erklärung festhalten und bei den entsprechenden Prüfschritten ein Häkchen setzen, dass native Elemente genutzt werden. Dann würde man als Ergebnis immer noch den Test bestehen, erhält aber gleich auch vorgefertigte Texte für die Barrierefreiheitserklärung, die solche Dinge benennen und einfach in die Erklärung kopiert werden können? Außerdem können Nutzer sich vieles einstellen. Im Safari ist beispielsweise die Fokushervorhebung von den eigenen Einstellungen im MacOS-Farbschema abhängig.

[Sommerli2]

@MarcHaunschild auch im Edge erfüllt die Texte sowie die Fokushervorhebung die Anforderungen. In Firefox passen die Kontraste der Texte, dafür ist die Fokushervorhebung insuffizient. Die Frage ist nur, wie will man das ordnungsgemäß dokumentieren. Dazu müsste man in der Erklärung der Barrierefreiheit die jeweils genutzte Browser-Version angeben. Solche Verhaltensmuster könnten sich ja bei einer neuen Browserversion theoretisch jederzeit ändern (verbessern aber auch verschlechtern).

[patrickhlauke]

Dazu müsste man in der Erklärung der Barrierefreiheit die jeweils genutzte Browser-Version angeben. Solche Verhaltensmuster könnten sich ja bei einer neuen Browserversion theoretisch jederzeit ändern (verbessern aber auch verschlechtern).

Genau, das macht dann Pruefergegnisse volkommend abhaengig von den Browsern, die fuer die Pruefung benutzt wurden, und deren Verhalten in der getesteten Version. Darueber hinaus sind dann oft noch verschiedene andere Faktoren (z.B. das Farbschema, dass der Benutzer im OS eingestellt hat, was dann Sachen wie den "Accent Colour", den ein Browser verwendet, beinflussen koennte). Macht das ganze dann sehr fragil...

[MarcHaunschild]

Ja, ich hatte schon gedacht, dass man das dann alles genau angibt, so wie @mitchellevan es für den Fall mit den select Boxen vorgeschlagen hat. Theoretisch ginge das, aber die Texte der Barrierefreiheitserklärung wären dann ja unendlich lang, wenn alle Browser und Versionen berücksichtigt würden. Vielleicht macht es Sinn einen Text zu verfassen, in dem das Problem kurz beschrieben wird: in Browsern können native Elemente nicht immer vollständig durch den Webseiten-Betreiber gestaltet werden. Hier kann es zu unzureichenden Kontrasten, unvollständiger Beeinflussbarkeit durch Nutzer und andere Probleme kommen. Die Verwendung der standardisierten nativen Elemente haben aber Vorteile, die die Verwendung gerechtfertigt erscheinen lassen. Daher führt es nicht zu einer Abwertung, wenn einige Browser bei der Umsetzung der nativen Elemente (noch) nicht alle Anforderungen erfüllen. In vielen Fällen lassen sich die Probleme durch Einstellungen im Betriebssystem, in den Browser-Optionen oder durch Verwendung eines anderen Browsers lösen.

[mitchellevan]

Vielleicht macht es Sinn einen Text zu verfassen, in dem das Problem kurz beschrieben wird

Das ist ein guter Kompromiss. Könnte der Text auch konkret sagen, welche Arten von nativen Bedienelementen eventuell betroffen sind, z. B. Optionslisten und Datumsfelder? Damit Benutzer und Entwickler verstehen können, dass die Probleme begrenzt sind.

[MarcHaunschild]

Vielleicht macht es Sinn einen Text zu verfassen, in dem das Problem kurz beschrieben wird

Könnte der Text auch konkret sagen, welche [Elemente …] eventuell betroffen sind? Damit Benutzer und Entwickler verstehen können, dass die Probleme begrenzt sind.

Mir ging es zunächst um einen Hinweis über das Testverfahren, den man womöglich auch in die Barrierefreiheitserklärung aufnehmen könnte. Die Elemente selber ändern sich und die Probleme sind unterschiedlich. Ich dachte gerade an einen unspezifischen Hinweis, der berücksichtigt, dass kaum alle spezifischen Einzelheiten erfassbar sind und der Nutzer zum experimentieren einlädt, womit sie am besten klar kommen. Einer der wichtigsten Vorteile von nativen Elementen ist ja, dass sie sich immer gleich verhalten. Gerade wenn man auf Tastatur ode Hilfsmittel angewiesen ist, kommt man besonders mit Elementen klar, die tun, was man erwartet . Es lohnt sich auch, für deren Mängel eine Strategie zu erlernen, weil man diese Elemente häufig sieht. Auch soll parallel der Druck auf die Hersteller hoch bleiben. Wenn einer dieses Probleme angeht, werden viele Millionen von Webseiten zugänglicher. Das liefert praktisch keine selbst gebaute eigene Lösung. Selbst die verbreitetsten wie Bootstrap ändern Komponenten in neueren Versionen oder werden von anderen frameworks abgelöst. Aber es gibt Webseiten, die sind 20 Jahre und länger am Markt und profitieren nach wie vor von jedem Browser-Update.

[detlevhfischer]

Ich habe im Prüfschritt 9.1.4.3 "Kontraste von Texten ausreichend" eine Ausnahme für native Elemente hinzugefügt und die Ausnahme eines geringeren Kontrastes bei Fokushervorhebung entfernt.

321

Bei Änderungsvorschlägen gerne im PR kommentieren!

[mitchellevan]

Im Pull Request: > Da die Nutzung nativer Elemente große Vorteile gegenüber dem Einsatz von Custom-Elementen bietet, gilt dieser Prüfschritt deshalb trotzdem als erfüllt, wenn die Kontrast-Mängel ausschließlich auf die Darstellung von nativen Elementen durch den jeweiligen Browser zurückzuführen sind. Richtig... es kann den Prüfschritt erfüllen, obwohl es technisch nicht das WCAG-Kriterium erfüllt. Ein guter Kompromiss.

[ljme]

Thanks @mitchellevan for bringing this to my attention. Chrome welcomes bug reports through its two bug tracing systems: Chrome Browser and all cross-platform bugs: crbug.com ChromeOS, Android, or other bugs: https://issuetracker.google.com/

I have opened two bugs for these concerns: Issue 1419033: HTML 5 elements too low of contrast: selects, date pickers, time pickers Issue 1419038: Feature Request: make HTML5 elements styleable with CSS: select, date picker, time picker

Please direct further inquires towards Chrome on this matter into those public bugs.