date-picker / date-time-picker: broken interaction when using assistive technologies

[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.

Depending on the specific browser/assistive technology used, the date picker does not allow users to select dates using the cursor keys.

On Windows, using Chrome and Firefox with NVDA, once the date picker is opened, cursor keys simply read through the content (announcing the various headings for months, days of the week, individual buttons for each day in source order). Cycling once through the "Today", "Cancel", date picker component itself, and back into the date picker overlay, cursor keys then work as intended (moving spatially through the various dates). Using JAWS, the initial experience is the same, except that JAWS does not exhibit the correct behaviour after cycling once through the focusable elements. In this screen reader, the date picker is largely unusable. It does appear to work correctly on MacOS with VoiceOver.

See the attached screen recording of Chrome/NVDA and Chrome/JAWS - after opening the date picker, attempting to use cursor keys reads the contents of the dialog. Cycling through focusable elements and back in "corrects" NVDA's behaviour.

Note that on mobile/smartphone devices, with assistive technologies, the date picker currently does not operate correctly at all - once opened, it does not receive focus programmatically, and users are left navigating in the underlying page.

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, assistive technology users on desktop and mobile devices will find the date picker component practically unusable.

Required solution

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

Implementation guidance

It was not immediately obvious to ascertain what the issue with the keyboard interaction on desktop devices with assistive technologies is (and, in particular, why NVDA "corrected" its handling after exiting and re-entering the date picker). It does appear to be related to how focus is handled once the date picker is first opened - the dialog itself, rather than the currently selected date/today's date/the starting date defined by the author is, receives focus. In the first instance, we would recommend experimenting with setting focus directly to the relevant button/date in the calendar.

In the case of mobile devices, we would recommend ensuring that the when the date picker displays in a modal-like fashion, it be treated as a modal - providing an appropriate role="dialog", setting aria-modal="true", hiding the underlying page behind the semi-transparent overlay, and then setting the correct initial focus inside the dialog.

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. Using a screen reader on a desktop device, open the date picker.
2. Change the selected date using the cursor keys.
3. Verify that the cursor keys change the date, rather than reading through all the contents of the dialog in a linear fashion.
4. On a mobile device, using a screen reader (VoiceOver on iOS, TalkBack on Android), open the date picker.
5. Verify that the date picker itself receives focus, and that navigating forward/backward (swiping left/right) moves through the contents of the date picker dialog, rather than the underlying page.

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 1.3.1 Info and Relationships (Level A)
• WCAG 2.1 Success Criterion 1.3.2 Meaningful Sequence (Level A)
• 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
• The A11Y Project - How-to: Hide content
• TPG: The current state of modal dialog accessibility
• A11y Dialog

Test data

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

[web-padawan]

Note that on mobile/smartphone devices, with assistive technologies, the date picker currently does not operate correctly at all - once opened, it does not receive focus programmatically, and users are left navigating in the underlying page.

This was fixed by #3372 and #3913

[web-padawan]

We tried using aria-modal, see #9976. However there are still some problems with content outside the date-picker overlay being announced in Safari VoiceOver, which could be related to the delay before focusing the date element (as it needs to be rendered first). Let's keep this issue / PR open for now and try investigating it further.