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
75 stars 22 forks source link

11.7 Benutzerdefinierte Einstellungen: Mindestschriftgröße > keine #258

Closed sprungmarker closed 2 years ago

sprungmarker commented 2 years ago

Bei Webauftritten, die noch Pixelwerte verwenden, wird bei diesem Prüfschritt nichts vergrößert, wenn man die Schriftgröße hochsetzt.

Würde man bei den Einstellungen > Mindestschriftgröße auch auf den gleichen Wert wie etwa 24 setzen, würden alle Inhalte auch vergrößert. Standardmässig ist da aber kein Wert angewählt.

Wie steht ihr dazu? Soll das mitaufgenommen werden, dass die Mindestschriftgröße keinen Wert ausgewählt hat? Bei etlichen Leuten ist da wohl was ausgewählt.

MarcHaunschild commented 2 years ago

Das würde meiner Meinung nach nur zu einem "teilweise erfüllt" reichen und damit einem nicht bestanden - oder bin ich da zu streng? Eine Bewertungsempfehlung hier würde ich mir auch wünschen.

sprungmarker commented 2 years ago

Ja, finde ich auch - habe ich bis dato auch so bewertet, weil Inhalte und Layout fast nur mit Hilfe von Pixel zu realisieren, ist eigentlich ein No-go mittlerweile.

MarcHaunschild commented 2 years ago

Das ist auch ein Aspekt. In Bewertungen spielen auch subjektive Aspekte mit rein. Als Entwickler neige ich dazu, Dinge strenger zu bewerten, die leicht zu beheben sind und viel bringen als Dinge, die viel Aufwand machen und weniger bringen. Also da wo man Entscheidungen wie diese hier treffen kann oder muss.

sprungmarker commented 2 years ago

@sweckenmann mich würde da schon eine Lösung interessieren - sollte das nicht doch im Prüfschritt vermerkt werden, dass in den Einstellungen für die Mindestschriftgröße keine Auswahl getroffen ist? Wenn nicht, d.h. es ist egal, ob da etwas ausgewählt ist, dann wird sich das Ergebnis je nach Vorauswahl halt auch "verbessern", wenn die getestete Seite z.b. nur fixe Schriftgrößen mit Pixel verwendet. Ist das gewollt?

sweckenmann commented 2 years ago

@sprungmarker danke für den Input. Sorry, bin noch nicht dazu gekommen, mich damit zu beschäftigen. D.h. du schlägst vor, in die PS-Anleitung mit aufzunehmen, in etwa:

  1. Im Bereich "Sprache und Erscheinungsbild" die Schriftgröße auf einen deutlich höheren Wert als den Standard-Wert setzen (z.B. 24). In den "Erweiterten Einstellungen" sollte für Mindestschriftgröße "Keine" ausgewählt sein.

Klingt für mich plausilbel, ich mache ein Pull Request @detlevhfischer spricht aus deiner Sicht etwas gegen diesen Zusatz?

sprungmarker commented 2 years ago

@sweckenmann genau - bei mir ist da im Default nichts ausgewählt - also Mindestschriftgröße "keine". Und ja - ich setze den Wert der Schriftgröße immer auf 24.

sprungmarker commented 2 years ago

@sweckenmann danke für das Update - dann schliesse ich jetzt dieses Issue

johannesFischer84 commented 2 years ago

@sweckenmann genau - bei mir ist da im Default nichts ausgewählt - also Mindestschriftgröße "keine". Und ja - ich setze den Wert der Schriftgröße immer auf 24.

Warum "keine" bei Mindestschriftgröße? In diesem Fall greift so ein gesetzter Wert von 24 nur, wenn die Seite keine eigene Schriftgröße definiert. Soll es damit verboten werden quasi vorschlagsmäßig eine Schriftgröße über CSS anzugeben?

MarcHaunschild commented 2 years ago

