React-datepicker: Accessibility: Calendar is not completely accessible with keyboard navigation

[greg-a-smith]

Expected behavior

When the calendar is visible, a user should be able to access any of the controls (_e.g._ dates, month/year selection, previous/next month/year, Today button, etc.) with keyboard navigation.

Actual behavior

Although the arrows keys do change the highlighted date, the calendar overlay itself is not accessible by keyboard navigation.

Steps to reproduce

Go to https://reactdatepicker.com and tab into the first input so the calendar appears.

Suggested direction

In order for the input, the calendar and the time picker to all be properly accessible with keyboard navigation, they need to be decoupled and broken into separate components. The browser focus actually needs to move from one control to the next so proper key handling can be achieved. The overlay also likely needs to be linked to a trigger button rather than simply tied to input focus. When showing an overlay to pick both date and time, it needs to include some form of OK/Cancel buttons since multiple selections can (and need to) be made.

We are interested in continuing to use react-datepicker, but we need to make these suggested changes in order to stay compliant. Our team is willing to help work through these issues (this one plus #1369 and #1370) with multiple pull requests, if you are open to it.

[aij]

As a frequent keyboard user, I appreciate your intentions, though your conclusion seems to be based on a common misunderstanding. All of the functionality needs to be accessible via the keyboard, and it is better to make that functionality readily keyboard accessible rather than forcing keyboard users to use controls that were designed for mousers. The keyboard UI should be designed for a keyboard, not for a mouse.

I do think there is certainly room for improvement. Ideally, the date picker should be strictly better than plain input for selecting a date, for all users.

Repurposing existing keybindings does mean we lose some of the functionality of a plain text box, but it also makes the bindings discoverable. Since dates tend to be pretty short, losing the ability to navigate within those 10 entered characters seems like a reasonable trade off for being able to more easily change the day/month/year. Is there a way the ease of use / discoverability / functionality trade off here can be improved? (Rather than just tilting more in one direction than the other?)

The overlay also likely needs to be linked to a trigger button rather than simply tied to input focus.

How would a user discover how to trigger the calendar to open? For mouse users, the calendar opens as soon as the click the input field to enter a date. Why shouldn't the calendar also open when a keyboard user focuses the input field to enter a date?

The browser focus actually needs to move from one control to the next so proper key handling can be achieved.

I agree, though I will point out that from a UI perspective, the datepicker is one control. If I tab to a date picker, and then press tab again, focus should go to the next control, just like it does with regular input boxes, checkboxes, radio buttons, select inputs, and even texareas.

Perhaps the scrollbars on these textareas (if you write a github comment) are a good example of how not every visible/clickable position needs to be focusable. The scroll up arrow, scroll down arrow, drag bar, and throughs can't be selected with the keyboard, but equivalent functionality is available via arrow keys/page up/page down/ctrl+home/ctrl+end or whatever other keybindings your browser may support.

[bcullman]

@aij

The browser focus actually needs to move from one control to the next so proper key handling can be achieved.

I agree, though I will point out that from a UI perspective, the datepicker is one control...

As soon as Hacker0x01 offered the datepicker with a date AND time control, it becomes 2 controls, because you cannot choose a date and time in a single selection.

Because of this, you need the ability to navigate between the date picker portion of the control and the timepicker portion of the control (which currently is inaccessible - see #1370). Tab would be ideal for this, but currently it is tied to the field.

Opening a calendar control via a button, allows the controls for the calendar and the time to be focus-trapped, where the tab key can toggle between setting the date, and setting the time. And, perhaps in a later iteration, setting the date, hour, minute, second, and am/pm).

We can retain the existing keyboard navigation for when we are just dealing with a date, but when a date and time are involved, you NEED the ability to tab between setting each independently.

[snide]

@greg-a-smith Let me know if you get started on this. My team would like to help out as well.

[greg-a-smith]

@snide Thanks for the note. I will be sure to reach out to you. I was hoping to get a little more traction on the issues we logged, but we may end up just starting and then let the discussions ensue in the pull requests.

[aij]

@bcullman We don't use the time part, and I'm not sure Hacker0x01 does either...

I agree that makes things complicated though, especially since not only can you have separate date and time inputs, but you can also have a unified datetime input.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.