Frage zu 9.1.4.4, 11.7, 9.1.4.12: Textgrößenanpassung in Auswahlmenüs mit Filter

[MaiKnie]

Moin,

ich habe eine Frage allgemein zu Auswahlmenüs mit Filter bzw. Dropdownlisten. Müssen die Textinhalte von solchen Liste sich auch anpassen, wenn gezoomt wird, die Schiftgröße im Browser angepasst wird oder die Laufweite anders eingestellt ist, also die Prüfschritte 9.1.4.4, 9.1.4.12 und 11.7?

Konkret geht es um dieses Beispiel einer Datatlist, ob man diese als barrierefreie Umsetzung nehmen könnte: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/datalist?retiredLocale=de

Hier wird schon erwähnt: "The font size of the data list's options does not zoom, always remaining the same size. The contents of the autosuggest do not grow or shrink when the rest of the contents are zoomed in or out."

Ist dass damit ein K.O. Kriterium für die drei Prüfschritte als nicht bestanden oder beziehen sich diese nur auf Fliesstexte im allgemeinen?

[stefanFarnetani]

Hallo @MaiKnie

Prinzipiell beziehen sich alle drei Prüfschritte auf das gesamte digitale Produkt; also auch Bedienelemente.

Es ist sehr ärgerlich, dass das datalist-Element, als HTML-Standardelement, nicht barrierefrei ist. In über 90% der Fällen ist HTML von Natur aus barrierefrei. Es lohnt sich also immer native HTML Elemente zu nutzen. Wir haben aber ein paar Elemente, die es immer noch nicht barrierefrei sind. Neben der datalist, ist es z.B. der datepicker und die Formularvalidierung (die anderen Elemente haben andere Probleme).

Ich komme ja aus der Umsetzung und es tut mir in der Seele weh; aber leider müssen die Prüfschritte als nicht bestanden bewertet werden, wenn datalist verwendet wird. Die Konsequenz ist, dass man entweder mit den Fehlern vorerst lebt (mit der Konsequenz, dass der Test negativ ausfällt) und hofft, dass sich die Browserhersteller irgendwann bewegen. Oder aber man muss die datalist Funktion selbst nachbauen. Was mehr Flexibilität bietet aber auch größere Gefahren weitere Barrierefreiheitsprobleme zu erzeugen.

Eine, wie ich finde, besch* Situation. Aber in meinen Augen leider ein fail.

[Andreas-Englisch]

Siehe: https://issues.chromium.org/issues/40720829

[MaiKnie]

Danke für eure Rückmeldungen.

Ich hab diesen Artikel hier noch an die Hand bekommen: https://www.webaxe.org/datalist-over-aria-combobox/

Das ist ja dann eine Grundsatzentscheidung, wie du schreibst @stefanFarnetani
Entweder man bastelt sich eine custom Komponente aufwändig zusammen, die die Prüfschritte hoffentlich erfüllt, oder benutzt lieber out-of the-box HTML Code und wartet ab bis sich was tut. :-)

[johannesFischer84]

Vor einigen Jahren war das <select>-Element auch noch nicht komplett barrierefrei. Beispielsweise war der Standardkontrast von markierten Elementen mit weißer Schrift auf blauem Grund nicht ausreichend. Inzwischen ist das behoben, wie ich auch gerade gesehen habe. Ich denke, früher wurde <select> trotzdem akzeptiert, weil es für Entwickler ohne aufwändige Eigenentwicklung keine barrierefreie Alternative gab und weil es eben nicht am Entwickler, sondern an den Browserherstellern lag. Wo jetzt <datalist> nicht barrierefrei ist, gibt es zumindest mit <select> eine passende Alternative ebenfalls in nativem HTML. Mit dieser Begründung würde ich auch sagen, dass die Nutzung von <datalist> aktuell als nicht konform zu bewerten ist.