@sweckenmann genau - bei mir ist da im Default nichts ausgewählt - also Mindestschriftgröße "keine". Und ja - ich setze den Wert der Schriftgröße immer auf 24.

Warum "keine" bei Mindestschriftgröße? In diesem Fall greift so ein gesetzter Wert von 24 nur, wenn die Seite keine eigene Schriftgröße definiert. Soll es damit verboten werden quasi vorschlagsmäßig eine Schriftgröße über CSS anzugeben?

Da vertust du dich. Kann sein, dass du die Seite neu laden musst, aber die Schriftgröße wirkt sich aus. Es sei denn (wie @sprungmarker schrieb), man gibt die Schriftgröße in Pixeln an. Dann funktioniert es nur mit einer Mindestschriftgröße. Das ist ja warum das Ticket ursprünglich geöffnet wurde. Eine eigene Schriftgröße darf schon vergeben werden, nur eben nicht mit der Einheit px

johannesFischer84 commented 2 years ago

@MarcHaunschild Marc, ja ich meinte auch die Pixelangaben. Dazu hatte ich hier in einem anderen Faden schon mal etwas geschrieben. Ich finde es etwas streng, Pixelangaben zu verbieten, wenn Nutzende ja über die Mindestschriftgröße dennoch die Schriftgrößen-Einstellung setzen können. Zudem würde es auch noch die Möglichkeit geben, über den Zoom des Browsers die Schriftgröße zu erhöhen. Daher würde ich 11.7 eher ohne Abzug bewerten, wenn das nur an Pixelangaben für die Schriftgröße liegt. Da aus dem Norm-Kriterium-Text nichts Genaues hervorgeht und die Schriftgröße anderweitig durch Nutzende beeinflusst werden kann, finde ich den Abzug nicht gerechtfertigt. Wenn sich der Text in der Norm ändern würde bzw. eine Art Understanding-Dokument etwas anderes aussagen würde, ändere ich aber auch gern meine Haltung.

MarcHaunschild commented 2 years ago

Ja, dann habe ich dich nur falsch verstanden. Du hast wie immer gute Argumente. Ich bin mir aber nicht ganz sicher, ob die hier zutreffend sind. Diese Forderung der EN ist ohnehin ziemlich seltsam - wer nutzt denn in Zeiten des Reader-Modus noch so etwas? Meiner Meinung nach ist der gesamte Prüfschritt streng. Ob solche Einstellungen übernommen werden, bringt ja wenig für die Zugänglichkeit, weil eben andere Einstellungen möglich sind. Und was unseren Prüfschritt angeht, scheint es mir auch recht willkürlich hier auf die Möglichkeiten eines Browsers mit so geringem Marktanteil zu setzen. Doch dazu später ein Vorschlag. Andererseits gibt es auch weitere Forderungen, wie das mit den 200% Zoom, die ich nie verstanden habe. Eine Website die im Normalzustand nur 8 Pixel hat, besteht den, wenn man auf 16 Pixel zoomen kann, aber eine mit 16 Pixel großer Schrift aus auch noch mal verdoppelt werden können? - Hier wäre eher angebracht zu prüfen, ob man wenigstens auf 32 Pixel große Schriften zoomen kann, was für die Website mit 8 Pixel großer Schrift dann eben 400% zoom bedeutet. Schließlich ist es einem Menschen, der sehr schlecht sieht und 32 Pixel große Schrift benötigt, völlig egal wie groß die Schrift ursprünglich war.

Aber mit diesen Dingen leben wir nun einmal und so auch mit diesem Prüfschritt. Schwierig zu erfüllen ist er nicht, denn Angaben in em sind seit Jahren Standard.

Andererseits kommen wir in solchen Diskussionen immer wieder zu dem Schluss, dass wir Anforderungen an die Zugänglichkeit von Webseiten nicht für die Durchsetzung von best practices missbrauchen dürfen. Auch wenn die Versuchung noch so groß ist Webentwickler zu sinnvollem Handeln zu erziehen: Dafür sind die Bestimmungen nicht gemacht.

