HTML date input and SC 1.3.1

[pete-murphy]

We are seeing reports that <input type="date"> fails 1.3.1 Info and Relationships (Level A) because of some screen reader-related issues:

• Screen readers (specifically JAWS) read the date in a format that's different from what's displayed on screen (JAWS reads year first, but the visually-rendered format is MM/DD/YYYY)
• JAWS announces two slashes after selecting a date from the date picker popover
• JAWS announces "date time, edit" when it encounters the <input type="date"> (instead of "date, edit")

I've personally noticed on VoiceOver on Mac that the HTML date input reads very strangely, at least on Chrome ("minus nine point one percent, month of date, ..."). However, I'm surprised that this basic usage of HTML would be non-compliant, regardless of poor screen reader support.

Does use of <input type="date"> fail SC 1.3.1, and if so is there a recommended alternative?

[pete-murphy]

Some guidance I've found: https://www.hassellinclusion.com/blog/input-type-date-ready-for-use/.

That includes a favorable report of using with JAWS with Chrome. It seems like the outlier was Safari, but the situation there seems to have improved since the article was published (2019). General support for <date input="text"> seems to be pretty good on Safari in general, and particularly for VoiceOver on Safari.

[pete-murphy]

General support for <date input="text"> seems to be pretty good on Safari in general, and particularly for VoiceOver on Safari.

Looks like there are still some issues with Safari. Also found a more up-to-date article: https://adrianroselli.com/2019/07/maybe-you-dont-need-a-date-picker.html

So it seems like the consensus is that there are still some issues with <input type="date">, but I'm unclear if any of the issues constitute a failure for 1.3.1.

[patrickhlauke]

I would say that strictly, this falls under "accessibility supported" considerations. the markup/use of the input per spec is correct, so in my mind doesn't fail 1.3.1, so nominally it passes ... but to make it actually usable/accessible right now, authors MAY still need to use alternative approaches

[mraccess77]

Browser based error messages can also fall into this category as well - typically pass a criterion but if there is not accessibility support then the technique can't be relied up until the support is there for the AT you claim conformance to.