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 - Konkretisierung der Prüfschritt-Beschreibung #309

Closed sweckenmann closed 1 year ago

sweckenmann commented 1 year ago

Im Folgenden der Input von @pp-ernst, den ich für ihn hinsichtlich einer Konkretisierung der Prüfschritt-Beschreibung hier zur Diskussion stellen darf. Ich werde im Anschluss ein PR erstellen.

1. Schriftgröße

  1. nur bewerten, ob sich die Schriftgröße verändert.
  2. beim Testen auch die Mindestschriftgröße berücksichtigen.
  3. Hinweis von Sepp: Es sollte definiert werden in welchen Browsern getestet wird. Eine entsprechende Funktion gibt´s ja in CH/FF und Edge.

Erläuterung: da keine Angaben in der Anforderung stehen, welche Schriftgröße gefordert wird und es auch noch die Zoom- und Textvergrößerung-Funktion der Browser gibt, kann man keine Schriftgröße vorschreiben. Irgendwann zerreißt es jedes Layout.

2. Schriftart

  1. wenn sich die Schriftart nicht ändert, negativ bewerten.

3. Farben

  1. wenn informationstragende Inhalte verschwinden, zum Beispiel weil sie als CSS-Hintergrundgrafiken eingebunden sind, negativ bewerten. Zu informationstragenden Inhalten würde ich alles außer dekorative und redundante Elemente rechnen. Redundante Elemente sind zum Beispiel ein Briefsymbol gemeinsam mit dem Text „Kontakt“ in einem Bedienelement.
  2. wenn Texte Vorder- oder Hintergrundfarbe nicht ändern, negativ bewerten.
  3. wie wir das Verhalten bei Buttons bewerten sollen, kann ich nicht sagen. Das Verhalten je nach Art der Grafik oder anderer Faktoren ist zu undefiniert, komplex oder nicht nachvollziehbar. Im Zweifelsfall ignorieren und nicht negativ bewerten.
  4. wenn Grafiken aufgrund von einem transparenten Hintergrund (zum Beispiel Logos) je nach gewählter Hintergrundfarbe nur noch schlecht sichtbar sind (Kontrast unter 3,0:1) ist die Lage auch komplex. Manche Grafiken übernehmen die benutzerdefinierte Vordergrundfarbe, manche nicht. Wenn man das negativ bewertet, würde man die Art der Grafiken, die die Vordergrundfarbe nicht übernehmen, per se als nicht barrierefrei ausschließen. Auf der anderen Seite ist es für Nutzer, die einen dunklen Hintergrund benötigen, eine große Barriere, wenn eine schwarze Schrift auf schwarzem Hintergrund dargestellt wird. Ich kann mich für keine Variante entscheiden.
sweckenmann commented 1 year ago

Bzgl. Farben sehe ich es ähnlich wie @johannesFischer84 siehe #305

Neben der Übernahme der Einstellungen bin ich dafür, dass man bei nicht mehr bedienbaren, nicht mehr lesbaren, nicht mehr wahrnehmbaren wichtigen Elementen eine Nicht-Konformität feststellt. Ausnahmen sind Browsers-Bugs. Zum Beispiel hatten wir mal festgestellt, dass die Hintergrundfarbe bei -Elementen im Firefox browserseitig nicht richtig übernommen wird (Ich habe nicht geprüft, ob das aktuell noch so ist).

In der Praxis sind mir hier aufgefallen:

In beiden Fällen kann man das Problem durch Nutzung von SVGs und CSS (currenColor) Probleme vermeiden. Siehe auch https://www.sarasoueidan.com/blog/inclusively-hiding-and-styling-checkboxes-and-radio-buttons/

Wenn das Hamburger-Icon eine andere Farbe hat, als mit currentColor zugewiesen werden kann, funktioniert die Technik wohl nicht. Aber in den meisten Fällen schon, denke ich.

MarcHaunschild commented 1 year ago

Das mit dem currentColor ist auch einer der Tipps, den ich gebe, wobei es auch eine andere sehr einfache Möglichkeit gibt: man kann Vordergrund und Hintergrund festlegen und dann sind die Symbole in jedem Fall erkennbar. Es ist zwar dann bei eigenen Farben nicht so schön, aber erstens muss es gar nicht schlecht sein, wenn icons auf diese Weise auffälliger werden und zum anderen tut es der Bedienung keinen Abbruch. Dieses vorgehen lässt sich zudem auch unabhängig von svgs z.b. bei gifs und pngs umsetzen. Als Schriftgrösse würde ich 32px vorschlagen, was in der Regel den 200% aus dem Schriftzoom-SC entspricht und von daher sinnvoll scheint. Wenn mindestschriftgrößen aktiviert werden müssen, dann kann man in der Regel Überschriften (die per default maximal 32px groß sind (h1)) nicht mehr von Fließtext unterscheiden, was für Stehende die Nutzung und Verständlichkeit der Seite stark einschränkt. Außerdem nützt das Menschen, die die Schrift verkleinern wollen überhaupt nichts. Wenn also Schriftgrössen-Änderungen nur über die mindestschriftgröße funktionieren, wäre das mMn ein fail (teilweise bestanden), so wie das hier schon thematisiert wurde. Logos würde ich analog zu anderen prüfschritten ausnehmen - sofern sie nicht als Bedienelement eingesetzt werden. Dann müsste man wenigstens erkennen, dass es an der Stelle eine interaktive Fläche befunden, zum Beispiel durch den typischen Rahmen in Linkfarbe.

detlevhfischer commented 1 year ago

@sweckenmann Du könntest dazu wohl einen PR auf meinen älteren PR https://github.com/BIK-BITV/BIK-Web-Test/pull/226 machen.

sweckenmann commented 1 year ago

Wir haben einen PR #328 gemacht. Hoffe das passt so. Wenn es keine Einwände gibt, würden wir ihn diese Woche noch mergen, damit er ins Release zum Wochenende mitkommt.