Insofern bin ich zwiegespalten: meiner Meinung nach sagt die Anforderung, dass sich alle Nutzereinstellungen auswirken müssen: Farben, Schriftarten und Schriftgrößen - dass Nutzerinnen dabei bestimmte Kombinationen von Einstellungen wählen müssen - also immer auch die Angabe einer Mindestschriftgröße setzen müssen - finde ich nicht in Ordnung und ich meine auch, wir würden da anders drüber reden, wenn sich die Hintergrundfarbe nur bei aktivierter Mindestschriftgröße auswirkt. Jede Einstellung sollte für sich wirken, sonst ist es eben nur eine teilweise Erfüllung des Prüfschrittes.

Nutzer mit bestimmten Bedürfnissen verwenden häufig exotische Browser gerade während deren Fähigkeiten, die anderen Browsern fehlen und so macht es dann am Ende des Tages keinen Unterschied, ob ein Browser hohen oder geringen Marktanteil hat. Wir wissen, dass die Kombination Firefox und NVDA bei Blinden sehr beliebt ist und testen daher zurecht mit dieser Kombination.

Auch dass man andere Möglichkeiten zum Zoomen hat, reicht mir nicht wirklich aus. Denn wenn ich hier dann tatsächlich auf die für mich nötigen 32 Pixel einstelle (oder 48 oder was auch immer), dann kann ich womöglich eher mit einem zerschossenen Layout aber lesbaren Texten leben, als mit dem in dieser Hinsicht strengeren Prüfschritt für den Textzoom, bei dem auch weniger relevante Seiteninhalte stimmen müssen.

Vielleicht können wir den Prüfschritt mit den Nutzereinstellungen ja noch mal etwas schärfer abgrenzen und hier dann in anderer Hinsicht weniger fordern. In einem anderen Thread, den ich jetzt nicht mehr finde, habe ich schon mal erwähnt, dass ich es in Ordnung finde, wenn Nutzer sich Einstellungen vornehmen können, mit denen der Hauptinhalt für sie zugänglich ist, aber andere Dinge (wie Icons - ging dabei um Hintergründe), nicht mehr zu sehen sind. Weil Nutzer ja hin und her switchen können und für Fließtexte eine andere Darstellung wählen können, um lange Texte ermüdungsfrei zu lesen als für den kurzen Klick auf einen Button.

Diesen Gedanken auf Schriftgrößen angewendet würde bedeuten, dass dann Texte im Footer, Marginalspalte und anderes, was eben nicht "lang" (= Hauptinhalt) ist, sich überlappen dürfte, was bei dem Punkt zum Textzoom nicht zulässig wäre.

Im Gegenzug sollte ich dadurch auch die Möglichkeit haben, auf Mindestschriftgrößen zu verzichten und zwar aus zwei Gründen: erstens sind dann Überlappungen und schwerwiegende Nebeneffekte weniger wahrscheinlich und zweitens möchte ich als Mensch mit kognitiven Einschränkungen ganz sicher nicht Unterschiede im Schriftbild nivellieren, die es mir schwer oder unmöglich machen, den Hauptinhalt von dem ganzen Clutter unterscheiden zu können.

Es gibt also durchaus Gründe für Menschen mit Behinderungen keine Mindestschriftgrößen zu wollen.

Aber ja, das ist streng. Und ja: ich bin mir nicht mehr so ganz sicher, ob man das fordern kann. Mir scheint, es gibt für beide Sichtweisen gute Argumente.

Nur wenn wir mit der Änderung Pixelangaben verdammen, dann sollten wir diesen Prüfschritt hier vielleicht schärfer von anderen Prüfschritten abgrenzen und wie gesagt vor allem nicht kleinlich bewerten, wenn hier das Layout bei zweitrangigen Inhalten nicht mehr "funktioniert".

