Barrierefreiheit der nativen Datumsfelder

[binarious]

InputDate wurde als natives input type="date" implementiert und als "Die Komponente ist BIK BITV getestet." deklariert. Welche Prüfschritte wurden hier durchgeführt, die zur Verwendung des nativen Date-Inputs in diesem Projekt geführt haben?

Ich durfte kürzlich einen BITV-Test begleiten, bei dem die Prüfer die nativen Datumsfelder bemängelt haben. Interessant sind dazu auch https://a11ysupport.io/tech/html/input(type-date)_element oder https://www.hassellinclusion.com/blog/input-type-date-ready-for-use/.

[deleonio]

Vielen Dank @binarious ,

wir testen alle Komponenten nach der BITV 2.0, jeweils nach den anwendbaren Prüfschritten. Eine Excel mit den historischen Prüfergebnissen ist im Repo enthalten.

Ich freue mich sehr über Ihre Frage - wir schauen uns die Idee an.

@ElVariablo, @cbraehmig

[cbraehmig]

Hallo @binarious,

wie von @deleonio bereits erwähnt, unterziehen wir alle Komponenten einem Test, der sich sehr stark am BIK BITV-Test orientiert.

Im Projekt verfolgen wir die Strategie, wenn möglich die nativen UI-Element zu verwenden. Nur so kann ein erwartungskonformes Verhalten der Elemente plattform- und browserspezifisch gewährleistet werden. Das damit die Umsetzung der Anforderung an die Barrierefreiheit primär bei den Herstellern liegt, ist uns durchaus bewusst. Aber nur so kann den Anwendenden ein gewohntes Verhalten in der technischen Umgebung geboten werden.

Und gerade der Blick auf das "InputDate"-Element zeigt, wie stark die Zugänglichkeit der Komponenten vom Browser, den eingesetzten assistiven Technologien und auch deren Versionen abhängig ist. Ein Großteil der Browser erfüllt bereits die Anforderung an die Barrierefreiheit. Um die Lücke der Zugänglichkeit zu schließen, müssten browserspezifische Anpassungen vorgenommen werden, die wiederum neue Probleme hinsichtlich der Barrierefreiheit mit sich bringen.

Die Interpretation des Accessibility-Tree des HTML ist Grundlage zur Verarbeitung für die assistiven Werkzeuge. Deshalb ist die Verwendung semantisch korrekten (nativen) HTML eigentlich alternativlos, auch um die Zukunftssicherheit zu gewährleiten.

Wir hoffen, dass wir unseren Ansatz an dieser Stelle erläutern konnten und wir sind immer an einem regen Austausch interessiert. Vor allem interessiert uns, welche Prüfschritte konkret im Bezug auf das Element bemängelt wurden.

[binarious]

Hallo @cbraehmig,

vielen Dank für die Ausführungen. Ich markiere diesen Post dann als Antwort, da meine grundlegende Frage beantwortet wurde.

In dem von mir verfolgten Test wurde das Datumsfeld beim Prüfschritt "9.1.3.2a Sinnvolle Reihenfolge" mit dem Hinweis bemängelt, dass Datumseingaben nicht mit dem Screenreader bedienbar seien und die Kalenderansicht mit der Leertaste geöffnet werden könne, diese dann aber nicht zu bedienen sei.

Interessant ist natürlich auch die Frage, ab welchem Punkt man aus Sicht der BITV oder dem entsprechenden Landesgesetz als barrierefrei gilt. Insbesondere, ob die Verwendung von potenziell barrierefreien Techniken, wie zum Beispiel dem nativen Datumsfeld, ausreicht, obwohl die Implementierung in den Browsern und/oder assistiven Technologien ggf. noch lückenhaft oder gar unbrauchbar ist. Zumindest Narrator, Orca und VoiceOver (iOS) scheinen da noch beim Datumsfeld problematisch zu sein. Schwierig natürlich für öffentliche Stellen, die häufig einen BITV-Test in Ausschreibung fordern, wenn diese dann an einen BITV-Tester geraten, der die lückenhaften Varianten zum Testen heranzieht.

[ElVariablo]

Hallo @binarious,

die von dir beschriebene Problematik mit dem Datumsfeld konnten wir in einem Nachtest leider nicht reproduzieren. Wir werden das Verhalten aber noch einmal genauer untersuchen.

Die Problematik der unvollständigen Umsetzungen der Standards in den verschiedenen Browsern und assistiven Technologien sehen wir ebenso. Um unsere Komponenten zu testen, orientieren wir uns daher an den technischen Rahmenbedingungen des BITV Tests. Das es Konstellationen gibt, in denen selbst die Verwendung nativer HTML Elemente zu Problemen führt, ist uns aber bewusst. Man kann eigentlich nur hoffen, dass möglichst zeitnah alle Browser die Standards erfüllen, um die beschriebene Problematik zu vermeiden.