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 Benutzerdefinierte Einstellungen #190

Open jkphl opened 3 years ago

jkphl commented 3 years ago

Der folgende Satz unter „Nicht voll erfüllt“ erzeugt bei mir Verständnisschwierigkeiten:

Texte haben bei Nutzung eigener Farbeinstellungen nicht genug Kontrast oder verschwinden

Wenn die Website einerseits die Einstellung benutzerdefinierter Farben (und anderer Merkmale) zulässt, dann ist es doch unter Garantie möglich, unmögliche Konstellationen herzukonfigurieren. Inwieweit kann dies dann der Website als Mangel anzulasten sein?

Und: Gehe ich richtig in der Annahme, dass es nicht Bestandteil der Prüfung ist, zu beurteilen, ob z.B. Texte nach Vergrößerung der Schriftgröße weiterhin lesbar sind? Immerhin kann man ja so absurde Schriftgrößen einstellen, dass es kein Layout dieser Welt ohne Verluste verkraften würde …

UPDATE: Ich will ergänzen, dass ich mir auch eine Präzisierung der Anwendbarkeitsbeschreibung wünschen würde:

Dieser Prüfschritt ist anwendbar, wenn eine Dokumentation vorhanden ist und wenn der Teil der Dokumentation, der sich mit Barrierefreiheit und Kompatibilität beschäftigt, auf HTML-Basis integriert ist.

Was ist, wenn die Website keine expliziten Zusatzfunktionalitäten zur Barrierefreiheit bietet? Ist der Prüfschritt dann ebenfalls nicht anwendbar, oder erfüllt?

MarcHaunschild commented 3 years ago

Der folgende Satz unter „Nicht voll erfüllt“ erzeugt bei mir Verständnisschwierigkeiten:

Texte haben bei Nutzung eigener Farbeinstellungen nicht genug Kontrast oder verschwinden

Wenn die Website einerseits die Einstellung benutzerdefinierter Farben (und anderer Merkmale) zulässt, dann ist es doch unter Garantie möglich, unmögliche Konstellationen herzukonfigurieren.

Hier wird getestet, ob sich die Änderungen auf alle Elemente auswirken.

Wenn z.B. heller text auf dunklem Hintergrund gewählt wird und ein Teil der Schriften bleibt schwarz, dann wäre das ein Problem.

jkphl commented 3 years ago

@MarcHaunschild So ist das wohl zu verstehen, genau. Worauf ich hinaus will: Die Formulierung gibt das meines Erachtens nicht eindeutig her und sollte präzisiert werden. Das hätte ich wohl an meinem Issue präziser schreiben sollen. ;) #meta

sweckenmann commented 3 years ago

Den Satz unter „Nicht voll erfüllt“ erzeugt verstehe ich auch nicht ganz:

Texte haben bei Nutzung eigener Farbeinstellungen nicht genug Kontrast oder verschwinden

In den Firefox-Einstellungen gibt es folgende Optionen:

Oben ausgewählte Farben anstatt der Farben der Seite verwenden:

  • Immer: Wählen Sie diese Option, um auf allen Seiten das Verwenden Ihrer Standardfarben zu erzwingen.
  • Nur in Designs mit hohem Kontrast: Mit dieser Option verwendet Firefox die vom Webseiten-Entwickler festgelegten Farben, außer Sie benutzen ein Windows-Design mit hohem Kontrast.
  • Nie: Wählen Sie diese Option, damit Firefox immer die vom Webseiten-Entwickler festgelegten Farben verwendet.

Mit der Einstellung "Immmer" (derzeitige Prüfanleitung) werden die benutzerdefinierten Farben "erzwungen", somit haben die Entwickler:innen ja keinen Einfluss auf die Kontraste. Hier würde nur geprüft, ob die Farben immer übernommen werden (Frage: kann da überhaupt ein Fehler von Seiten der Entwickler:innen vorhanden sein?)

Mit der Einstellung "nie" würde man im Prinzipt dasselbe testen wie im WCAG-Kontrast-Prüfschritt (Vorder- und Hintergrundfarbe definiert). Wenn eines von beiden nicht definiert wurde, greift an dieser Stelle die benutzerdefinierte Farbe, es kann zu unzureichenden Kontrasten mit der von der Webentwickler:in festgelgten Farbe kommen. Wäre das nicht der Grund für dies Szenario:

Wenn z.B. heller text auf dunklem Hintergrund gewählt wird und ein Teil der Schriften bleibt schwarz, dann wäre das ein Problem.

Aber wir prüfen hier etwas anderes? Ob die benutzerdefinierten Farben (erzwungen) werden können?

MarcHaunschild commented 3 years ago