Außerdem sollten wir einheitlich mit einer verbindlichen Schriftgröße testen. 32 Pixel scheinen mir persönlich sehr angemessen, weil es 200% der Standardschriftgröße des Browsers ist.

Leben kann ich sowohl mit Sylvias Vorschlag, als auch mit deinem Gegenargument. Beides hat viel für sich. Wir müssen uns nur entscheiden und einheitlich bewerten.

Das wäre mir persönlich das Wichtigste.

johannesFischer84 commented 2 years ago

Danke für deine ausführliche Anmerkung, Marc. Es zeigt sich hier wieder mal, dass fehlende Understanding-Texte bei den EN-Kriterien die Bewertung total schwierig machen. Ich hoffe, dass die Norm-Ersteller hier nochmal nachbessern. Im Repository der EN 301 549 wird in einem Faden sogar auch für eine zusätzliche NOTE geworben.

Irgendwas von uns aus festlegen wie z. B. eine feste Schriftgröße oder eben das Verbot der Pixel-Angabe für Schriftgröße halte ich für schwierig. Denn da es gesetzliche Vorgaben der EU sind, müsste das eher auf EU-Ebene festgelegt werden.

MarcHaunschild commented 2 years ago

Irgendwas von uns aus festlegen wie z. B. eine feste Schriftgröße oder eben das Verbot der Pixel-Angabe für Schriftgröße halte ich für schwierig.

Ich möchte nicht die Pixel-Angaben verbieten.

Ich denke jede Einstellung der Nutzer muss sich auswirken.

Wenn ausschließlich Schriftart oder Farbe oder Größe oder Mindestgröße geändert wird, muss sich das auswirken. Jede einzelne Einstellung von Nutzern muss einen Effekt haben. Sonst wäre der Prüfschritt nur teilweise erfüllt.

Ich finde es unzulässig zu fordern, dass Nutzer bestimmte Kombinationen von Einstellungen vornehmen müssen.

johannesFischer84 commented 2 years ago

Ich kann deine Argumentation nachvollziehen, Marc. Dass sich die Pixel-Schriftgröße nur bei Mindestgrößenangaben der Schrift, aber nicht bei Größen-Angaben ändert, halte ich für einen Fehler in der Verarbeitung des Browsers, ähnlich wie Fehlermeldungen des Browsers (z. B. bei Abschicken Formular mit leeren required-Formularfeldern) sich beispielsweise nicht vergrößern lassen. Bei Fehlermeldungen des Browsers fordern wir eine Umgehung z. B. mit novalidate-Attribut für das Formular (ohne Verzicht auf required-Attribute). Eine solche Umgehung könnte man bei der Schriftgröße in Form der Mindestgröße oder im erfolgreichen Zoom des Browsers sehen (ohne Verzicht auf Pixel-Schriftgrößenangaben). Wobei die Umgehung bei den Formularfehlermeldungen auch nicht normativ festgelegt ist, sondern eher aus Diskussionen der WCAG Working Group hervorgegangen war. Insgesamt stellt es für mich zumindest nicht eindeutig dar, wie man Pixel-Schriftgrößenangaben in der Bewertung handhaben sollte, ich kann aber beide Richtungen nachvollziehen.

MarcHaunschild commented 2 years ago

Ich kann auch beide Richtungen nachvollziehen und hätte gerade deshalb hier eine eindeutiges Vorgehen in der Prüfschritt-Beschreibung, dann mache ich es wie alle anderen.

Die lange Antwort:

