date-picker / date-time-picker: small-screen date picker not fully keyboard-accessible

[TetraLogicalHelpdesk]

WCAG Level

Level A

Priority

High

Pages/screens/components affected

• Date Picker
• Date Time Picker

Description

Good design means supporting different modes of interaction, because there are many reasons why someone might use a keyboard instead of a mouse, and if keyboard interaction is not fully supported the website is effectively unusable.

On smaller screens/viewports, the date picker turns into a modal-like dialog. While it is possible, using the cursor keys, for a keyboard user to select a particular date, it's not possible to set focus/activate the "Today" and the "Cancel" controls.

In addition, after closing the small-screen date picker (using Esc or selecting an actual date), it appears that the date picker component itself "traps" keyboard focus when users attempt to navigate in reverse through the page (using Shift+Tab).

User impact

Someone with mobility problems will often use a keyboard instead of a mouse to navigate a web page. A screen reader user will also tend to use a keyboard if they cannot see the screen to use the mouse. Therefore if the website does not properly support keyboard interaction a large number of people are effectively prevented from using it.

In this case, keyboard users will be disadvantaged since they won't be able to use the "Today" and "Cancel" buttons. While they can alternatively cancel using Esc, not being able to easily get back to "Today"'s date may make interacting with the date picker very inconvenient.

More problematically, the fact that the date picker traps focus when using Shift+Tab to navigate will have a major impact on users, who will be forced to cycle through the entire page and back to the top of the document whenever they want to reach an element that came before the date picker.

Required solution

Make sure that all interactive controls can be used with a keyboard.

In this case, both the "Today" and "Cancel" button appear, from the markup, to be correctly implemented and focusable/actionable. It seems the problem may be due to some JavaScript acting as a focus trap (presumably to keep focus inside the modal-like date picker) - this may not have been correctly implemented. This would also explain why, after closing the date picker, focus is still affected when navigating through the page itself. We recommend reviewing and testing the current JavaScript that handles focus for this component.

This solution must be applied to all instances of the issue identified within the test sample, then applied to all other instances of the same issue identified throughout the rest of the components, their variants, and the documentation website.

Test procedure(s)

Use these steps to confirm that the solution has been correctly applied to issues identified within the test sample, and to test the rest of the components, their variants, and the documentation website for instances of the same issue:

1. Open the date picker in a small-screen/viewport environment (for instance, making your browser window relatively small / using zoom).
2. Check that all interactive elements can be navigated to using the tab key.
3. Check that all interactive elements can be activated using the enter or space keys.
4. Check that interactive elements can be interacted with using the arrow keys.
5. Check that, after closing the date picker, focus in the underlying page is not affected - users can Tab and Shift+Tab past the date picker and not become trapped.

Definition of done

Complete all of these tasks before closing this issue or indicating it is ready for retest:

• All issues identified within the test sample have been resolved.
• The rest of the components, their variants, and the documentation website have been tested for the same issue.
• All issues identified throughout the rest of the components/website have been resolved or filed as new issues.

Related standards

• WCAG 2.1 Success Criterion 2.1.1 Keyboard (Level A)
• WCAG 2.1 Success Criterion 2.4.3 Focus Order (Level A)

More information

• WebAIM: Keyboard
• W3C - Placing the interactive elements in an order that follows sequences and relationships within the content

Test data

Test date: March 2021
Website: vaadin.com/components, vaadin.com/docs-beta