Per email discussion, we decided that we still like the library that is currently used and rather than look for a new one or implement our own, we will contribute upstream to fix the issues noted.
See Hacker0x01/react-datepicker#1371 / All open accessibility issues for react-datepicker

Per @timroes:
I've been looking a bit into what would needs to be done, and I think we would have to fix the following items, with a very rough time estimation. This estimations are really rough, since I a) don't know the libraries source code or testing framework, and b) I don't know how much these different modes we are not actually using, might influence that effort.

Properly label the existing keyboard navigation
The datepicker already has a rather good keyboard navigation for basic date selection. But it's terribly labeled via ARIA (each day just has the label day-3, day-4, etc. This task would involve properly label that existing functionality. Since the focus stays on the original input while navigating the datepicker this means using aria-activedescendant on the original input, labeling and describing all dates properly; adding proper description when opening the datepicker to explain its usage, etc.
Since this will require setting props of the trigger element (which I think the datepicker does not do right now), this might require some changes. Also aria-activedescendant can be a bit tricky to use, so this task will involve a lot of testing on different assistive technologies.
Estimated time: 4-6 days
Making the time picker accessible
Unfortunately the time picker is currently not keyboard accessible at all. So we would need to build a keyboard mechanism to use it, e.g. having a hotkey (like pressing Tab, or something else, would need to evaluate if Tab could be a good choice here actually) to switch from date to time selection and then being able to press up/down to navigate through the times. This of course would also require using aria-activedescendant and proper labeling in that. In contrast to the above, this would also benefit non assistive technology users, by a general improved keyboard navigation.
Estimated time: 4-6 days
Fix custom input keyboard accessibility
When using a custom input like in the EUI example with a button, keyboard accessibility doesn't work at all anymore. This should be fixed, but I am absolutely not sure if we could fix this (or at least improve it) via the library, or if this is something we need to fix this in EUI. Also it could be, that this will be hard to get working properly, since aria-activedescendant is super picky about the role of the element it is set on - I had some real fun doing the timelion multiline input with that one :-/
Estimated time: no idea, since I can't even say it's properly solvable with the mechanisms above, and at least require tons of testing for different elements
Support month/year navigation
You can currently click on the month and the year, to jump to a selection of years and months. That makes it way easier to select dates far away from today. This functionality is not keyboard accessible at all and this task means giving somehow access to them and make them work properly with ARIA, since this is the classical case of context switches, that are sometimes hard to do properly. I think this task would be optional and could also if wanted be done at a later point, because we are able to select all dates already beforehand, it's just super cumbersome to select dates like 5 years ago, with a keyboard with this feature :-)
Estimated time: 2-5 days

It might be that I am missing some tasks, but that are at least the high level tasks, that I would see.

Date picker accessibility #793

Description

Metadata

Metadata

Assignees

Labels

Type

Fields

Projects

Milestone

Relationships

Development

Issue actions