11.1.4.3 / 11.1.4.11 Kontrastmodus des Betriebssystems akzeptieren

[johannesFischer84]

Ich möchte anregen, dass in den Kontrastprüfschritten für Apps (WCAG 1.4.3 und 1.4.11) zur Konformität auch die Einstellung des Kontrastmodus (oder Hell-/Dunkel-Modus) akzeptiert wird. In der Regel akzeptieren wir Konformität mit entsprechenden Einstellungen des Betriebssystems, z. B. in EN 11.7, bei der Zoom-Vergrößerung oder vielleicht auch bei der Pausierung von Animationen. Zudem haben besonders unter iOS native Bedienelemente in der Standard-Einstellung zu geringen Kontrast, was sich in der hohe-Kontrast-Einstellung aber anders darstellen kann.

Wenn wir es akzeptieren, müsste es in die Prüfanleitungen aufgenommen werden.

[detlevhfischer]

@johannesFischer84 Hieße das für Dich, grundsätzlich mit dieser Vorauswahl zu testen?
Ein Argument dafür ist, dass sehbehinderte Menschen dies ja grundsätzlich einstellen können.
Das Gegenargument ist, dass es viel Nutzer (?) ggf nicht wissen ,gerade die Älteren, die zunehmend Probleme bekommen, aber teczhnisch nicht versiert sind.
Mit der Grundeinstellung wäre dafür gesporgt, dass native iOS Switches dann automatisch ausreichen würden. Anderenfalls zu verlangen, dass Entwickler nicht native Bedienelemente nutzen sollen, da diese im Default-Zustand die Kontrastanforderung nicht erfüllen, käme mir fasch vor.

[johannesFischer84]

@detlevhfischer Detlev, ich stimme dir zu. Ich würde schon zunächst mit dem Standardmodus testen. Aber wenn man auf Fehler stößt, kann man den Hohen-Kontrast-Modus bzw. in Kombination den Wechsel von Hell-Modus und Dunkel-Modus ausprobieren. Wenn es Fehler im Standard-Modus gibt, die über die Einstellungen mit anderen Modus behoben werden können, würde ich den Betreiber/Entwickler auch immer darauf hinweisen, dass es noch nicht perfekt ist, eben weil nicht alle Nutzenden über die Einstellungen Bescheid wissen (Info wäre über eine App-Hilfe-Funktion möglich). Es könnte aber noch als konform akzeptiert werden.
Ich denke auch, dass Entwickler soweit irgendwie möglich auf native Standard-Elemente der Umgebung setzen können sollten.

[mitchellevan]

Es gibt seit langem Präzedenzfälle, dass der Kontrast nur mit Standardeinstellungen getestet werden sollte. Aus eigener Erfahrung weiß ich, dass Level Access und TPGi auf diese Weise testen. Weitere Beispiele:

• Testing Color Contrast in Mobile Apps (Deque Blog): "Even though it’s great to support these settings in your apps, you cannot use them as a way to meet WCAG criteria."
• Beim Testen von 1.4.3 und 1.4.11 ändert die Testmethodik von IBM die Systemeinstellungen nicht.

Wenn sich diese Präzedenzfälle geirrt hätten, würde ich gerne bessere vorschlagen. Die Präzedenzfälle sind jedoch gut für die Benutzer und nicht unlogisch.

...dass es viel Nutzer (?) ggf nicht wissen ,gerade die Älteren, die zunehmend Probleme bekommen, aber teczhnisch nicht versiert sind.

[detlevhfischer]

@mitchellevan Danke erstmal für die Hinweise zur Prüfpraxis von IBM, LevelAccess und Deque.

Es gibt folgenden Passus in 1.4.11 der hier ggf in Betracht kommt:

except for inactive components or where the appearance of the component is determined by the user agent and not modified by the author;

Die Entsprechung des user agent wäre für native Apps wohl das jeweilige mobile Betriebssystem?

[detlevhfischer]

Ich habe die Ausnahme für native controls wie iOS switches vorerst rausgenommen und zur Klärung ein Issue bei der WCAG2ICT Task Force angelegt: w3c/wcag2ict#94

[detlevhfischer]

Es gab dazu schon ein älteres Issue w3c/wcag2ict#82

Ich habe daraufhin den Prüfschritt zu 11.1.4.11 vorläufig angepasst und nochmal in einem Kommentar um Bestätigung dieser Position durch die WCAG2ICT task force gebeten.