1802205 - Selection indication is removed from spinbuttons of the timepicker when arrow keys are used

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. Open a new tab with URI data:text/html,<input type=time>
3. Navigate to and activate either of time spin buttons (hour, minute, time of the day) by pressing Space when it's focused
4. Confirm a timepicker panel is opened
5. Change the value by pressing Up/Down arrows few times, and observe its behavior
6. Using Right arrow navigate to each field's selection spinner and repeat step 5

Expected

The selection indication highlight is clearly visible on each spin button and it is clear from the time picker's appearance which value is being currently selected

Actual

The selection indication on each spin button is removed when a value selection is changed on that spinner by Up/Down arrows and therefore it is not clear from the time picker which value is being currently selected.

• This affects accessibility of the component, because a clear indication of selected state is needed for users with cognitive difficulties and users with low visions

Form fields

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

Comment 1

[Eitan Isaacson [:eeejay]]

Setting this to access-s2 because it heavily affects keyboard users.

Comment 2

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

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

For more information, please visit auto_nag documentation.

Comment 3

[Emilio Cobos Álvarez (:emilio)]

We're not shipping time pickers afaict, so S3 seems reasonable.

Comment 4

[Emilio Cobos Álvarez (:emilio)]

Given comment 3 this is probably not access-s2?

Comment 5

[Anna Yeddi [:ayeddi]]

This is the similar case as Jamie described in the comments 5 and 6 of bug 1655503:

It's a little tricky. On one hand, yes, sure, it's not shipping, so it's not currently an access-s2 for users. On the other hand, if we do plan to ship it, it will become an access-s2. The concern is that if we drop it to access-s3 and then we later decide to ship this, folks might not realise that this is absolutely a ship blocker. This is one of the few situations where it's reasonable for a feature to be marked access-s2 but to not be triaged as an s2 within its component.
Perhaps we need some keyword to indicate that we don't have plans to ship something in the short-term. That way, these access-s2s can be excluded from searches for user-impacting access-s2s.