Mit der Einstellung "Immmer" (derzeitige Prüfanleitung) werden die benutzerdefinierten Farben "erzwungen", somit haben die Entwickler:innen ja keinen Einfluss auf die Kontraste. Hier würde nur geprüft, ob die Farben immer übernommen werden (Frage: kann da überhaupt ein Fehler von Seiten der Entwickler:innen vorhanden sein?)

Eigentlich sollte das nicht möglich sein und es macht auch überhaupt keinen Sinn. Darum habe ich das nie versucht. Vielleicht geht es irgendwie, wenn man es drauf anlegt und wilde Hacks anwendet.

Es kann auch sein, dass jemand Systemeinstellungen nutzt. Also dass jemand versucht festzustellen, ob die Seite auf einem Gerät läuft, das den Dark mode aktiviert hat.

Hierbei bin ich tatsächlich auf Probleme gestoßen. Wenn der Autor einer Seite einerseits einen Hintergrund abhängig von Systemeinstellungen verwendet (z.B. schwarz) und andererseits für eine Schrift schlicht "schwarz" angibt, kann das zum Problem werden.

Auch Icons können hier Probleme machen. Man kann einem SVG-Icon sagen, dass es dieselbe Farbe haben soll wie die Schrift im selben Container. Wenn man nicht aufpasst, wo man die Schriftfarbe festlegt, kann es sein, dass beides in der normalen Darstellung identisch aussieht, bei angepassten Farben aber nicht mehr (hierfür gibt es glaube ich gar keinen Prüfschritt mehr? - Früher wurde das mal getestet).

Allerdings weiß ich nicht, ob die hier angegebene Prüfanleitung in der Lage ist, diese Fälle zu identifizieren.

Meiner Meinung nach könnte man diesen Prüfschritt schon so verstehen, dass auch die Berücksichtigung eine Art "Kontrastmodus" ist, auch wenn ich dafür nicht extra einen Button drücken muss. Idealerweise gibt es auch (am Anfang) auf der Seite einen Button, mit dem man selber festlegen kann, ob man das als Benutzer ausschalten möchte. Ich mache das so, aber das ist dann schon best practice und nicht mehr einzuforderndes SC. Nur sieht man dann tatsächlich einen Button, wodurch klar wird, dass es eigentlich genau dasselbe ist vom Prinzip her wie die a11y-Features, die Seiten heute etwas inflationär und meist wenig hilfreich so mitbringen.

johannesFischer84 commented 3 years ago

Hier wird getestet, ob sich die Änderungen auf alle Elemente auswirken. Wenn z.B. heller text auf dunklem Hintergrund gewählt wird und ein Teil der Schriften bleibt schwarz, dann wäre das ein Problem.

Genauso verstehe ich es auch. Der Zusatz "nicht genug Kontrast" bei "nicht voll erfüllt" müsste entfernt werden.

Zu den Icons habe ich selbst noch nicht viel ausprobiert. Mir ist allerdings gerade aufgefallen, dass auch der Firefox-Browser (Version 86.0) nicht alles perfekt übernimmt. Bei einem button-Element wird eine vom Nutzer eingestellte Hintergrundfarbe nämlich nicht übernommen, auch bei der Option "Immer" in den Farbeinstellungen nicht. Das heißt, eine andere Hintergrundfarbe erscheint schon, aber das ist wohl die Default-Farbe von Firefox, wenn keine CSS-Anweisung definiert ist und eben auch keine nutzereigene Farbe definiert wäre.

sweckenmann commented 3 years ago

@johannesFischer84 Prüfen wir dann nicht aber das, was wir bei 9.1.4.3a prüfen? D.h. die Prüfanleitung stimmt dann nicht? Oder warum sollte bei der Einstellung "immer" dieses Problem auftauchen?

johannesFischer84 commented 3 years ago

@sweckenmann Sonja, ich meinte das in der Hinsicht, dass wir in 11.7 den Firefox-Browser zur Prüfung empfehlen, weil beispielsweise beim Chrome überhaupt keine Nutzereinstellungen bei Seiten übernommen werden. Aus meiner Sicht dürfen solche Fehler des Browsers nicht negativ bewertet werden, die Prüfung unter 11.7 wäre für solche Fälle automatisch erfüllt (sofern nicht jemand einen anderen Browser entdeckt, der das doch richtig macht). Die Prüfanleitung stimmt bis auf das Detail mit dem button-Element. Gern kann das jemand anderes auch mal ausprobieren, falls ich nur etwas übersehen habe (einfach ein Test-HTML mit einem button-Element erstellen).

sweckenmann commented 3 years ago

@johannesFischer84 Ja, das habe ich auch so verstanden. Ich bezog mich auf die Aussage:

Hier wird getestet, ob sich die Änderungen auf alle Elemente auswirken. Wenn z.B. heller text auf dunklem Hintergrund gewählt wird und ein Teil der Schriften bleibt schwarz, dann wäre das ein Problem.

Welche Ursache hat ein solches Problem bei der Einstellung "immer" (das habe ich nicht verstanden)? Ist das nicht ein typisches Problem, wenn entweder Vorder- oder Hintergrundfarbe nicht definiert ist?

johannesFischer84 commented 3 years ago

Welche Ursache hat ein solches Problem bei der Einstellung "immer" (das habe ich nicht verstanden)? Ist das nicht ein typisches Problem, wenn entweder Vorder- oder Hintergrundfarbe nicht definiert ist?

Du hast oben geschrieben, dass man die Einstellung "immer" nutzen muss, um das Übernehmen der Farbeinstellung zu erzwingen, was aus meiner Sicht auch die einzige praktikable Möglichkeit zur Prüfung ist.

Das Problem der Nicht-Übernahme der Hintergrundfarbe beim button hängt nicht mit den CSS-Angaben des Seitenbetreibers von Vorder-/Hintergrundfarbe übergeordnet (body) zusammen. Du kannst es direkt hier bei der Github-Seite mit dem Comment-Schalte ausprobieren. Und ich hatte auch ein Test-HTML ohne jegliche CSS-Anweisungen genommen.

sweckenmann commented 3 years ago

@johannesFischer84 Wir missverstehen uns. Ich habe mich wahrscheinlich nicht richtig ausgedrückt. Klammern wir die button-Geschichte mal aus (Sonderfall). Auf die bezieht sich meine Frage nicht.

Ich habe euch so verstanden, dass man grundsätzlich bei dem Prüfschritt prüfen soll, dass so ein Problem wie "heller text auf dunklem Hintergrund wird gewählt und ein Teil der Schriften bleibt schwarz" aufgedeckt wird. Richtig? Und hier ist mir die Ursache nicht klar, wenn die Einstellung "immer" gewählt wird, weil dann doch die Übernahme "erzwungen" wird. Danke nochmal für deine Geduld ;).

johannesFischer84 commented 3 years ago

Ich habe euch so verstanden, dass man grundsätzlich bei dem Prüfschritt prüfen soll, dass so ein Problem wie "heller text auf dunklem Hintergrund wird gewählt und ein Teil der Schriften bleibt schwarz" aufgedeckt wird. Richtig?

ja, da stimme ich dir zu.

Und hier ist mir die Ursache nicht klar, wenn die Einstellung "immer" gewählt wird, weil dann doch die Übernahme "erzwungen" wird.

Die Ursache im button-Beispiel scheint mir ein Fehler/Bug des Firefox-Browsers zu sein. Der Firefox erzwingt hier die Übernahme nicht, selbst wenn man ein HTML-Dokument ganz ohne CSS oder JavaScript nimmt. Ganz allgemein hat Chrome aber mehr Fehler, denn dort werden Nutzereinstellungen allgemein nicht übernommen für eine Webseite.

Danke nochmal für deine Geduld ;).

Kein Problem :-)

sweckenmann commented 3 years ago

Die Ursache im button-Beispiel scheint mir ein Fehler/Bug des Firefox-Browsers zu sein. Der Firefox erzwingt hier die Übernahme nicht, selbst wenn man ein HTML-Dokument ganz ohne CSS oder JavaScript nimmt. Ganz allgemein hat Chrome aber mehr Fehler, denn dort werden Nutzereinstellungen allgemein nicht übernommen für eine Webseite.

Verstanden, wir prüfen nicht den Browser, also bewerten wir dieses Problem nicht. Vergessen wir mal das button-Beispiel. Kann denn überhaupt ein Problem auftauchen, das man Entwickler:innen anlasten kann und wenn ja, welche Ursache hätte das? Letzte Rückfrage... verprochen 😅

johannesFischer84 commented 3 years ago

Kann denn überhaupt ein Problem auftauchen, das man Entwickler:innen anlasten kann und wenn ja, welche Ursache hätte das?

Da kannst du tatsächlich wohl nicht mehr rückfragen (du darfst aber gern), denn das habe ich mich auch schon gefragt und bin bisher nicht zu einem richtigen Ergebnis gekommen. Meine Gedanken: Vielleicht könnte man das Erzwingen des Browsers über Skripte blockieren oder es geht doch mal etwas schief durch falsche Angabe der Vorder-/Hintergrundfarbe im CSS.

Weil ich mich diese Dinge gefragt habe, habe ich vorhin mal an einer Seite rumprobiert und bin so auf den Fehler mit button gestoßen (der Entwickler hatte keinen Fehler gemacht). Vielleicht trifft man mal auf einen Fall, wo der Entwickler etwas anders machen müsste, aber im Moment kenne ich noch kein Beispiel. Vielleicht jemand anderes?

