[a11y]: Date picker lacks documented keyboard equivalents for month and year changes

[mbgower]

Package

@carbon/react

Browser

Chrome

Operating System

MacOS

Package version

https://react.carbondesignsystem.com/?path=/story/components-datepicker--simple

React version

https://react.carbondesignsystem.com/?path=/story/components-datepicker--simple

Automated testing tool and ruleset

n/a

Assistive technology

keyboard

Description

In a native HTML date type input, each of the parts of a date (the day, month and year) receive a separate tabstop inside the input

Screen.Recording.2022-07-13.at.3.59.46.PM.mov

However, Carbon has implemented the data picker with a single tab stop in the input (although the time input retains the granular tabstops for am/pm and timezone).

This isn't necessarily a problem, but there is one critical consideration from an accessibility perspective. In the native HTML input, the user can adjust months or days with arrow keys simply by tabbing to that portion of the input.

Screen.Recording.2022-07-13.at.4.14.07.PM.mov

Since Carbon does not offer this simple ability to adjust month and year by keyboard, it needs to provide equivalent facilitation. Unfortunately, the left and right direction buttons < > which can be clicked with a pointer to adjust months are not reachable by keyboard. Further, the up/down incrementers that appear beside the year are not operable by keyboard either (or at least I couldn't figure out how to do it).

Thus Carbon's Date picker calendar variant has arguably failed 2.1.1 Keyboard; it lacks equivalent facilitation since there is not an easy way for a keyboard user to see what day of the week any specific date falls -- at least anywhere outside a range of, say, the currently displayed month and the preceding and following ones. (Note: Users can always directly enter a date, so the default simple date input variant can be considered passing -- once Carbon resolves its endemic inaccessible date mask, another issue I will be raising.)

---

Approaches

There are a few different ways Carbon can resolve (ordered, IMO, from least to most useful):

1. Return to the 3-tab stop implementation for the date input done by native HTML
2. Introduce keyboard shortcuts to adjust by year and month (historically Pgup/PgDn and Shift+PgUp/PgDn) AND surface the shortcuts to users.
3. Add an additional tabstop inside the calendar on the month/year text, at which point the arrow keys could be emphasized to show that the left/right arrows adjust months and the up/down arrows adjust years. Then a second tab stop would reposition users on the grid in the calendar. I believe this could be a quite elegant solution.

Until this is resolved, it seems to block an ability to update the accessibility guidance for Date picker.
There are a number of other important issues/ considerations, but this one is being opened separately since it impedes progress on the documentation project.

WCAG 2.1 Violation

2.1.1 Keyboard

Reproduction/example

https://react.carbondesignsystem.com/?path=/story/components-datepicker--single-with-calendar

Steps to reproduce

1. Open https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/date

2. Position the focus on the the input. Press the up/down arrows to modify the value

3. Press Tab and Shift+Tab to reposition the focus between the mm dd and yyyy. Repeat 2

4. Open https://react.carbondesignsystem.com/?path=/story/components-datepicker--single-with-calendar

5. Tab to the date input. With a mouse, select the < > on either side of the month/year text.

6. With a ouse, select the increment button with the pointer to adjust year.

7. Attempt to adjust the value by month of year using only the keyboard

Code of Conduct

• I agree to follow this project's Code of Conduct
• I checked the current issues for duplicate problems

[mbgower]

In addition, I'll mention that the React implementation of the calendar date picker opens on focus and cannot be dismissed.

Carbon departs significantly from this stock HTML interaction, in the following ways:

1. The calendar opens on focus
2. The calendar does not close on loss of focus
3. The calendar cannot be closed by pressing Esc from the date input

The above three items compounded constitute a real possible problem for keyboard users. The calendar could be covering other content info and there is no apparent way to dismiss.

It IS closed when the keyboard is in the calendar itself and Esc is pressed
4. The date input takes only one tab focus (not in itself a show-stopper)

Given the fact it also lacks a keyboard method of iterating by month or year, this constitutes a clear keyboard failure and substantial lessening of the stock html date input functionality.

[dakahn]

Flatpickr (the underlying library we use to render our calendar) has undocumented keyboard support for manipulating both the year ( CTRL/CMD + UP/DOWN) and the month(CTRL/CMD + LEFT/RIGHT)

that said this seems to work as intended on Windows only and clash with OS level desktop switching controls on macOS last I checked.

@mbgower I updated the issue title to reflect this

[tay1orjones]

This is probably something we'll need to defer into the next iteration of DatePicker, #11967

[mbgower]

That's fine, @tay1orjones; however, I wanted to make sure that you folks have captured the separate issue for the React implementation mentioned in this comment above as a separate higher priority issue. Should be a relatively easy fix -- just put in a collapse/dismiss on Esc.

[grahamharper]

Our product suffered from the a11y issues with DatePicker mentioned in this defect so we had to patch the component locally to address them and meet customer a11y requirements.

Would Carbon we willing to accept these fixes if we were to get a PR together? Is there any point if the component is being totally rewritten for v12?

Roughly when might we expect the new rewrite/v12?

[mbgower]

@tay1orjones did you ever check in with @grahamharper on their offer?
The v12 date picker was turned into a discussion last August, and received juar one comment last September, so I'm curious what the timing/status is.

[mbgower]

DA noted the undocumented keyboard interactions for month and year navigation last year in a comment, but also said:

that said this seems to work as intended on Windows only and clash with OS level desktop switching controls on macOS last I checked.

I have just confirmed that on Mac, Ctrl+Cmd+ arrow keys works on at least Chrome, so I am retitling this issue one more time. I believe by documenting this on the accessibility tab, we have some level of defence that the keyboard interaction is now.

Once I have that documentation in place, I believe this can be down-graded to a sev 3.

[OleksandrDzindziura]

Hey! Any updates about it?