Open sweckenmann opened 4 years ago
johannesFischer84
commented
3 years ago Würde das bedeuten, dass auch Font Icons mit Hexadezimalwert in der content-Eigenschaft versteckt werden müssen? Sind diese auch problematisch bei VoiceOver? Ich habe tatsächlich meist nur mit NVDA oder JAWS getestet.
detlevhfischer
commented
3 years ago Ich hatte kürzlich in einer QS keine Probleme bei nicht versteckten SVGs ohne title gefunden und geschrieben:
aria-hidden(kann man) bei in Links eingebundenen SVGs mit nebenstehendem Linktext grundsätzlich empfehlen (also anmerken)(...), auch wenn ich keine UA/AT Kombi bisher gefunden habe, wo es störend ausgegeben wird. Nur sollte man SVGs ohnetitle/description, die nicht versteckt sind, nur deswegen nicht als nicht-konform bewerten.
Ob es Probleme bei MacOS/Voiceover gibt, habe ich aber bislang nicht geprüft.
stefanFarnetani
commented
3 years ago Ich bin bisher davon ausgegangen, dass der Einsatz von icon-fonts aus Sicht der Barrierefreiheit ok ist, wenn die einzelnen Zeichen im sogenannten "Private Use Area" in der Schrift abgelegt wurden. Das sieht in CSS in etwa so aus: Content: "\e001"
Die Information, dass dennoch immer etwas vorgelesen wir unter bestimmten Screenreader-Konstellationen ist beunruhigend. Auch wenn icon-fonts nicht mehr state-of-the-art sind, werden sie noch sehr häufig verwendet. Das was beschrieben wird, würde heißen, dass man diese Technik überhaupt nicht einsetzen kann. Außer man hat ein aria-hidden als attribute verwendet. Das ist aber nicht immer möglich. Manchmal wird ja das Icon z.B. bei einem Link direkt über das CSS before- oder after-Element angehängt. Das setzten des aria-hidden attribute würde dann den ganzen Link entfernen.
Demzufolge müsste die klare Empfehlung sein, meidet die Technik. Wenn ihr sie einsetzt nur mit aria-hidden. ansonsten gibt es Abzüge: und zwar egal ob Entwicklungsbgleitend oder abschließender Test. Die unterschiedliche Bewertung je nach Test-Typ finde ich sehr schwierig und würde gar nicht damit anfangen.
Ich tue mir schwer einzuschätzen, ob es dafür Abzüge geben soll. Soll man einen Abzug geben, für einen Fehler, der nur in einen geringen Anteil an Screenreader-Konstellationen auftritt und es -meines Wissens nach- keinen failure dafür gibt, noch irgendein Standard der durch die Technik verletzt wurde. Ich bin da immer ein wenig auf Seiten des Programmierer. Woher soll er denn wissen, dass es auf irgendwelchen Geräten evtl. zu Fehlern führen kann. Anderes wäre es in meinen Augen, wenn ein klarer Verstoß gegen Standards vorliegen würde. Als Beispiel, um meine Ausführung zu untermauern möchte ich anbringen, dass es recht leicht passieren kann, dass ein komplexeres HTML Konstrukt in bestimmten Screenreader-Kombinationen zu unerwünschten Ergebnissen führt. Wir hatten hier bereits Probleme mit Links in Tabellen. Das leidliche Problem mit figure und figcaption. Ist das dann nicht ein screenreader-Bug? Nur damit dass nicht falsch verstanden wird, ich würde immer raten es dennoch zu ändern, aber ich muss ja irgendwo den Mindeststandard WCAG verteidigen. Wo hört man auf anzumerken? müssen wir am Schluss doch immer mit konkreten Screenreader testen? Fragen über Fragen. Ich bin gespannt auf eure Einordnung.
sweckenmann
commented
3 years ago Würde das bedeuten, dass auch Font Icons mit Hexadezimalwert in der content-Eigenschaft versteckt werden müssen? Sind diese auch problematisch bei VoiceOver?
Ich bin bisher davon ausgegangen, dass der Einsatz von icon-fonts aus Sicht der Barrierefreiheit ok ist, wenn die einzelnen Zeichen im sogenannten "Private Use Area" in der Schrift abgelegt wurden. Das sieht in CSS in etwa so aus: Content: "\e001"
Die Information, dass dennoch immer etwas vorgelesen wir unter bestimmten Screenreader-Konstellationen ist beunruhigend.
@johannesFischer84 und @stefanFarnetani Ich muss gestehen, dass ich nicht genau weiß, wie der aktuelle Stand ist. In allen Best Practice-Artikeln wird beschrieben, dass man das Icon verstecken soll, damit nicht evtl. was ausgegeben wird. Allerdings sind diese alle älteren Datums. Z.B. https://www.filamentgroup.com/lab/bulletproof_icon_fonts.html Hier wird auch auf Unicode und PUA eingegangen.
Es gibt eine WCAG-Technique im Entwurfsstadium, die aber nur im Wiki seit Längerem vor sich hin dümpelt... Ich konnte nicht rausfinden, warum sie noch nicht offiziell aufgenommen wurde: Using aria-hidden=true on an icon font that AT should ignore. @detlevhfischer weißt du dazu mehr? Wenn ich das richtig sehe, ist das Icon in dem Beispiel auch im PUA..
...Das ist aber nicht immer möglich. Manchmal wird ja das Icon z.B. bei einem Link direkt über das CSS before- oder after-Element angehängt. Das setzten des aria-hidden attribute würde dann den ganzen Link entfernen.
Man kann doch mit Hilfe eines span innerhalb des Links nur das Icon verstecken?
Woher soll er denn wissen, dass es auf irgendwelchen Geräten evtl. zu Fehlern führen kann.
Das Problem hat man beispielsweise auch mit ganz neuen ARIA-Techniken. Hier muss man dann entscheiden, ob eine Technik "accessibility supported" (siehe "Understanding Accessibility Supported" in Understanding Conformance WCAG 2.1) ist und damit zur Erfüllung eines Erfolgskriteriums geeignet ist. Aufgabe der Testentwicklung bzw. dieser Diskussion ;-)?!
Ich kann mit einem "eher erfüllt" (noch konform) leben, genauso, es nur als Anmerkung und Empfehlung aufnehmen, außer wir kommen zu dem Ergebnis, dass es tatsächlich nicht zu unerwünschten Ausgaben kommt. Andererseits berücksichtigen wir VO sonst auch nicht unbedingt (und ich vermute, dass es nur da zu Problemen führen könnte). Ich habe das Fass aufgemacht, weil ich in der QS sehe, dass die Umsetzung mit aria-hidden von vielen empfohlen wird, aber eben nicht von allen.
Aber einig sind wir uns denke ich, dass das nicht-Verstecken kein "fail" ist, wenn es keine anderen Probleme gibt.
johannesFischer84
commented
3 years ago Aktuell haben wir in Prüfung 1.1.1a stehen:
Falls für die Icons Text ausgegeben wird (z.B. content: "k"), prüfen, ob das Icon mit einer geeigneten Technik für Screenreader versteckt wird (z.B. aria-hidden="true").
An diese Regel halte ich mich auch bei der Prüfung. Das bedeutet, wird in der content-Eigenschaft wie von Stefan (@stefanFarnetani) genannt ein Hexadezimalwert angegeben (z. B. "\e001"), dann verlange ich in der Prüfung auch kein aria-hidden. Denn NVDA oder JAWS geben das zusammen mit Firefox oder Chrome nicht aus. Wenn jemand mit VoiceOver bei Hexadezimalwerten andere Erfahrungen hat, könnte man darüber diskutieren.
Von Stefan (@stefanFarnetani):
Ich tue mir schwer einzuschätzen, ob es dafür Abzüge geben soll. Soll man einen Abzug geben, für einen Fehler, der nur in einen geringen Anteil an Screenreader-Konstellationen auftritt und es -meines Wissens nach- keinen failure dafür gibt, noch irgendein Standard der durch die Technik verletzt wurde. Ich bin da immer ein wenig auf Seiten des Programmierer. Woher soll er denn wissen, dass es auf irgendwelchen Geräten evtl. zu Fehlern führen kann. Anderes wäre es in meinen Augen, wenn ein klarer Verstoß gegen Standards vorliegen würde.
Von Sonja (@sweckenmann):
Es gibt eine WCAG-Technique im Entwurfsstadium, die aber nur im Wiki seit Längerem vor sich hin dümpelt...
Ich finde, wenn man eine Nicht-Konformität bei einer so speziellen Prüfung annimmt, dann müsste man entweder selbst Probleme mit einer assistiven Technologie / Browser feststellen, wobei man z. B. VoiceOver als Grundlage des Auftretens eines Fehlers dann auch in der Testumgebung (Werkzeugliste) erwähnen müsste. Zusätzlich muss die assistive Technologie / Browser eine gewisse Relevanz haben, die ich bei VoiceOver aber als gegeben sehen würde. Alternativ gibt es eine WCAG-Technik zu der Problematik. Warum die eine Technik nur im Wiki der Working Group steht, hab ich mich irgendwann auch schon mal gefragt. Ich hab dann vermutet, dass das Problem wohl nicht wichtig genug war oder doch gar kein Problem darstellt.
Die Prüfung, ob Font Icons mit einer geeigneten Technik versteckt werden (aria-hidden) ist in der Prüfschrittbeschreibung derzeit sehr schwammig/kulant formuliert. Für eine einheitlichere Prüfpraxis schlage ich vor, insbesondere im Entwicklungsbegleitenden Test immer anzumerken, wenn das Icon nicht versteckt wurde, nicht nur wenn NVDA etwas kryptisches ausgibt (Probleme gibt es eher mit VO). Im Entwicklungsbegleitenden Test ist dies in der Regel nicht der einzige Mangel, daher für die Bewertung nicht entscheidend. Für den Abschlißenden Test bleibt zu diskutieren, ob dafür ein "Fail" gerechtfertigt wäre oder ob ein "eher erfüllt" ausreicht (sollte das das einzige Problem sein). Betrifft auch 9.1.1.1b und 9.1.1c.