1802201 - Make timepicker panel accessible

Status: NEW

(Core :: Layout: Form Controls, defect)

Description

[Anna Yeddi [:ayeddi]]

STR

1. Ensure that the dom.forms.datetime.timepicker pref is set to true on about:config
2. Turn on a screen reader
3. Open a new tab with URI data:text/html,<input type=time>
4. Navigate to and activate either of time spin buttons (hour, minute, time of the day) by pressing Space when it's focused
5. Confirm a timepicker panel is opened and the focus is moved to it
6. Using Right arrow navigate to each field's selection spinner, try to change the value by pressing Up/Down arrows, and observe its behavior

Expected

The timeppicker dialog to follow the best practices of a WAI ARIA Spinbutton and Dialog (modal)

1. The timepicker panel should communicate to a user that it is a dialog (by a role on the panel container) and what its purpose is (by a localizable aria-label on the container)
2. The spin button previous/next controls should provide a descriptive localizable accessible names (by aria-label attributes on the <button> elements), i.e. Previous hour and Next minute - while a screen reader may not need to access them as the spin buttons themselves provide selection functionality, a speech-to-text/Voice Control user should be able to call these buttons by their name
3. The spin button previous/next controls should have a tabindex=-1 to remove the decrease and increase buttons from the page Tab sequence while keeping them focusable so they can be accessed with touch-based assistive technology
4. The spin buttons themselves should provide an accessible name to communicate which value is being selected

Actual

1. The timepicker panel is not marked up appropriately: it does not expose its role and accessible name to a screen reader
2. The spin button previous/next controls lack accessible names and are announced as button only
3. The spin buttons themselves have no accessible name and therefore it is not clear which value is being selected

Form fields

1. <input type=time>
2. (possible) <input type=datetime-local> (if the bug 451832 is implemented)

Notes

Most of the spin button attributes for spinners are to be provided by the bug 1676068, incl.:

• aria-valuemin and aria-valuemax attributes that indicate the minimum and maximum allowed values for each spin button
• aria-valuenow and aria-valuetext that communicate a current selected value and its human-friendlier pronunciation
• role=spinbutton that identifies the containing <div> element as a spin button
• tabindex=0 that includes the spin button to the logical Tab sequence of the panel
• aria-hidden=true attributes to the children of spin buttons that hides the text showing the next and previous values that is displayed adjacent to the up and down arrow icons since it would otherwise add superfluous elements to the screen reader reading order that are likely to be more confusing than helpful.

Comment 1

[Anna Yeddi [:ayeddi]]

The picker should also respect prefers-reduced-motion

Comment 2

[Anna Yeddi [:ayeddi]]

Attachment: Bug 1802201 - Make timepicker panel for time inputs accessible. r=Jamie,emilio,mconley,flod

Done:

• The time picker panel has role, accessible name as a dialog
• Each spinbutton has an accessible name
• Each spinbutton's previous/next controls
• All aria-labels are localized

ToDo:

• Respect prefers-reduced-motion
• Add tests (maybe another patch for bug 1309471 or not)

Depends on D167458

Comment 3

[Anna Yeddi [:ayeddi]]

This issue is an access-S2, but it was marked with a lower accessibility severity because it is not planned to be enabled yet. With the improvements in our a11y triage system, per bug 1901188, I'm adding a keyword no-plan-to-ship and setting up a proper accessibility severity. This bug should be fixed before the timepicker is enabled.

I'm also unassigning myself since I wouldn't have cycles to work on the patch, but if anyone wants to commandeer the attached patch in progress, I'll be happy to mentor them on the a11y side of the work.

Comment 4

[BugBot [:suhaib / :marco/ :calixte]]

The severity field for this bug is set to S3. However, the accessibility severity is higher, .
:emilio, could you consider increasing the severity?

For more information, please visit BugBot documentation.

Comment 5

[James Teh [:Jamie]]

The plan is that BugBot won't nag about mismatched access severity/severity when no-plan-to-ship is set, but that work hasn't been done yet.