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

11.7 Benutzerdefinierte Einstellungen - Iconfonts #245

Open stefanFarnetani opened 2 years ago

stefanFarnetani commented 2 years ago

Verwendet eine Website die Iconfont-Technik zur Darstellung von Icons, so wird nach dem deaktivieren der Checkbox "Seiten das Verwenden von eigenen statt der oben gewählten Schriftarten erlauben" kein Icon mehr korrekt dargestellt.

Wie bewertet man so eine Situation? Die Iconfont-Technik ist immer weit verbreitet und an sich kein Fehler. Die Umstellung der Schrift macht die Seite mit sehr hoher Wahrscheinlichkeit als sehender unbedienbar (fehlende Icons in allen Buttons). Also müssten wir ein "nicht bestanden" vergeben. Mir erscheint das jedoch sehr streng. Sollte es ein eher erfüllt sein?

Ich frage mich, ob wir die Prüfung auf individuelle Schriftart ganz aus dem Prüfschritt raus nehmen sollen. Meines Wissens nach ist die Einstellung einer Schriftart nur im Firefox-Browser möglich. Wir testen und bestrafen einen technischen Sonderfall. Aktuell testen wir ja auch die weiteren "Maßeinheiten" und die individuelle "Darstellung des Fokuscursors" nicht. Eben aus den Gründen, dass es technisch nicht geht.

MarcHaunschild commented 2 years ago

Es gibt ja zahlreiche übliche Vorgehensweisen, die weit von best practices entfernt sind.

Seit mehr als einer halben Dekade wird von Iconfonts abgeraten und statt dessen die Verwendung von SVGs (inline, als img, Sprite oder wie auch immer) empfohlen.

Ich finde es schwierig so zu argumentieren, denn viele Techniken sind üblich, aber nicht barrierefrei (ein Link-Element als Button zu gestalten und mit onclick zu versehen). Das lassen wir auch nicht durchgehen. Zumal hier wie dort (besser zugängliche) Alternativen vorhanden sind.

Auch ist es nicht ganz richtig, dass es nur für sehende Firefox-Nutzerinnen ein Problem gibt. Auch Screenreader-Nutzerinnen haben mit Iconfonts das Problem, dass es unverständliche Zeichen gibt (daher müssen die dann per ARIA-hidden verborgen und mit einer zugänglichen Text-Alternative versehen werden).

Also von mir kein ja oder nein, nur ein bisschen Wechselgeld (ziemlich genau 2Cent)

Am 27.01.2022 um 13:32 schrieb Stefan Farnetani @.***>:

Ich frage mich, ob wir die Prüfung auf individuelle Schriftart ganz aus dem Prüfschritt raus nehmen sollen. Meines Wissens nach ist die Einstellung einer Schriftart nur im Firefox-Browser möglich. Wir testen und bestrafen einen technischen Sonderfall

stefanFarnetani commented 2 years ago

@MarcHaunschild wir haben ebenfalls iconfonts hinter uns gelassen. Dennoch ist die Technik , richtig eingesetzt (mit aria usw.), völlig valide. Ich habe viel schlimmeres gesehen. Bitte verteufelt iconfonts nicht. Das Argument, dass die Technik schlecht ist, würde ich nicht gelten lassen.

MarcHaunschild commented 2 years ago

Ich habe die Technik nicht schlecht genannt oder gar verteufelt. Das Gute ist der Feind des besseren. ;-)

Die Frage ist nur, wollen wir die objektiv vorhandenen Probleme als so gering einstufen, dass wir ein Pass geben.

Ich finde die Frage schwer zu beantworten. Persönlich denke ich: wenn jemand Iconfonts verwendet, soll er sich um die Probleme kümmern - dann machen Iconfonts keinen Sinn, denn seien wir ehrlich: die werden eingesetzt, weil sie praktisch sind - in Bezug auf Barrierefreiheit sind sie aber unpraktisch, weil es mehr Probleme zu lösen gibt als bei der Verwendung von SVGs.

Insofern wäre die Verwendung von SVGs aus Sicht der Wirtschaftlichkeit im barrierefreien Umfeld zu empfehlen.

Vermutlich ist das auch der Grund, warum ihr keine Iconfonts mehr einsetzt. Bei mir war das definitiv der Grund.