Eigentlich wollte ich das so ausführlich nicht schreiben, aber vielleicht interessiert es ja jemanden: ich mochte immer, dass der IE bei Text zoomen Pixelgrößen beibehalten hat. Es gab mir als Entwickler das Gefühl, etwas mehr Kontrolle über die Website zu haben und Nutzer denen das nicht genügt hat, konnten per Seitenzoom ja trotzdem auf 200% skalieren und ich habe auch dafür gesorgt (damals noch fluid Layout, RWD gab es noch nicht), dass beides funktioniert hat. Den Gedanken, absichtlich eine feste Schriftgröße festzulegen, die immer eine bestimmte Größe hat, schien mir nicht abwegig, auch wenn ich selber nie den Bedarf dafür hatte. Insofern würde ich bei deinem "Vorwurf", dass es ich hier um einen Browserbug handelt gern ein ganz klein bisschen Widersprechen, gibt es doch jetzt dem Nutzer die Macht darüber, das Layout gezielt komplett oder mit Einschränkungen anzupassen und die Kontrolle in die Nutzerhänder zu legen gefällt mir als Barrierefreiheit-Onkel noch besser. Allerdings sehe ich dabei zwei Probleme: erstens weiß davon "kein" Nutzer etwas und zweitens ist die aktuelle Implementation in FF so schlecht, dass man da als Nutzer auch niemals drauf kommen wird. Wer weiß schon, dass man mit der Schriftgröße nur solche Schriftgrößen anpasst, die mit relativen Einheiten daher kommen. Das weiß kaum ein Entwickler (und kann damit dieses Feature nicht sinnvoll nutzbar machen) und kein Nutzer (und kann es damit nicht anwenden). So macht es dann auch überhaupt keinen Sinn. My 2 Cents

mayerhh commented 2 years ago

Irgendwas von uns aus festlegen wie z. B. eine feste Schriftgröße oder eben das Verbot der Pixel-Angabe für Schriftgröße halte ich für schwierig. Denn da es gesetzliche Vorgaben der EU sind, müsste das eher auf EU-Ebene festgelegt werden.

Genau das ist der Punkt. Aus der derzeitigen Fassung der EN lässt sich für 11.7 alles und nichts ableiten. Auf so einer Basis kann man keine Konformitätstests machen. Wir sollten hier auf Klartstellung warten.

MarcHaunschild commented 2 years ago

Irgendwas von uns aus festlegen wie z. B. eine feste Schriftgröße oder eben das Verbot der Pixel-Angabe für Schriftgröße halte ich für schwierig. Denn da es gesetzliche Vorgaben der EU sind, müsste das eher auf EU-Ebene festgelegt werden.

Genau das ist der Punkt. Aus der derzeitigen Fassung der EN lässt sich für 11.7 alles und nichts ableiten. Auf so einer Basis kann man keine Konformitätstests machen. Wir sollten hier auf Klartstellung warten.

Was machen wir in der Zwischenzeit mit diesem Prüfschritt?

stefanFarnetani commented 2 years ago

Wir sollten hier auf Klartstellung warten. Apropos. Mal in die Runde gefragt. Wie sieht es denn aus? Weiß irgendjemand näheres? Wurde der Vorschlag eines "understanding documents" unterbreitet?

Ich habe leider keinerlei Kontakt zu Personen des EU-Gremiums. Falls Zuarbeit benötigt wird, helfe ich gerne. Über diesem Prüfschritt diskutiere/recherchiere/lese ich so häufig, dass eine beschleunigte Klarstellung mir tatsächlich Zeit und Geld einsparen würde.

mayerhh commented 2 years ago

Keine Ahnung, wie der Stand ist. Ich finde aus dem Thread, den Johannes oben verlinkt hat, die Haltung der Section 508 zu einer vergleichbaren Anforderung sehr interessant:

https://www.federalregister.gov/d/2017-00395/p-627

