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

9.2.1.1 Tastaturbedienbarkeit mit Screenreader an und aus #79

Open detlevhfischer opened 3 years ago

detlevhfischer commented 3 years ago

Ein Punkt, der gelegentlich verschieden bewertet wird, tritt auf, wenn Elemente bei abgeschalteten Sxreenreader tastaturnutzbar sind, nicht aber mit eingeschaltetem Screenreader (zumindest nicht in manchen Screenreader/Browser Kombinationen). So sind etwa die mit div und tabindex="0" umgesetzten Akkordeon-Ausklappbereiche auf Seite https://www.diabinfo.de/vorbeugen/bin-ich-gefaehrdet/wie-hoch-ist-mein-risiko-fuer-typ-2-diabetes.html in Chrome und Firefox mit NVDA (und in Chrome mit JAWS) nicht aktivierbar, nur wenn man zusätzlich die ALT-Taste (oder bei NVDA auch die NVDA-Taste) drückt. Mit Edge / Sprachausgabe geht's. (Auch der aria-expanded-Zustand wird nicht zuverlässig ausgegeben, aber das ist ein Thema vonn 9.4.1.2 Name, Rolle, Wert). Frage also:

sweckenmann commented 3 years ago

Ich habe mal auf die Schnelle (!) mit JAWS und NVDA (jeweils mit Chrome und FF) getestet. Ich kann mit beiden SR ein- und ausklappen.

Was nicht funktioniert:

Ganz häufig ist die Ursache der Diskrepanz in der falschen Umsetzung der ARIA Rollen und Attribute zu suchen (nach meiner Erfahrung): Häufig der falsche Einsatz von aria-hidden. Auch bei den Widgets (combo box etc.) hängt es oft am falschen Einsatz von ARIA. In der Folge kann es sein, dass der SR nicht in den Formular/Anwendungsmodus springt.

Ich finde auf jeden Fall, dass man NICHT davon ausgehen sollte, dass die Nutzenden den Trick kennen sollten, explizit den Modus zu wechseln. Wir testen ja hinsichtlich Konformität und mit Tricks können Nutzende ja alles mögliche machen. Es sollte korrekt umgesetzt sein.

mayerhh commented 3 years ago

Die Modi virtuell und Formular sind seit jeher ein zentrales Bedienkonzept für alle Windows basierten Screenreader. Die automatische Umschaltung gibt es noch gar nicht so lange und es treten immer wieder Probleme dabei auf. Ich würde deshalb nicht sagen, dass es sich um einen Trick oder Geheimwissen handelt, wenn der Modus gewechselt wird.

Aber zur eigentlichen Frage: Da die Probleme i.d.R. durch falsche ARIA-Rollen oder Zustände eingeschleppt werden, erscheint es mir unlogisch das bei der Tastaturbedienung zu bewerten. Das sind nur die Symptome. Die Quelle des Übels ist Name, Rolle, Wert. Daher würde ich das auch nur dort bewerten wollen.

Das Beispiel funktioniert hier mit Jaws 2021 und Edge (Chrome) übrigens problemlos (aria-expanded wird aber auch nicht ausgegeben).

sweckenmann commented 3 years ago

Die Modi virtuell und Formular sind seit jeher ein zentrales Bedienkonzept für alle Windows basierten Screenreader. Die automatische Umschaltung gibt es noch gar nicht so lange und es treten immer wieder Probleme dabei auf. Ich würde deshalb nicht sagen, dass es sich um einen Trick oder Geheimwissen handelt, wenn der Modus gewechselt wird.

Wenn für eine standardkonforme Umsetzung dieser Wechsel nicht nötig ist, dann kann ich nicht nachvollziehen, warum man hier sagen sollte, "das wäre auch okay". Gerade bei dem Beispiel Akkordeon ist eine funktionierende Umsetzung ja möglich.

stefanFarnetani commented 3 years ago

Eine wirklich spannende Frage.

Im konkreten Beispiel scheint zusätzlich ein Umsetzungsfehler (kein Button, verletzung des ARIA-Pattern) gemacht worden zu sein, wie @sweckenmann bereits erwähnt hat. Dementsprechend bin ich auch für die Einordnung des fails in 9.4.1.2 Name, Rolle, Wert.

Aber Lösen wir uns vom diesem Beispiel. Es gibt immer wieder Situationen in denen alles richtig umgesetzt wurde (Quellcode und Tastatur-Pattern). Und dennoch funktioniert es in einem bestimmten Screenreader/Browser-Kombination nicht. In der accessiblity baseline des BIK-Test legen wir nicht fest Alles mit einer bestimmten Assistiven Technologien und Browser zu testen (das wäre aufweniger). Wir testen stichprobenhaft mit Screenreadern, bevorzugt NVDA. So habe ich das bisher verstanden. Deshalb bin ich der Meinung, dass wir das nicht als fail einstufen können. Nochnmal: Vorausgesetzt es ist alles standard-konform umgesetzt worden und es funktioniert in anderen screenreadern.

Anders ist es wenn z.B. eine Software die Unterstützung einer konkrete Screenreader/Browser-Kombination festlegt. Dann kann man das genau Testen und danach auch bewerten. Damit ändert man die accessibility baseline.

Wir wollen im BIK-Test eine möglichst breite Unterstützung testen. Wie sollen wir den entscheiden welche Kombination es wert ist getestet zu werden? Nach Marktanteilen und Nutzerzahlen? Dann müssten wir bereits jetzt viele der Websites eher mit TalkBack und VoiceOver testen und nicht mit Desktop Screenreader. Je nach Website ändern sich die Zusammensetzung der Nutzer außerdem.

I postuliere jetzt etwas mutig: Standard über Implementierung (damit meine ich wie es vom screenreader schlussendlich ausgegeben wird).

Bei einer standardkonformen Lösung besteht die Möglichkeit, dass auch der Screenreader, der aktuell noch ein Problem hat, dies demnächst löst.

mayerhh commented 3 years ago

Wenn für eine standardkonforme Umsetzung dieser Wechsel nicht nötig ist, dann kann ich nicht nachvollziehen, warum man hier sagen sollte, "das wäre auch okay". Gerade bei dem Beispiel Akkordeon ist eine funktionierende Umsetzung ja möglich.

Ich habe nicht gesagt "es ist okay", Es gehört zur Bedienung eines Windows-Screenreaders dazu die unterschiedlichen Modi zu kennen und bei Bedarf (z.B. wenn die automatische Umschaltung nicht funktioniert) hin- und herzuschalten. Deshalb kann man nicht von einem Trick reden.

Im Übrigen glaube ich, dass Standardkonformität uns bei der Lösung der ursprünglichen Frage nicht weiterhilft. Wenn das maßgeblich ist brauchen wir doch gar nicht mit Screenreadern oder anderen Hilfsmitteln testen? Und welche Standards gelten überhaupt für komplexe ARIA Widgets? Die ARIA Authoring Practices sind toll und hilfreich aber nicht normativ.

sweckenmann commented 3 years ago

Ok, vielleicht ist Trick nicht die richtige Ausdrucksweise.