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

11.7 Minimale Anforderungen für benutzerdefnierte Farben #337

Open sweckenmann opened 1 year ago

sweckenmann commented 1 year ago

Ich möchte Diskussion mit @jkphl hier öffnen, wir haben überlegt, was genau man im Sinne der EN fordern kann, was nicht:

Aus anderen issue-Diskussionen kristallisierte sich heraus, dass zentrale Funktionen auch bei benutzerdefinierten Farbeinstellungen weiterhin benutzbar bleiben sollen. Aus meiner Erfahrung aus eigenen Tests (und QS), handelt es sich dabei (in der Regel) um:

  1. Hamburger-Icon
  2. Zustand von Checkboxen und Radio-Inputs (ausgewählter Zustand ist ggf. nicht mehr sichtbar, Checkbox-Icon oder gefülltes Element des Radio-Inputs)

Gedanken dazu:

  1. Wird ein svg eingesetzt, das dieselbe Farbe hat, wie der Text (Vordergrund), kann man durch den Einsatz von currentColor dafür sorgen, dass auch das Icon die Vordergrundfarbe annimmt und somit auf der neuen Hintergrundfarbe weiterhin sichtbar bleibt.

  2. Hat das Icon eine andere Farbe (als die Vordergrundfarbe), so funktioniert das nicht.

    a) Man muss vermutlich akzeptieren, dass ggf. die Kontraste sich verschlechtern bis hin zu nicht / kaum sichtbar ist.

    b) Wenn eine andere Technik für das Icon eingesetzt wird (SVG wird per <img> oder per CSS-hintergrund geladen, Font-Icon etc) kann sich der Kontrast ebenfalls verschlechtern, bis hin zu nicht sichtbar sein.

  3. Bei Checkboxen / radio-inputs sehe ich immer häufiger, dass der aktivierte Zustand mithilfe eines pseudo-Elments umgesetzt wird, für das eine Farbe definiert wird. Wenn ich eine neue Hintergrundfarbe einstelle, wird diese auch für das pseudo-Elemnet übernommen und der Zustand "aktiviert" ist nicht mehr ermittelbar. Oder auch schon gesehen: Es wird ein Font-Icon eingesetzt.

Fragen:

  1. Kann man eine einzusetzende Technik vorschreiben? Kein Font-Icon, kein pseudo-Element für ausgewählte radio-inputs… etc.
  2. Kann man selbst beim Einsatz von inline-svg vorgeben, dass die inline-svgs dieselbe Farbe haben, wie die Vordergrundfarbe? Vermutlich eindeutig: Nein.
  3. Kann man verlangen, dass ein Icon "immunisiert" wird - damit immer gut sichtbar?

Würden wir in allen Fällen nicht über die minimalen Anforderungen der EN hinausgehen?

MarcHaunschild commented 1 year ago

Vielleicht verstehe ich das nicht richtig, aber das Bild braucht nur eine undurchsichtige Hintergrund-Farbe. Ein schwarzes Hamburger-Icon für eine Website mit weißem Hintergrund bekommt also selber auch einen weißen Hintergrund.

Wenn Nutzer nun einen schwarzen Hintergrund einstellt hat man halt ein kleines weißes Quadrat hinter dem Hamburger Icon. Das ertragen sogar blendempfindliche Menschen. Habe ich 20 Jahre lang so gemacht (bis SVG kam).

Wir schreiben so etwas natürlich nicht vor sondern geben das bei einem fail als mögliche Lösung an (SVG mit currentColor oder festem Hintergrund).

Jeder Seitenbetreiber kann auch eine eigene Lösung verwenden wenn er eine hat - viele lieben es ja alles mögliche per JavaScript abzufangen. Bestimmt kann man auch rausbekommen, welche Farbe der body hat (ob die eigene Farbe also überschrieben ist) und darauf reagieren.

Die jungen Leute mögen es ja "sophisticated". Ich bin eher der Typ "bulletproof".

Checkboxen sind von der Beurteilung eh ausgenommen. Es sei denn jemand will die per checkbox-Hack gestalten. Dann wird man mit einem aha-Erlebnis erkennen, warum es "Hack" genannt wird und nicht best practice. Hier kann man vermutlich dieselbe Methode verwenden indem man im CSS die content-Eigenschaft mit einer url zu einem Bild mit intransparentem Hintergrund füllt. Oder wiederum ein SVG verwendet.

In jedem Fall dürfen diese Dinge nicht per background-Property gesetzt werden (z.B. background-image) - sonst verschwinden sie womöglich ganz.