9.1.4.3 Kontraste von Texten ausreichend: Native Elemente #321
Conversation
Hinzufügung eines Abschnittes 3.4 3.4 Hinweise zu mangelnden Kontrasten nativer Elemente in Browsern (z.B. `select`, datepicker widgets)
detlevhfischer
added
changelog:added ➕
Entfernung der Vorgabe in 4. Bewertung: "Das Kontrastverhältnis des schlechteren Zustands des Maus- und Tastaturfokus liegt über 3:1." Dies is nicht durch den normativen Text gedeckt
detlevhfischer
changed the title
Richtig... es kann den Prüfschritt erfüllen, obwohl es technisch nicht das WCAG-Kriterium erfüllt. Ein guter Kompromiss. |
|
|
||
| === 4. Bewertung | ||
| Autoren haben auf die Darstellung nativer Elemente und Widgets zurzeit keine ausreichenden Einflussmöglichkeiten, um für guten Kontrast in allen Zuständen zu sorgen. Würden sie deshalb native Elemente durch kontrastreichere Custom-Elemente ersetzen, entstünden ggf. andere Probleme: die korrekte Darstellung ist von JavaScript abhängig, es treten umgebungsabhängig Probleme bei der Nutzung mit Screenreadern auf, der Code ist umfangreicher und dadurch fehleranfälliger, usw. 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. | ||
|
|
There was a problem hiding this comment.
Sollte man hier nicht präziser sein, in etwa "Autoren, haben auf die Darstellung bestimmter Bereiche von nativen Elementen (z.B. <select> und <input type="date">) zur Zeit keine ausreichende Einflussmöglichkeiten..." - die nicht-Stylebarkeit betrifft ja nicht alle nativen Elemente und beim select kann man die selectbox an sich stylen (nur die eingeblendeten options nicht - ist vielleicht für diesen Prüfschritt nicht relevant, aber um nichts Falsches zu schreiben). Gleichzeitig frage ich mich, ob es neben select und datepicker noch andere Elemente gibt.
There was a problem hiding this comment.
Das alles kann sich mit dem nächsten Browser-Update ändern, und je nach Browser gibt es unterschiedliche Mängel (z.B. Fokushervorhebung auf select options unter 3:1 im Firefox) - ich würde es eher allgemein lassen.
There was a problem hiding this comment.
Bei select-Elementen gibt es ja nicht nur in Bezug auf Hintergründe unterschiedliche Möglichkeiten die Darstellung zu beeinflussen. Für mein CSS-Buch habe ich diverse Formatierungen vorgenommen. Der eine Browser setzt dieses um, der nächste jenes.
Außerdem betrifft es ja auch File-Uploads, summary und details uswusf - oder ist da inzwischen alles möglich?
Sind jedenfalls doch noch ein paar mehr...
| @@ -108,9 +108,14 @@ Ansicht erfolgt nur unter folgenden Bedingungen: | |||
| höher auflösenden Bildschirmen)Für die Prüfung maßgeblich ist der | |||
| Referenzwert von 96 dpi Bildschirmauflösung, für den die Entsprechung auf | |||
| jeden Fall gilt. | |||
|
|
|||
| === 3.4 Hinweise zu mangelnden Kontrasten nativer Elemente in Browsern (z.B. `select`, datepicker widgets) | |||
| Abhängig vom genutzten Browser sind in manchen Zuständen die Kontrastwerte nicht ausreichend. So wird etwa bei `select`-Elementen in der Darstellung im Chrome-Browser die jeweils ausgewählte Option durch weiße Schrift auf blauem Hintergrund mit einem Kontrast von nur 3,2:1 dargestellt. Formal gesehen wäre deshalb bei der Verwendung nativer Elmente mit Kontrastmängeln dieser Prüfschritt in manchen Browsern nicht erfüllt. | |||
There was a problem hiding this comment.
Würde schreiben "3.4 Hinweise zu mangelnden Text-Kontrasten nativer Elemente in Browsern (z.B. select, datepicker widgets)
kleinE Textanpassung unter "Was wird geprüft?"
select, datepicker widgets): Nicht ausreichender Kontrast etwa bei Fokussierung wird bei nativen Elementen akzeptiert (ist Aufgabe für User Agent Hersteller)Closes #317