sweckenmann commented 3 years ago

@johannesFischer84 Danke. Das beruhigt mich jetzt doch sehr, dass ich mit meinen Überlegungen nicht ganz falsch liege... ;)

MarcHaunschild commented 3 years ago

Eine Bitte/ Frage.

könntest du die problematische Seite mal schicken, @johannesFischer84 - Gerne auch per Mail, wenn du die nicht öffentlich hier posten möchtest.

Würde mir das auch gerne mal anschauen und auch mal mit anderen Seiten vergleichen.

johannesFischer84 commented 3 years ago

@MarcHaunschild Marc, fang gleich mal hier mit der Github-Seite an, beispielsweise mit dem "Comment"-button am Ende des Editors, wo man Kommentare schreibt. Daran müsstest du es bereits nachvollziehen können. Ebenso bei den Registerkarten-Schaltern "Write"/"Preview" davor. Ändere bei den Firefox-Farb-Einstellungen die Standard-Option "Nur in Designs mit hohem Kontrast" auf "Immer". Dann wird die Hintergrundfarbe Weiß (Standardwerte Firefox) nicht auf Write, Preview, Comment angewandt bzw. es wird z. B. für "Comment" zwar nicht mehr das Grün verwendet, aber ein Grau-Ton. Es sind alles button-Elemente. Es funktioniert ebenso, wenn du ein HTML-Test-Dokument ohne jegliches CSS/JavaScript z. B. nur mit button erstellst und damit probierst.

sweckenmann commented 3 years ago