Ich tu mich immer schwer, Entwickler zu unterstützen, die veraltete Technik verwenden und dafür Kompromisse auf User-Seite zu akzeptieren. Ich tu mich leichter damit, wenn es keine guten oder gar besseren Alternativen gibt. Aber für Iconfonts gibt es die nun mal.

Aufgrund dieser Überlegungen tendiere ich inzwischen eher zu einem FAIL, wobei es immer auf den konkreten Fall ankommt - es muss ohne Icon schon komplett unverständlich sein, um ein Fail zu ergeben - sonst ist es ein „eher erfüllt“…

Wenn Icons aus anderen Gründen z.B. bei eigenen Hintergründen unerkennbar sind oder verschwinden, werten wir ja auch ab.

Am 27.01.2022 um 14:50 schrieb Stefan Farnetani @.***>:

@MarcHaunschild https://github.com/MarcHaunschild wir haben ebenfalls iconfonts hinter uns gelassen. Dennoch ist die Technik , richtig eingesetzt (mit aria usw.), völlig valide. Ich habe viel schlimmeres gesehen. Bitte verteufelt iconfonts nicht. Das Argument, dass die Technik schlecht ist, würde ich nicht gelten lassen.

— Reply to this email directly, view it on GitHub https://github.com/BIK-BITV/BIK-Web-Test/issues/245#issuecomment-1023230324, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAFHOSUGSV5BACC6J4OZBFLUYFESJANCNFSM5M5YV6TA. You are receiving this because you were mentioned.

stefanFarnetani commented 2 years ago

@MarcHaunschild Welche Nachteile siehst du in der iconfont-Technik. Ich sehe nur, dass ggf. sinnlose Zeichen vorgelesen werden. Und das lässt sich sehr einfach lösen mit ein aria-hidden. In dem konkretem Beispiel ist alles "korrekt" programmiert. ich hätte die iconfonts jederzeit durchgewunken , wenn nicht dieser Prüfschritt existieren würde.

MarcHaunschild commented 2 years ago

Das haben andere besser zusammengefasst. Zum Beispiel hier (aktueller Artikel) https://www.lambdatest.com/blog/its-2019-lets-end-the-debate-on-icon-fonts-vs-svg-icons/#:~:text=One%20major%20advantage%20of%20SVG%20icons%20over%20Icon,as%20an%20image%20and%20not%20as%20a%20text.

Auf CSS-Tricks gibt es eine ganze Serie von Artikeln zu dem Thema und Chris Coyier hat das Thema für sich 2014 abschließend beantwortet: https://css-tricks.com/icon-fonts-vs-svg/

Ich kenne keine Gegenüberstellung dieser beiden Techniken, in der Iconfonts besser abschneiden. Agenturen stellen nur sehr zögerlich auf SVGs um, ich kenne aber keine, die wieder zurück zu Iconfonts gewechselt wäre.

Ich selber habe es mal für mich recherchiert und so zusammengefasst (siehe unten, nicht mehr besonders aktuell) die letzte Jahre habe ich mit einer Mischung aus SVG-Sprites und inline-SVGs gearbeitet und will auch nicht mehr zurück.

https://haunschild.de/2016/svg-scalable-vector-graphics/

Nichts davon rechtfertigt ein FAIL in einem BIK-BITV-Audit zu vergeben. Auch bei mir ist es nur der eine Punkt, den du angegeben hast.

Und da tendiere ich eher zu einem fail, wenn durch das Fehlen der Icons eine Funktion komplett unverständlich wird - kann aber auch gut damit leben, wenn das - weil es nur einen Browser betrifft - anders festgelegt wird. Deinen Vorstoß, das mal festzulegen (und womöglich in der Prüfschrittbeschreibung zu dokumentieren) finde ich sehr gut!

johannesFischer84 commented 2 years ago

Verwendet eine Website die Iconfont-Technik zur Darstellung von Icons, so wird nach dem deaktivieren der Checkbox "Seiten das Verwenden von eigenen statt der oben gewählten Schriftarten erlauben" kein Icon mehr korrekt dargestellt. Wie bewertet man so eine Situation?

Hm, schwierig. Also wenn die Icons nicht unbedingt für das Verständnis nötig sind, kann man es aus meiner Sicht durchgehen lassen. Ein Hamburger-Schalter (Öffnen einer Navigation) sollte aus meiner Sicht aber schon noch korrekt dargestellt werden, wenn kein zusätzlicher Text oder anderes Merkmal darauf hinweist. Zumindest interpretiere ich die 11.7 so.

stefanFarnetani commented 2 years ago

@MarcHaunschild danke für die Informationen. Beim Durchlesen ist mir nichts aufgefallen, was -bei korrekter Verwendung- ein Fail in einen der andren Prüfschritte rechtfertigt. Und du hast es ja auch erwähnt, dass ein fail nicht direkt gerechtfertigt ist. Aus Sicht eines Testers (während mein Entwicker-Herz natürlich blutet) führt die Verwendung der iconfont-Technik im restlichen Prüfkatalog zu keinen Abzug. Wenn dazu konsens besteht, würde ich die Diskussion auf das bestehen von 11.7 konzentrieren.

Ich greife auch @johannesFischer84 Anmerkungen auf. Beim Ersetzten der Schrift kommt es: 1) zu Situationen in denen "dekorative" icons ersetzt werden. z.B. icons vor telefonummern, die auch ohne icons eindeutig erkennbar sind. 2) zu Situationen, wie z.B. icon-buttons, die ohne Icon nicht mehr bedienbar sind.

Zu 1) ich denke wir sind uns einig, dass es keine punkte Abzüge rechtfertigt. Zu 2) Wenn ich das Ergebnis betrachte ist die Bewertung eindeutig. Es ist nicht bedienbar, also fail. Aber wenn ich mir anschaue wie es zu der Situation kommt. Dass ich beim Testen massiv in das Rendering der Website eingreife mit einer Technik die es nur auf Firefox gibt, frage ich mich, ob das eine realistischer FAll ist und ein fail gerechtfertigt. Wir haben mit Issue #244 zufällig zeitgleich eine ähnliche Diskussion. In beiden steht am Schluss die Frage: Beeinflusst die Art des Testen das Testergebnis zu stark und müssen Bewertungsausnahmen definiert werden?

stefanFarnetani commented 2 years ago

Ich muss nochmal nachlegen. Mir ist gerade noch etwas eingefallen. Wenn wir schon dabei sind sollten wir die gleiche Diskussion auch gleich über SVG- und Canvas-Elemente führen, wenn diese größere Inhaltsbereiche oder interaktive Komponenten darstellen. Stellt euch sowas wie google analytics (die Diagramme mit Bild und Text) vor oder auch sowas wie google docs (wo die ganze Seite und teile der Navigation als Canvas umgesetzt werden). Der Browser reicht Farb- und Schriffanpassung, meines Wissens, nicht an das SVG und Canvas weiter.

MarcHaunschild commented 2 years ago

@MarcHaunschild danke für die Informationen. Beim Durchlesen ist mir nichts aufgefallen, was -bei korrekter Verwendung- ein Fail in einen der andren Prüfschritte rechtfertigt. Und du hast es ja auch erwähnt, dass ein fail nicht direkt gerechtfertigt ist. Aus Sicht eines Testers (während mein Entwicker-Herz natürlich blutet) führt die Verwendung der iconfont-Technik im restlichen Prüfkatalog zu keinen Abzug. Wenn dazu konsens besteht, würde ich die Diskussion auf das bestehen von 11.7 konzentrieren.

Von Anfang an: ein FAIL kommt nur in Frage, wenn Informationen oder Funktionalitäten verloren gehen.

Ich greife auch @johannesFischer84 Anmerkungen auf. Beim Ersetzten der Schrift kommt es:

  1. zu Situationen in denen "dekorative" icons ersetzt werden. z.B. icons vor telefonummern, die auch ohne icons eindeutig erkennbar sind.
  2. zu Situationen, wie z.B. icon-buttons, die ohne Icon nicht mehr bedienbar sind.

Zu 1) ich denke wir sind uns einig, dass es keine punkte Abzüge rechtfertigt. Zu 2) Wenn ich das Ergebnis betrachte ist die Bewertung eindeutig. Es ist nicht bedienbar, also fail. Aber wenn ich mir anschaue wie es zu der Situation kommt. Dass ich beim Testen massiv in das Rendering der Website eingreife mit einer Technik die es nur auf Firefox gibt, frage ich mich, ob das eine realistischer FAll ist und ein fail gerechtfertigt.

Genau in der Argumentation bin ich dir anfangs noch gefolgt. Aber ist das überhaupt so? Wir testen so, aber was ist mit User StyleSheets? Was mit Plugins, die die Verwendung eigener Styles allen ermöglichen? Die gibt es als Plugin doch für alle Browser.

Und andere Browser? Gibt es keine Möglichkeit Edge zu zwingen eine Systemschriftart zu verwenden, wenn man sich durch die Barrierefreiheits-Einstellungen von Windows kämpft? Oder Safari unter MacOS? Und iOS? Android?- Ich bin mir nicht sicher, ob man nur FF dazu bringen kann, Wunschschrfitarten zu verwenden - vielleicht hat das ja jemand anders schon mal getestet?!?

Mein Fazit

Manchen Menschen helfen eigene Schriftarten.

Es gibt also einen Bedarf.

Und es gibt Möglichkeiten, eine Website so robust zu machen, dass sie das aushält.

Daher: je länger wir darüber diskutieren, desto mehr wäre ich für ein FAIL...

MarcHaunschild commented 2 years ago

Der Browser reicht Farb- und Schriffanpassung, meines Wissens, nicht an das SVG und Canvas weiter.

Die zugrundeliegende Plattform ist der Browser. Wenn die dort getätigten Einstellungen nicht greifen - wie soll man dann ein PASS geben?

sweckenmann commented 2 years ago

@stefanFarnetani Unabhängig der Diskussion/Kritik, ob die Prüfung mit einer Technik, die es nur in Firefox gibt (siehe auch Issue #244) und welche ich nachvollziehen kann, gibt es eine ARIA-Technik, die bei Icon-Fonts vielleicht hilft (habe es nicht getestet)? Siehe Semantically identifying a font icon with role="img"

stefanFarnetani commented 2 years ago

@stefanFarnetani Unabhängig der Diskussion/Kritik, ob die Prüfung mit einer Technik, die es nur in Firefox gibt (siehe auch Issue #244) und welche ich nachvollziehen kann, gibt es eine ARIA-Technik, die bei Icon-Fonts vielleicht hilft (habe es nicht getestet)? Siehe Semantically identifying a font icon with role="img"

Spannend. dass kannte ich noch nicht. ich werde es mal ausprobieren.

MarcHaunschild commented 2 years ago

Weil es mir keine Ruhe lässt. Die Forderung ist ja recht simpel:

Procedure

1.    Check that the software provides a mode of operation that follows the platform settings.

Result

Pass: Check 1 is true

Also können wir gar nicht fordern, dass nach der Übernahme der Nutzereinstellungen noch irgendetwas funktioniert?!? Geprüft werden soll ausschließlich, ob die Einstellungen des Nutzer übernommen werden. Wenn es dann nicht funktioniert, läge es am Nutzer seine Einstellungen so anzupassen, dass z.B. die Icons wieder erscheinen?!?

johannesFischer84 commented 2 years ago

@stefanFarnetani

Beim Ersetzten der Schrift kommt es:

  1. zu Situationen in denen "dekorative" icons ersetzt werden. z.B. icons vor telefonummern, die auch ohne icons eindeutig erkennbar sind.
  2. zu Situationen, wie z.B. icon-buttons, die ohne Icon nicht mehr bedienbar sind. Zu 1) ich denke wir sind uns einig, dass es keine punkte Abzüge rechtfertigt. Zu 2) Wenn ich das Ergebnis betrachte ist die Bewertung eindeutig. Es ist nicht bedienbar, also fail. Aber wenn ich mir anschaue wie es zu der Situation kommt. Dass ich beim Testen massiv in das Rendering der Website eingreife mit einer Technik die es nur auf Firefox gibt, frage ich mich, ob das eine realistischer FAll ist und ein fail gerechtfertigt.

Zu 1) ja, einig, sofern nicht Telefonnummer und Faxnummer beieinander stehen, die ohne Symbol nicht auseinanderhaltbar wären ... Zu 2) Versteh ich schon, nur drückt es die EN 11.7 aus meiner Sicht so aus, dass es wohl ein Fail sein muss. :-(

johannesFischer84 commented 2 years ago

@MarcHaunschild

Und andere Browser? Gibt es keine Möglichkeit Edge zu zwingen eine Systemschriftart zu verwenden, wenn man sich durch die Barrierefreiheits-Einstellungen von Windows kämpft? Oder Safari unter MacOS? Und iOS? Android?- Ich bin mir nicht sicher, ob man nur FF dazu bringen kann, Wunschschrfitarten zu verwenden - vielleicht hat das ja jemand anders schon mal getestet?!?

Wenn die Webseite keine eigenen Schriftarten definiert, werden die Browser-eingestellten Schriftarten z. B. in Chrome übernommen. Aber eben nur dann. Da hatte ich auch schon mal gefragt, ob Entwickler nun keine eigenen Schriftarten mehr definieren dürfen oder ob sie eine Einstellung setzen müssen, wo die Schriftdefinition im CSS ausgeschaltet wird?

johannesFischer84 commented 2 years ago

@MarcHaunschild

Also können wir gar nicht fordern, dass nach der Übernahme der Nutzereinstellungen noch irgendetwas funktioniert?!? Geprüft werden soll ausschließlich, ob die Einstellungen des Nutzer übernommen werden. Wenn es dann nicht funktioniert, läge es am Nutzer seine Einstellungen so anzupassen, dass z.B. die Icons wieder erscheinen?!?

Ich schätze es so ein: Nein, es läge nicht am Nutzer, die Einstellungen anzupassen. Sondern die Software, hier also die Webseite, muss einen Modus anbieten, der den platform settings, hier also den Browser-Einstellungen, folgt.

MarcHaunschild commented 2 years ago

@MarcHaunschild

Also können wir gar nicht fordern, dass nach der Übernahme der Nutzereinstellungen noch irgendetwas funktioniert?!?

Geprüft werden soll ausschließlich, ob die Einstellungen des Nutzer übernommen werden.

Ich schätze es so ein: Nein, es läge nicht am Nutzer, die Einstellungen anzupassen.

Der hat seine Einstellungen ja schon angepasst, wenn die icons weg sind.

Sondern die Software, hier also die Webseite, muss einen Modus anbieten, der den platform settings, hier also den Browser-Einstellungen, folgt.

Das tut er ebenfalls, wenn die Icons weg sind.

Was bedeutet denn "folgen"?

Dass die Änderungen sich auswirken (tun sie) oder dass die Änderungen sich auswirken und noch alles funktioniert?

In der WCAG steht ja immer so etwas:

"Except for captions and images of text, text can be resized without assistive technology up to 200 percent without loss of content or functionality."

Der letzte Teil steht nicht explizit in 11.7 der EN.

Wir hatten ja auch schon vor längerem den Hinweis von Jörg und @jkphl glaube ich, dass man kaum eine Seite bauen kann, die alles überlebt, was Nutzer so einstellen können.

Konkret bei den Icons gibt es eine robuste Technik. Trotzdem sehe ich in der EN keinen Hinweis darauf, dass wir das fordern können.

Ich habe es immer als selbstverständlich hingenommen, dass nach solchen Einstellungen alles funktionieren muss. So habe ich ja hier auch argumentiert.

Aber nochmal: das steht da nicht.

Wenn der Browser den Einstellungen folgt, dann ist es ein PASS und es wird nichts anderes mehr getestet...

sweckenmann commented 2 years ago

Hattet ihr eigentlich schon mal praktisch den Fall, dass ein Icon der FF-Prüfung mit eigenen Schriften verschwunden ist? Ich meine bei mir ist das Problem in der Prüfung noch nie aufgetaucht oder ich habs übersehen..

stefanFarnetani commented 2 years ago

Hattet ihr eigentlich schon mal praktisch den Fall, dass ein Icon der FF-Prüfung mit eigenen Schriften verschwunden ist? Ich meine bei mir ist das Problem in der Prüfung noch nie aufgetaucht oder ich habs übersehen..

Ich hatte den Fall. Leider ist die Seite nicht öffentlich. Jetzt habe ich auf die schnelle eine x-beliebige andere Seite mit icon-fonts getestet und musste feststellen, dass der Fehler anscheinend nicht per se "immer" auftritt. Ich muss etwas genauer nachschauen, wahrscheinlich ist es ein Zusammenspiel an Programmierung. Für die diskusison aber heißt es. Es ist ein edge-case. und in sofern sollte er nicht betrachtet werden.

@sweckenmann Danke für den sehr wichtigen Hinweis. @all entschuldigt diese Diskussion. Ich habe übersehen, dass das ein edge-case ist. Das hat die Diksussion unnötig gemacht.

Aber. ich finde wir sind durch @MarcHaunschild Ausführungen auf eine sehr wichtige Frage gestoßen. insofern hatte es doch ein wenig etwas gutes. ;)

