search

public-ui / kolibri

The accessible HTML-Standard
https://public-ui.github.io
European Union Public License 1.2
173 stars 33 forks source link

🐞 Bug: Checkbox-Input Lesereihenfolge #7104

Open mweiershaeuser opened 1 day ago

mweiershaeuser commented 1 day ago

Link to the code that reproduces this issue:

https://stackblitz.com/edit/vitejs-vite-p3eaey?file=src%2FApp.tsx

Can you categorise where the error occurs?

React

Which browser or operating system do you used to test KoliBri?

Chrome

How to reproduce issue?

  1. Reproduktionsbeispiel öffnen und Screen Reader starten (NVDA)
    1. Seite mit Pfeiltastennavigation vorlesen lassen (Lesemodus)
    2. Anschließend über Felder mit Tab navigieren

Current vs. Expected:

Current Visuell ist sowohl bei der KoliBri-Checkbox als auch bei der HTML-Checkbox das Input-Feld links neben dem Label positioniert. Bei Navigation via Tab lesen sowohl die KoliBri-Checkbox als auch die HTML-Checkbox erst das Label und dann das Input-Feld vor. Bei Navigation mit Pfeiltasten wird bei der KoliBri-Checkbox zuerst das Label vorgelesen und dann das Input-Feld, bei der HTML-Checkbox hingegen erst das Input-Feld und dann das Label. Expected Die Lesereihenfolge bei Pfeiltastennavigation (Lesemodus) entspricht der visuellen Darstellung. Ist das Label rechts neben der Checkbox, sollte erst das Input-Feld und dann das Label vorgelesen werden, wie es beim HTML-Beispiel der Fall ist.

Environment informations:

Stackblitz, Chrome, Windows NVDA Screen Reader

deleonio commented 1 day ago

Hallo @mweiershaeuser,

vielen Dank für deinen Hinweis und das Aufwerfen dieses wichtigen Themas.

Das SOLL ist, dass das Markup der visuellen Darstellung entspricht. Meines Wissens liegt der Fokus darauf, sicherzustellen, dass CSS nicht verwendet wird, um die Reihenfolge der Inhalte so zu verändern, dass diese nicht mehr in der logischen Abfolge (z. B. von links oben nach rechts unten) für Screenreader wahrnehmbar sind.

Ein Eingabefeld besteht aus Sicht der Barrierefreiheit jedoch immer aus einem Label, einem Input-Feld und ggf. weiteren Elementen. Diese sollten als Einheit betrachtet werden. Ob innerhalb der Komponente das Label vor oder nach dem Input-Feld gelesen wird, sollte der Barrierefreiheit keinen Abbruch tun, solange die logische Verbindung gegeben ist.

Ein Fehler wäre es allerdings, die Inputs beispielsweise am Ende des Dokuments zu platzieren und sie nur visuell als Suchfeld oben anzuzeigen.

Die von KoliBri entwickelten Elemente sind in sich vollständig und barrierefrei gestaltet. An der Stelle, wo sie verwendet werden, sind sie semantisch korrekt und für sich barrierefrei. Eine kleine Abweichung im Detail sollte daher immer in Relation betrachtet und bewertet werden.

@Chrisdo82, @AntnSaj: Ich würde euch bitten, hier ebenfalls eine Stellungnahme abzugeben. Hinterfragt auch gerne meinen Ansatz und zieht, falls möglich, Rückmeldungen von Screenreader-Nutzenden hinzu.

deleonio commented 1 day ago

Was wir machen können:

FYI @Makko74 könntest Du sowas beim Refactoring der Input-Komponent berücksichtigen?

mweiershaeuser commented 1 day ago

grafik

mweiershaeuser commented 1 day ago

Im gemeinsamen Gespräch ist aufgefallen, dass das Label und das Input-Feld im Lesemodus separat ausgegeben werden (zweimal Pfeiltaste drücken) während es bei der Verbindung des reinen HTML-Labels mit -Input zusammen vorgelesen wird.

deleonio commented 1 day ago

Wir müssen schauen, wieso bei uns Label und Input beim Lesemodus getrennt vorgelesen wird. Im reinen HTML wird es immer im Zusammenhang vorgelesen.