[a11y]: Datepicker opens calendar on focus, but does not dismiss on loss of focus; also cannot dismiss with Esc

[mbgower]

Package

@carbon/react

Browser

Chrome

Operating System

MacOS

Package version

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

React version

No response

Automated testing tool and ruleset

n/a

Assistive technology

No response

Description

I'm spinning this issue off from the larger issue on keyboard affordances in the datepicker, #11800. It looks like that work will be rolled into the V12 datepicker update; however, I think the on-focus behaviour is different enough, and of a higher order of disruption, that it should be given its own assessment and a higher priority, especially if the v12 datepicker release isn't impending.

The following is pretty much what I documented in a comment in the other issue back in July.

Carbon's react implementation of a date input with a calendar departs significantly from this stock HTML interaction, in the following ways:

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

These 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, however, it is not intuitive or consistent how a user moves from the input to the calendar.

1. The date input takes only one tab focus. When the user presses Tab again, focus moves to the next item.
2. The user needs to press the Down arrow to move to the calendar. This isn't a traditional operation.
3. As well, the user has to Shift+Tab to get back to the date input, even though the user did not Tab to get to the calendar.

The solution to this issue is fairly simple:

1. If you are going to have the date picker appear on focus of the date input, make it dismissible with Esc from the date input
2. I would also make Tab be the key that moves to the calendar from the input, but I would rate this as a 'should' not a 'must'. It's a much lower priority thing to fix than dismissing the calendar.

---

The behaviour is definitely not delightful. It is a debatable failure of 2.1.1 Keyboard. There is a method of operating by keyboard. It's just not expected, and is very cumbersome. It also verges on a failure of 1.4.13 Content on Hover of Focus, but since the calendar does not go away on loss of focus, it fails the spirit of the SC without the normative wording. Finally, it is debatable whether it represents a potential failure of Focus Visible (since the calendar can entirely obscure an item with focus). It will definitely fail WCAG 2.2's Focus Not Obscured, but that will not be required until the second half of 2023 at the earliest.

WCAG 2.1 Violation

see note in description

Reproduction/example

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

Steps to reproduce

Persistent and non-dismissible calendar

1. Using https://react.carbondesignsystem.com/?path=/story/components-datepicker--single-with-calendar#storybook-preview-wrapper tab to date input.
2. Attempt to dismiss the calendar that appears with the Esc key.
3. Press Tab. Focus will leave the component, yet the calendar does not react.

Inconsistent date input <> calendar operation

1. Having established above that Tab will not move focus from the date input to the calendar, with focus in the date input, press the Down Arrow to move to the calendar (an unintuitive move)
2. Now try to return to the datepicker by pressing the Up Arrow. Instead the selected date in the calendar moves up a week.
3. To return to the datepicker, the user must press Shift+Tab. So, arrow key in one direction, Tab in the other.

Code of Conduct

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

[tw15egan]

Part of this was recently addressed in #12567 (closing on esc). It still remains open on loss of focus, however

[mbgower]

@tw15egan sorry I missed that. Definitely an improvement. Not yet in the React storybook, I think.

[tw15egan]

@mbgower no worries, it was just merged in. Just wanted to make a note of it 👍🏻

[mbgower]

@sstrubberg with the resolution of the Esc key behaviour, I think the failure to close on loss of focus is not so clearly a failure until WCAG 2.2 comes into force,, so I'll reluctantly agree it can be sev 3, not 2.

[OleksandrDzindziura]

Hey! Any updates about it?

[sstrubberg]

hey @OleksandrDzindziura no immediate updates yet. I've added this to a larger work-stream we are building around WCAG 2.2 readiness that we will soon get to. Happy to take any contributions if you want to open a PR.