johannesFischer84 commented 2 years ago

@MarcHaunschild

Was bedeutet denn "folgen"? Dass die Änderungen sich auswirken (tun sie) oder dass die Änderungen sich auswirken und noch alles funktioniert? In der WCAG steht ja immer so etwas: "Except for captions and images of text, text can be resized without assistive technology up to 200 percent without loss of content or functionality." Der letzte Teil steht nicht explizit in 11.7 der EN.

Ja, das bedeutet "folgen" aus meiner Sicht. Dass "kein Inhalts-/Funktionsverlust" in den WCAG explizit drinsteht, hat meiner Meinung nach nur den Grund, dass vielleicht nicht jeder gleich daran denkt. Quasi eine zusätzliche Sicherheit. Bei der EN sollte das genauso gelten. Der Zusatz wie in den WCAG zur Klarstellung wäre sicher sinnvoll, damit nicht solche Nachfragen aufkommen.

Wenn Inhalt oder Funktion verloren geht und das Kriterium weiterhin bestanden wird, dann macht das Kriterium aus meiner Sicht keinen Sinn und man könnte es auch weglassen.

Wenn der Browser den Einstellungen folgt, dann ist es ein PASS und es wird nichts anderes mehr getestet...

Nicht der Browser soll Einstellungen folgen, sondern die Seite soll den gesetzten Einstellungen des Browsers folgen.

MarcHaunschild commented 2 years ago

@MarcHaunschild

Was bedeutet denn "folgen"? Dass die Änderungen sich auswirken (tun sie) oder dass die Änderungen sich auswirken und noch alles funktioniert? In der WCAG steht ja immer so etwas: "Except for captions and images of text, text can be resized without assistive technology up to 200 percent without loss of content or functionality." Der letzte Teil steht nicht explizit in 11.7 der EN.

Ja, das bedeutet "folgen" aus meiner Sicht. Dass "kein Inhalts-/Funktionsverlust" in den WCAG explizit drinsteht, hat meiner Meinung nach nur den Grund, dass vielleicht nicht jeder gleich daran denkt. Quasi eine zusätzliche Sicherheit. Bei der EN sollte das genauso gelten. Der Zusatz wie in den WCAG zur Klarstellung wäre sicher sinnvoll, damit nicht solche Nachfragen aufkommen.

Falls das gemeint ist. Meiner Meinung nach können wir hier nur spekulieren. Was gemeint ist, kann man den Text nicht entnehmen.

Wenn Inhalt oder Funktion verloren geht und das Kriterium weiterhin bestanden wird, dann macht das Kriterium aus meiner Sicht keinen Sinn und man könnte es auch weglassen.

Auf keinen Fall. Ich nutze ständig den Lesemodus, obwohl da ganz viel weg fällt (Menü, Seitenleiste, Fußbereich), ja sogar weil da viel weg fällt (Werbung).

Wieso soll es mich kümmern, wenn ich den langen Text im Hauptteil lesen möchte, ob irgendwelche icons auf call-to-Action- buttons fehlen. Außerdem habe ich es in der Hand, den vom Autor bereitgestellten Zustand wieder zu aktivieren, wenn ich den doch mal sehen will.

Die Forderung, dass die Website den Einstellungen folgen soll, finde ich auch dann sinnvoll, wenn Details wie ein Icon verschwindet.

Wir können das jetzt so festlegen wie wir meinen, das es gedacht ist. Unter Umständen werden wir dann für Forderungen kritisiert, die die EN nicht hergibt.