503.2 User Preferences. Applications shall permit user preferences from platform settings for color, contrast, font type, font size, and focus cursor. EXCEPTION: Applications that are designed to be isolated from their underlying platform software, including Web applications, shall not be required to conform to 503.2.`

Die Begründung: https://www.access-board.gov/ict/#503-applications-1

The proposed rule included a general requirement that applications must permit users to set their preferences from platform settings for color, contrast, font type, and focus cursor (proposed 503.2). For example, a user with low vision might want the default windowing scheme to use yellow on black text with an 18 point sans-serif font. An exception to this provision exempts applications that are designed to be isolated from their underlying platform software (such as Web applications) from this requirement. We received several comments (from individuals, a disability advocacy organization, and an accessibility ICT services provider) concerning the scope of the exception. These commenters acknowledged that certain technologies (such as Adobe® Flash®) were properly exempted, but thought that the exception was otherwise overbroad by sweeping in other types of Web applications (which were unspecified). More generally, some of these commenters also suggested that the Board broaden 503.2 so that the requirement for pass-through of user preferences apply to Web content, as well as applications.

With respect to commenters' suggestion of overbreadth, the Board declines to revise the exception to apply only to certain types of Web applications. We are aware of no discernible basis for differentiating between Web applications that do and do not warrant the exception, nor did commenters offer any such criteria. It is not technically feasible to require Web applications to use platform preferences because generally the developer of a Web application has no way of knowing what font characteristics a reader will be using for text in windows of their operating system. Applications, including Web applications, which qualify for the exception to use platform settings are still subject to the other requirements of Chapter 5, including the requirements referenced by WCAG 2.0 Level AA.

Likewise, the Board finds commenters' suggestion that the scope of proposed 502.3 be broadened to include Web content to be misplaced. Section 502.3 in the final rule, as with all of Chapter 5, addresses technical requirements for accessibility of software, not Web content. In any event, requiring Web content to meet requirements for pass-through of user preferences would face the same technical challenges as Web applications.

MarcHaunschild commented 2 years ago

Keine Ahnung, wie der Stand ist. Ich finde aus dem Thread, den Johannes oben verlinkt hat, die Haltung der Section 508 zu einer vergleichbaren Anforderung sehr interessant:

Das ist ja auch nicht unsinnig, aber die EU hat sich nun mal anders entschieden. Vielleicht kann man für die Zukunft auf diesen Punkt Einfluss nehmen?

Bis dahin sind Webanwendungen in der EN allerdings explizit genannt und als "underlying platform" der Browser definiert...

johannesFischer84 commented 2 years ago

Wir sollten hier auf Klartstellung warten. Apropos. Mal in die Runde gefragt. Wie sieht es denn aus? Weiß irgendjemand näheres? Wurde der Vorschlag eines "understanding documents" unterbreitet?

Ich habe leider keinerlei Kontakt zu Personen des EU-Gremiums. Falls Zuarbeit benötigt wird, helfe ich gerne. Über diesem Prüfschritt diskutiere/recherchiere/lese ich so häufig, dass eine beschleunigte Klarstellung mir tatsächlich Zeit und Geld einsparen würde.

Der erste Bericht zu den Befragungen zur EU-Richtlinie 2016/2102 ist letzten Freitag veröffentlicht worden: Der erste Bericht zu den Befragungen der EU-Richtlinie 2016/2102 ist letzten Freitag veröffentlicht worden: https://op.europa.eu/en/publication-detail/-/publication/4a93f181-d2d1-11ec-a95f-01aa75ed71a1/language-en Allerdings sind die Ergebnisangaben eher oberflächlich und sagen nichts über zukünftige Schritte aus, die auch erst noch nach einer genaueren Analyse der Ergebnisse erarbeitet werden sollen.

mitchellevan commented 2 years ago

Seit 2018 prüfe ich Websites und native Apps nach Section 508 und EN 301 549. Section 508 und EN 301 549 halte ich in diesem Fall für anders. Auf der einen Seite ist es etwas ärgerlich, wenn sich die beiden Standards unterscheiden. Andererseits sind Einstellungen im Browser tatsächlich möglich. Es ist gut für die Benutzer, wenn einer der Standards ein höheres Maß an Barrierefreiheit fordert.

Was machen wir in der Zwischenzeit mit diesem Prüfschritt?

Ich erwarte nicht, dass die EU auf eine solche Frage eine verbindliche Antwort gibt. Deutschland sollte einen Präzedenzfall schaffen. Ich empfehle Folgendes: