[Accessibility] Datepicker days don't respond to "enter" keypress

[cjcenizal]

You can tab to a day in the datepicker, but when you hit "Enter" the focus reverts to the calendar element. Instead, the date should be selected, the same as if the user had clicked on it.

This applies to the months and years too.

[timroes]

The keyboard navigation of the datepicker currently seems a little bit "broken" in general.

If you navigate using the arrow keys, you won't see any highlights, but it will store the date you currently navigated internally and pressing enter will activate that date.

Since not highlighting the current focus is bad usability in general, I would suggest the following:

When using the keys to navigate, also focus the button, for the target date. Pressing enter wouldn't then need any special treatment, since the button is already focused. That way it would also work when using tab to let the browser navigate through the buttons.

There is a huge disadvantage: we cannot focus disabled buttons. Meaning we could not navigate outside the valid date range. It might not look like a bad thing, let's just say we stop at the borders of validity, but it's not as easy as that. It would also mean, that the user cannot press page-up/down anymore, if the previous/next month isn't inside the valid range. This would feel very weird, especially if the boundary of valid dates is at a month boundary, and you cannot see a reason, why it wouldn't let you select the next month by keyboard.

So if we don't move focus, we have the problem, what how the enter key behave? If the user focused something by tab, we need to activate that button; but if she used arrow keys and we need to activate that internal stored date (still we should highlight it before somehow!). What if she pressed tab multiple times, and than navigated using arrow keys? She would have two selections, which one should be activated on enter?

Maybe the mix of both might be the best solution: We move the focus as long as we can (i.e. are in the valid date range), and use an internal navigation if and highlighting of buttons as soon as we can't anymore, because we are selecting invalid dates.

Nevertheless, the way the datepicker is currently built, it will require quite some refactoring e.g. in the id calculation, to make it more predictable for a given date.

But we should first decide on an actual user interaction pattern, that we now want to implement. What are your thoughts on the topic?

[lukasolson]

Suppose for a second that we removed the special handling of arrow/page keys, and we fixed the focus/enter bug. The date picker would then be fully functional and keyboard-accessible, correct?

Obviously, using tab/shift+tab to navigate through a list of dates can be annoying, which I think is where the arrow keys come into play. In my opinion, the arrow keys should simply be an easier way to move the focus. They shouldn't automatically switch months, and they should even allow you to move the focus to the month selector and previous/next month buttons.

The page up/down keys should act like the previous/next month buttons. If you use them to switch months, I think it makes sense to move the focus to the month selector rather than try to select the same date from the previous/next month. From there, you can use the tabs/arrow keys to select the date.

Does this make sense? Can you think of any gotchas?

[timroes]

Thanks a lot for that feedback.

Yeah if we would just remove the special arrow key handling, everything would be accessible (or at least can be made accessible very fast).

I totally agree with you, that this custom behavior adds a lot of usability (for all kind of users). So I rather wouldn't remove it. I think we could make this work as you suggested with the following steps:

• Remove the automatically switching of month when using arrow keys
• Jump to the month button when using page up/down, instead of same date in the new month
• Use the arrow keys to move the focus to the button (instead of using the internal date variable - so that Enter will always work no matter if you use Tab or arrow keys)
• And thus don't allow to navigate to disabled days with arrow keys (since they are not focusable)

Do you think these changes are reasonable and would leave is with a good usability (and also accessibility)?
If so I or one of the original devs of the date picker could implement that.

[timroes]

We are currently looking into replacing the current datepicker completely, see #13525. So further fixing and refactoring of the old datepicker will be postponed, till we made a decision regarding a new React datepicker.

[timroes]

As discussed yesterday, we will for now just remove custom keyboard navigation in the currently used Angular UI datepicker, and will look into a replacement datepicker in #13525 .