können wir das nicht - zum Beispiel über die BFIT - klären lassen?

Wenn der Browser den Einstellungen folgt, dann ist es ein PASS und es wird nichts anderes mehr getestet...

Nicht der Browser soll Einstellungen folgen, sondern die Seite soll den gesetzten Einstellungen des Browsers folgen.

Ja, schon klar…

johannesFischer84 commented 2 years ago

Auf keinen Fall. Ich nutze ständig den Lesemodus, obwohl da ganz viel weg fällt (Menü, Seitenleiste, Fußbereich), ja sogar weil da viel weg fällt (Werbung).

Ok, ich verstehe. Aber wenn man nur Farben oder Schriften ändert, weiß ich nicht, ob man dabei erwarten darf/will, dass bestimmte Inhalte verschwinden. Der Lesemodus hat dagegen das Ziel, dass man den Hauptinhalt der aktiven Seite gut lesen kann, nicht dass man Menüs bedienen muss.

Wir können das jetzt so festlegen wie wir meinen, das es gedacht ist. Unter Umständen werden wir dann für Forderungen kritisiert, die die EN nicht hergibt. können wir das nicht - zum Beispiel über die BFIT - klären lassen?

Die Überwachungsstellen, die du sicherlich meinst, können hier auch nur die EN interpretieren und ggf. unterschiedlicher Meinung sein. Klären kann das nur die EU bzw. die Arbeitsgruppen, welche dieses EN-Kriterium verfasst haben ...

MarcHaunschild commented 2 years ago

Auf keinen Fall. Ich nutze ständig den Lesemodus, obwohl da ganz viel weg fällt (Menü, Seitenleiste, Fußbereich), ja sogar weil da viel weg fällt (Werbung).

Ok, ich verstehe. Aber wenn man nur Farben oder Schriften ändert, weiß ich nicht, ob man dabei erwarten darf/will, dass bestimmte Inhalte verschwinden.

Nein, natürlich will ich das nicht, wenn ich so etwas nutze. Aber mich persönlich stört es auch nicht, wenn sich dadurch ein drängenderes Problem lösen lässt und ich dann wieder zur Normalansicht zurückkehren kann.

Wie auch immer: wir können hier nur spekulieren.

Wir können das jetzt so festlegen wie wir meinen, das es gedacht ist. Unter Umständen werden wir dann für Forderungen kritisiert, die die EN nicht hergibt. können wir das nicht - zum Beispiel über die BFIT - klären lassen?

Die Überwachungsstellen, die du sicherlich meinst, können hier auch nur die EN interpretieren und ggf. unterschiedlicher Meinung sein. Klären kann das nur die EU bzw. die Arbeitsgruppen, welche dieses EN-Kriterium verfasst haben ...

Nein, ich meine wir sollten auf einer Sitzung des Ausschusses für barrierefreie Informationstechnik des BFIT-Bund das auf die Tagesordnung setzen, damit die Fragen, über die wir nur spekulieren können, an die Macher der EN weitergeben - bei den Untertiteln konnten wir so auch eine Klärung herbeiführen. Und diese Forderung nach eigenen Schriften findet sich nicht in den WCAG, so dass hierüber auch keine Hinweis zu finden sind, wie das gemeint sein könnte...

Was meinst du @sweckenmann - könnte das Sinn machen?

sweckenmann commented 2 years ago

@MarcHaunschild Wie ich weiter oben schon geschrieben habe, glaube ich, dass es praktisch nicht zu Problemen kommt in diesem Prüfschritt bzgl. Font Icons. Habe es bei einer Website gut eingebundenen Icons nochmal geprüft und erinnere einen solchen Fall auch aus der Vergangenheit nicht.

MarcHaunschild commented 2 years ago

@sweckenmann Na ja, es kommt aber immer wieder zu Diskussionen zu diesem Prüfschritt und die wiederkehrende Frage (wie bewertet man, wenn durch Einstellungen etwas nicht mehr funktioniert) ist nicht beantwortet. Ich habe das zuletzt nicht mehr ausschließlich auf Icons bezogen.

Aber ich kann auch gut mit einem Entscheidungsspielraum leben.

😉