Ich habe jetzt mal einen Entwurf gmacht (https://github.com/BIK-BITV/BIK-Web-Test/pull/195):

Zum Thema Schriftgröße:

Zum Thmea benutzerdefinierte Einstellungen: Wie ich bereits erläutert habe, gibt es zwei Einstellungsmöglichkeiten im Browser :

Da wir die Variante "Nie" im Prüfschritt 9.1.4.3 Kontraste von Texte ausreichen bereits prüfen (und dort das Problem "schwarze Schrift auf dunklem Grund), würden wir hier mit der Option "immer" prüfen.

Nach meinem letzten Test scheinen mir folgende Probleme möglich:

Meinungen?

@Jkphal - kann es sein, dass du hier Prüfschritte durcheinandergebracht hast? 11.7 ist immer anwendbar.

UPDATE: Ich will ergänzen, dass ich mir auch eine Präzisierung der Anwendbarkeitsbeschreibung wünschen würde:

MarcHaunschild commented 3 years ago

@MarcHaunschild Marc, fang gleich mal hier mit der Github-Seite an, beispielsweise mit dem "Comment"-button am Ende des Editors, wo man Kommentare schreibt. Daran müsstest du es bereits nachvollziehen können.

OK, jetzt verstehe ich, was du meinst.- Sorry für die späte Antwort, hatte das vorher übersehen. Ja, das ist ein Problem. Auch zum Beispiel in Drop-Down-Menüs die Hervorhebung für das aktuelle Element (kann man hier bei den drei Punkten ausprobieren. Ich habe als Hintergrund einen beige-Ton, weil mir das weiß zu gfell ist und das sieht fast aus wie das Standard-Grau des FF. Insofern finde ich das Verhalten von FF auch problematisch und würde es auch als Bug ansehen.

Habe übrigens auf MacOSX (OS und FF aktuell) getestet.

sweckenmann commented 3 years ago

@johannesFischer84 und @MarcHaunschild - Wenn das ein Bug ist, müsste man wohl noch Ausnahmen definieren und im Prüfschritt festhalten..

MarcHaunschild commented 3 years ago

Wenn das ein Bug ist, müsste man wohl noch Ausnahmen definieren und im Prüfschritt festhalten..

Gibt es denn ein Problem? Man müsste erst mal sehen, wo die Probleme auftauchen und welche. Die hellgrauen Button. Der Kontrast auf den Button reicht ja zum Bestehen der Kontrast-Prüfschritte (wegen der Beschriftung). Die eigenen Farben wirken sich hier nie aus, es wird immer nur die (zugängliche) Standard-Variante dargestellt. Mit den Dropdowns hier ist es wohl eher ein Vorschlag, der grau hinterlegt wurde. warum weiß ich gar nicht (ist beim ändern des eigenen Beitrages sogar mehr als nur ein Eintrag. Ich verstehe nicht einmal, was da anders dargestellt wird. Insofern ist das keine (für mich erkennbare) Information, die durch ausreichenden Kontrast statt Farbe dargestellt werden müsste...

Was ich sagen wollte: wenn wir hier prüfen, ob bei der Verwendung eigener Farben Probleme im Sinne der WCAG auftauchen und das ist nicht der Fall (auch wenn es etwas komisch aussehen mag), brauchen wir keine Ausnahme?!?

johannesFischer84 commented 3 years ago

@sweckenmann Sonja, im Bereich Hinweise der Prüfanleitung wird ja darauf hingewiesen, dass der Firefox-Browser zur Prüfung verwendet werden soll, weil Einstellungen in anderen Browsern nicht vorhanden sind bzw. unwirksam sind. In diesem Fall übernimmt der Firefox-Browser für button die vom Nutzer gewählte Hintergrundfarbe nicht bzw. setzt eine eigene Farbe. Dies könnte man ggf. in den Hinweisen erwähnen. Wobei ich nicht sicher bin, ob das dann vollständig ist. @MarcHaunschild Marc, das Problem ist eher die Nicht-Übernahme der vom Nutzer gewählten Farbe, der Kontrast ist hier völlig irrelevant. Da es aber am Browser liegt, nicht am Quellcode der Webseite, handelt es sich nicht um einen Fehler im Sinne des Prüfschritts.

johannesFischer84 commented 3 years ago

@sweckenmann Zu deinen Entwurfs-Fragen hier meine Anmerkungen:

Frage: Wäre es sinnvoll, wenn wir eine Schriftgröße festlegen, mit der wir testen? @jkphl s Hinweis finde ich schlüssig.

Ich weiß nicht, ob man unbedingt bestimmte Schriftgrößen vorgeben muss. Sofern die Seite keine festen Höhen/Breiten für Inhaltskomponenten definiert, sollte unabhängig vom Layout doch eine Lesbarkeit gegeben sein, oder? Allerdings fällt mir gerade ein, dass der Browser-Zoom auch eine Einstellung der Schriftgröße darstellen könnte. Es stellt sich die Frage, ob der Punkt zur Schriftgröße vielleicht schon erfüllt wäre, wenn die WCAG-Kriterien 1.4.4/1.4.10 erfüllt werden.

Ich verstehe den Prüfschritt so, dass wir (pragmatisch) nur den Fließtext prüfen (und ob es hier nicht zu Problemen / Überlagerungen kommt)?

Sollte die Schriftgröße nicht in Menüs übernommen werden, wäre das genauso ein Fehler.

Da wir die Variante "Nie" im Prüfschritt 9.1.4.3 Kontraste von Texte ausreichen bereits prüfen (und dort das Problem "schwarze Schrift auf dunklem Grund), würden wir hier mit der Option "immer" prüfen.

Die Standardauswahl bei Farben in Firefox ist eigentlich "Nur in Designs mit hohem Kontrast". Diese ist jedoch gleichbedeutend mit "Nie", sofern im Betriebssystem kein solches Design ausgewählt wurde. In 11.7 macht nur die Option "Immer" Sinn, damit eben Nutzereinstellungen übernommen werden.

Ifnormationstragende Icons sind nicht mehr sichtbar

Ja, würde ich als Problem sehen. Beispielsweise auf der Ruhrfutur-Seite ist das klickbare Symbol des Menü-Schalters nicht mehr sichtbar.

Texte auf Fotos, die vorher einen ausreichenden Kontrast hatten, haben es nun nicht mehr (hier ein Positiv-Beispiel, wo alles ok wäre: Bei geänderten Farbeinstellungen hat der Text einen Hintergrund auf dem Bild: https://www.gutgefragt.hamburg/startseite)

Ja, das liegt bei Fehler vermutlich an Hintergrundgrafiken.

Schrift von Logos ist nicht mehr lesbar (aufgrund eines transparenten Hintergrunds). Frage: Sollte man das negativ bewerten? Beispiel hier (Partner, Städtelogos): https://www.ruhrfutur.de/fruehkindliche-bildung/kinderstuben-nach-dem-dortmunder-modell

Kommt vielleicht auf die Wichtigkeit der Logos an, aber tendenziell würde ich sagen, ja. Fehler sollten wieder an Hintergrundgrafiken liegen. Bei der Ruhrfutur-Seite im Bereich Partner sind die Logos beim mir bei geänderten Farben übrigens noch voll sichtbar und lesbar.

Frage: Sollte man die Nicht-Anpassbarkeit von Schriftgrafiken hier zusätzlich zu dem bereits bestehenden Prüfschritt negativ bewerten? Ich denke, eher nicht.

Ich sehe auch keine Notwendigkeit dazu.

sweckenmann commented 3 years ago

@johannesFischer84

im Bereich Hinweise der Prüfanleitung wird ja darauf hingewiesen, dass der Firefox-Browser zur Prüfung verwendet werden soll, weil Einstellungen in anderen Browsern nicht vorhanden sind bzw. unwirksam sind. In diesem Fall übernimmt Dies könnte man ggf. in den Hinweisen erwähnen. Wobei ich nicht sicher bin, ob das dann vollständig ist.

Ja, man könnte den Satz "Der Firefox-Browser für button die vom Nutzer gewählte Hintergrundfarbe nicht bzw. setzt eine eigene Farbe." ergänzen. Wenn uns noch mehr solcher Fälle auffallen, könnt man das zusätzlich dokumentieren.

Zur Schriftgrößeneinstellung: Ja an den Browserzoom (Nur Text zoomen) hab ich auch schon gedacht, aber das ist nicht ganz die gleiche Funktionalität, man vergrößert je aufgerufenen Webauftritt? Ob man eine maximale Schriftgröße festelegen müsste... hätte ich gern mal eine Meinung von den Umsetzenden... (siehe @jkphl oben "absurde Schriftgrößen, die kein Layout dieser Welt verkraften"). Zumal es den Browser-Zoom gibt?

Sollte die Schriftgröße nicht in Menüs übernommen werden, wäre das genauso ein Fehler.

Hm, und was ist mit Buttons (@detlevhfischer hatte mir von einer Diskussion in der Working Group berichtet) und Überschriften?

Texte auf Fotos, die vorher einen ausreichenden Kontrast hatten, haben es nun nicht mehr (hier ein Positiv-Beispiel, wo alles ok wäre: Bei geänderten Farbeinstellungen hat der Text einen Hintergrund auf dem Bild: https://www.gutgefragt.hamburg/startseite)

Ja, das liegt bei Fehler vermutlich an Hintergrundgrafiken.

Ich glaube es geht eher darum, ob die Schrift auf dem Bild einen Hintergrund hat, der die "eingestellte Farbe" übernimmt? Bei dem Beispiel bezog ich mich auf die Karussell-Teaser.

Bei den Partner-Logos ist die Schrift des Logos zu sehen, aber der Hintergrund ist die Farbe, die ich eingestellt habe. D.h. die Schrift kann sehr schwer lesbar werden (kann man auch beim RuhrFutur-Logo sehen).

johannesFischer84 commented 3 years ago

Zur Schriftgrößeneinstellung: Ja an den Browserzoom (Nur Text zoomen) hab ich auch schon gedacht, aber das ist nicht ganz die gleiche Funktionalität, man vergrößert je aufgerufenen Webauftritt?

Warum den Nur-Text-Zoom? Der reine Browser-Zoom vergrößert (und verkleinert) auch den Text, um den es auch in WCAG 1.4.4 geht. Was du mit "man vergrößert je aufgerufenen Webauftritt" meinst, verstehe ich nicht.

Sollte die Schriftgröße nicht in Menüs übernommen werden, wäre das genauso ein Fehler.

Hm, und was ist mit Buttons (@detlevhfischer hatte mir von einer Diskussion in der Working Group berichtet) und Überschriften?

Ich würde generell keine wichtigen Inhalte für die Schriftgröße ausschließen wollen, das mit den Menüs sollte nur ein Beispiel sein, was ich vergessen hatte, dazuzusagen.

Texte auf Fotos, die vorher einen ausreichenden Kontrast hatten, haben es nun nicht mehr (hier ein Positiv-Beispiel, wo alles ok wäre: Bei geänderten Farbeinstellungen hat der Text einen Hintergrund auf dem Bild: https://www.gutgefragt.hamburg/startseite) Ich glaube es geht eher darum, ob die Schrift auf dem Bild einen Hintergrund hat, der die "eingestellte Farbe" übernimmt? Bei dem Beispiel bezog ich mich auf die Karussell-Teaser.

Den Karussell-Teaser hab ich auch probiert und war verwundert, dass er tatsächlich die eingestellte Hintergrundfarbe übernimmt, obwohl er in der Normalansicht das Foto als Hintergrund hat, nicht eine einfarbige Fläche. Ich dachte, der Grund wäre, dass es sich bei dem Karussell-Foto nicht um eine Hintergrundgrafik handelt. Aber so sicher bin ich mir auch nicht.

Bei den Partner-Logos ist die Schrift des Logos zu sehen, aber der Hintergrund ist die Farbe, die ich eingestellt habe. D.h. die Schrift kann sehr schwer lesbar werden (kann man auch beim RuhrFutur-Logo sehen).

Schlechte Lesbarkeit eines Logos aufgrund der vom Nutzer eingestellten Farbkombination würde ich nicht fehlerhaft werten. Logos sind in der Regel bei der Gestaltung von Kontrast oder Schriftgrafik u. ä. sowieso ausgenommen. Vielleicht könnte man empfehlen, keinen transparenten Hintergrund für Logos zu liefern.

sweckenmann commented 3 years ago

Schlechte Lesbarkeit eines Logos aufgrund der vom Nutzer eingestellten Farbkombination würde ich nicht fehlerhaft werten. Logos sind in der Regel bei der Gestaltung von Kontrast oder Schriftgrafik u. ä. sowieso ausgenommen. Vielleicht könnte man empfehlen, keinen transparenten Hintergrund für Logos zu liefern.

Genau darum ging es mir, ob man sowas fordern soll (keinen transparenten Hintergrund für Logos), dann würde sowas wie bei RuhrFutur nicht passieren (glaube ich).

Ok, dann Browser-Zoom, dachte es ginge "nur" um Schriftgröße. Daher hatte ich an die Funktion gedacht. Finde den Browser-Zoom eingentlich auch sinnvoller.

pp-ernst commented 3 years ago

Den Fall, dass der Menü-Button verschwindet, habe ich bei meinem aktuellen Test auch. In der Prüfschrittanleitung wird unter „nicht voll erfüllt“ nur von Texten gesprochen. Unter „2. Prüfung“ wird nur gefordert, dass sich die Änderungen von Schriftgröße, -art und Farben auswirkt. Konsens aus der obigen Diskussion scheint mir zu sein, dass auch geprüft und negativ bewertet wird, wenn wichtige Inhalte (z.B. Bedienelemente) verschwinden. So haben wir ja auch schon früher getestet, als die benutzerdefinierten Farben noch ein Prüfschritt waren. Ich finde, die Prüfung, ob wichtige Inhalte verschwinden, muss in die Prüfschrittbeschreibung aufgenommen werden.

MarcHaunschild commented 3 years ago

Also ich bin hier ja der Neue und weiß immer nicht, ob ich mal einfach so fragen soll, ob ihr nicht alle "auf dem Holzweg" seid, aber ich werde den Eindruck nicht los, dass es sich hier überhaupt um zusätzliche Anforderungen handelt, die nicht in schon in diversen 9er Prüfschritten abgehandelt wurden. Ich meine 11.7 ist nicht aus dem Web-Abschnitt, sondern aus dem Software-Abschnitt. Ich habe den Eindruck, dass mit 11.7 nur geprüft werden soll, ob eine App noch so funktioniert und lesbar und bedienbar ist, wie eine Webseite, die die Prüfschritte zu Zoom, Reflow, Text-Abständen usw besteht. Da man in Apps selten so weitreichende Einstellungsmöglichkeiten hat wie in Browsern, verlangt meiner Interpretation nach 11.7 nur, ob alles noch funktioniert, wenn man die Einstellungsmöglichkeiten nutzt, die die App anbietet, bzw. wenn Sie Systememeinstellungen respektiert (wie den DarkMode). Ich sehe hier ehrlich gesagt nicht, dass sich aus 11.7 zusätzliche Anforderungen ergeben, die nicht in den WCAG-SCs bereits enthalten sind. Ich glaube da deutet ihr etwas rein, was nicht gemeint ist...?!?

johannesFischer84 commented 3 years ago

@MarcHaunschild

Ich sehe hier ehrlich gesagt nicht, dass sich aus 11.7 zusätzliche Anforderungen ergeben, die nicht in den WCAG-SCs bereits enthalten sind. Ich glaube da deutet ihr etwas rein, was nicht gemeint ist...?!?

In der Version 3.1.1 oder auch der neuen 3.2.1 der EN 301 549 gibt es die NOTE 2, die sagt:

For web content, the underlying platform is the user agent.

Im Zusammenhang mit dem Begriff "user preferences" aus dem Text der Anforderung 11.7 muss man also explizit die Einstellmöglichkeiten des Browsers und deren Auswirkungen auf die Webseite beachten. Wie du gesagt hast, muss eine App die Einstellungen des Betriebssystems übernehmen. Eine Webseite muss dagegen die Einstellungen des Browsers übernehmen. Nach meinem Verständnis muss natürlich kein Mindestkontrast erfüllt werden, wenn ein Nutzer komische Farben einstellt. Aber zumindest sollten nicht wichtige Inhalte plötzlich verschwinden.

MarcHaunschild commented 3 years ago

@MarcHaunschild

Im Zusammenhang mit dem Begriff "user preferences" aus dem Text der Anforderung 11.7 muss man also explizit die Einstellmöglichkeiten des Browsers und deren Auswirkungen auf die Webseite beachten.

Ach verflixt - wir reden schon so lange über den Prüfschritt, dass ich das völlig aus den Augen verloren habe. Sorry, ist natürlich richtig, dass man das so prüft...

mayerhh commented 3 years ago

For web content, the underlying platform is the user agent.

Und wo steht welcher user agent berücksichtigt werden soll?

Angesichts des ständig sinkenden Marktanteils von Firefox (10 - 20%) könnte man sich auch auf die Möglichkeiten der chromebasierten Browser konzentrieren. Ich sehe jedenfalls nicht warum hier zwingend der Firefox als Maßstab genommen werden muss.

johannesFischer84 commented 3 years ago

Angesichts des ständig sinkenden Marktanteils von Firefox (10 - 20%) könnte man sich auch auf die Möglichkeiten der chromebasierten Browser konzentrieren. Ich sehe jedenfalls nicht warum hier zwingend der Firefox als Maßstab genommen werden muss.

Ich habe in Chrome die Einstellungen nochmal etwas ausprobiert. Schriftart und Schriftgröße werden doch auf Webseiten angewandt, allerdings nur wenn die Seite selbst keine festen Pixelangaben für die Schriftgröße oder fest bezeichnete Schriftarten verwendet. Eine Checkbox wie in Firefox, dass Seiten ihre eigenen Werte erlaubt bzw. nicht erlaubt werden, gibt es bei Chrome nicht. Die Frage ist, ob deswegen nun Webentwicklern verboten werden müsste, Pixelangaben oder feste Schriftarten zu machen. Ich halte das für streng, bin mir aber nicht sicher. Für die Schriftgröße gibt es aber theoretisch weiterhin den Browser-Gesamt-Zoom.

sweckenmann commented 3 years ago

Hat jemand eine Idee, weshalb die Schriftgröße der FF-Einstellung hier nicht übernommen wird? https://www.zusammengegencorona.de/

johannesFischer84 commented 3 years ago

Hat jemand eine Idee, weshalb die Schriftgröße der FF-Einstellung hier nicht übernommen wird?

Ich vermute, weil im html-Element die Eigenschaft font-size:16px angegeben ist. Da wird die Schriftgröße wohl nur in Firefox übernommen, wenn eine Mindestschriftgröße in den Einstellungen gewählt wird.

sweckenmann commented 3 years ago

@johannesFischer84 Ja, wenn ich das in den DevTools rauslösche funktioniert es! Konnte bislang jede Schriftgröße einstellen, nichts wurde übernommen. Danke!

MarcHaunschild commented 3 years ago

Bei meinem aktuellen Test habe ich festgestellt, dass auch die Farbe nicht übernommen wird (Schriftgröße schon), wenn eine Hintergrundfarbe für Body angegeben ist. Scheint so in FF zu sein, dass Nutzerangaben definierte Werte ggfs. nicht überschreiben. Dasselbe galt für die Schriftart. Ich frage mich auch gerade, was man als Entwickler dagegen tun kann (denke mal nichts). Das macht es echt schwierig diesen Prüfschritt sinnvoll zu bewerten... Vielleicht ist das auch ein Grund, warum andere Browser es nicht anbieten. Schließlich kann man damit auch viel kaputt machen. Auch bei den Barrierefreiheitstools, die Webseiten manchmal mitbringen, werden meist nicht alle Texte/Hintergründe wie festgelegt eingefärbt...

mayerhh commented 3 years ago

Bei dem Problem mit der Schriftgröße läuft es auf die Frage hinaus, die Johannes weiter oben schon gestellt hat. Kann man px Angaben negativ bewerten?

Die Probleme treten hier wohl auf, weil die rem-Einheiten auf der Beispielseite die font-size Angaben aus dem Root-Element erben. Statt 16px (wie dort verwendet) wird oft empfohlen 62.5% zu nehmen. Damit kann man den Schriftgrad in Chrome und Firefox ändern.

MarcHaunschild commented 3 years ago

Bei dem Problem mit der Schriftgröße läuft es auf die Frage hinaus, die Johannes weiter oben schon gestellt hat. Kann man px Angaben negativ bewerten?

Die Probleme treten hier wohl auf, weil die rem-Einheiten auf der Beispielseite die font-size Angaben aus dem Root-Element erben. Statt 16px (wie dort verwendet) wird oft empfohlen 62.5% zu nehmen. Damit kann man den Schriftgrad in Chrome und Firefox ändern.

Interessant. Ich hätte gedacht, dass die Browser die Schriftgröße irgendwo mal auf 16px setzen. Dann dürfte 62.5% eigentlich nicht helfen, weil das dann eben 10px sein müssten.

Ich bin ja überhaupt kein Freund davon, die Standard-Schriftgröße zu ändern, aber das kann ja jeder Entwickler machen, wie er mag.

Die besten Erfahrungen habe ich gemacht mit html {font-size: 1em;} - eine Empfehlung aus der html5boilerplate.