1409731 - Time values cannot be changed with arrow keys while using "NVDA" screen reader

Status: VERIFIED FIXED

(Core :: Layout: Form Controls, defect, P3)

Description

[Emil Ghitta, QA [:emilghitta]]

[Affected versions]:
57.0b9 (BuildId:20171016185129)
58.0a1 (BuildId:20171017220415)

[Affected platforms]:
-Windows 10 64bit
-Windows 7 64bit

[Unaffected platforms]:
-macOS 10.11.6
-Ubuntu 16.04 64bit

[Steps to reproduce]:
1. Launch Firefox.
2. In the URL bar enter "data:text/html, <input type="time">".
3. Open the "NVDA" screen reader.
4. Highlight the input box.
5. Press the Up/Down arrow keys to change the values.

[Expected result]:
Values can be successfully changed using the up/down arrow keys.

[Actual result]:
Values cannot be changed using the up/down arrow keys.

[Regression range]:
I don't think that this is a regression.

[Additional notes]:
Please note that this issue is not reproducible using VoiceOver (with macOS 10.11.6) and GNOME-ORCA (with Ubuntu 16.04 64bit).

Also this issue is not reproducible on Chrome while using "NVDA".

Comment 1

[:Gijs (he/him)]

Jamie, any idea what's going on here?

Comment 2

[James Teh [:Jamie]]

The accessibility implementation for these controls is somewhat broken/non-existent.

1. The accessible for the input element has a role of text frame. This is where the label of the field (if any) is exposed. I'd suggest this should get a role of grouping (ARIA role="group") so that the label is reported for the entire widget.
2. The hour, minute and AM/PM fields are currently just spans with no ARIA semantics. I'd suggest these should get an ARIA role="spinbutton". In addition, aria-valuetext should be set to the value.

Note that input type="date" is similarly broken... and can be fixed in a similar way.

Comment 3

[Marco Zehe (:MarcoZ)]

I know Eitan and I were working on this at the design stage with the folks implementing these widgets. At some point, I was looped out of the workings in progress, and it seems this somehow either got broken or was never properly implemented in an accessible way.

Eitan, do you have any idea about the current status? You were working with them more closely than I.

Comment 4

[Eitan Isaacson [:eeejay]]

Yeah. It looks like no work was done for accessibility API. I'll take this on.

Comment 5

[Eitan Isaacson [:eeejay]]

Attachment: Expose input[type=date/time] correctly in a11y. r?

Here is a patch to get basic aria and role mapping for the date and time input type. Marco, can you give this a try and let me know what you think is missing?

Comment 6

[Marco Zehe (:MarcoZ)]

Comment on attachment 8930293 [details] [diff] [review]
Expose input[type=date/time] correctly in a11y. r?

This looks correct.

Comment 7

[alexander :surkov (:asurkov)]

Comment on attachment 8930293 [details] [diff] [review]
Expose input[type=date/time] correctly in a11y. r?

Review of attachment 8930293 [details] [diff] [review]:
-----------------------------------------------------------------

would you please add couple tests into https://dxr.mozilla.org/mozilla-central/source/accessible/tests/mochitest/elm/test_HTMLSpec.html

Comment 8

[Eitan Isaacson [:eeejay]]

Attachment: Expose input[type=date/time] correctly in a11y. r=surkov r?mconley

Comment 9

[Eitan Isaacson [:eeejay]]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=e7a159f3f474b588eb12b57426a6e256096a4bef

Comment 10

[Mike Conley (:mconley) (:⚙️)]

Comment on attachment 8930708 [details] [diff] [review]
Expose input[type=date/time] correctly in a11y. r=surkov r?mconley

In a blaze of delegation, I'm going to see if scottwu feels comfortable reviewing the changes to datetimebox.xml and datetimebox.dtd.

Not sure if he'd also be comfortable reviewing the accessible/ changes. I'm not super comfortable reviewing that stuff myself, since I don't really know the code. Perhaps have yura review that part?

Comment 11

[Eitan Isaacson [:eeejay]]

(In reply to Mike Conley (:mconley) (:⚙️) - Backlogged on reviews and needinfos from comment #10)
> Comment on attachment 8930708 [details] [diff] [review]
> Expose input[type=date/time] correctly in a11y. r=surkov r?mconley
> 
> In a blaze of delegation, I'm going to see if scottwu feels comfortable
> reviewing the changes to datetimebox.xml and datetimebox.dtd.
> 
> Not sure if he'd also be comfortable reviewing the accessible/ changes. I'm
> not super comfortable reviewing that stuff myself, since I don't really know
> the code. Perhaps have yura review that part?

I already got an r+ from surkov on that front!

Comment 12

[Scott Wu [:scottwu]]

Comment on attachment 8930708 [details] [diff] [review]
Expose input[type=date/time] correctly in a11y. r=surkov r?mconley

I think we should have :jessica take a look at the patch, since she wrote the datetimebox.xml portion.

Thanks you so much your patch Eitan!

Comment 13

[Jessica Jong [:jessica] (inactive)]

I'll quickly go through the ARIA document on MDN before looking at the patch, will get back to this tomorrow. Keeping the NI for tracking.

Comment 14

[Jessica Jong [:jessica] (inactive)]

Comment on attachment 8930708 [details] [diff] [review]
Expose input[type=date/time] correctly in a11y. r=surkov r?mconley

Review of attachment 8930708 [details] [diff] [review]:
-----------------------------------------------------------------

Looks good to me. I'm just wondering whether we should use role="textbox" on AM/PM field, since you can't really enter any text there, but I see there is also aria-autocomplete="inline" with it. So.. you're more familiar with ARIA, you'd know better. :)

Thanks a lot for the patch!

Comment 15

[alexander :surkov (:asurkov)]

ready for landing?

Comment 16

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/mozilla-inbound/rev/4d05087275dd
Expose input[type=date/time] correctly in a11y. r=surkov, r=jjong

Comment 17

[Narcis Beleuzu [:NarcisB]]

https://hg.mozilla.org/mozilla-central/rev/4d05087275dd

Comment 18

[Julien Cristau [:jcristau]]

This involves string changes so I'll call it wontfix for 58.

Comment 19

[Emil Ghitta, QA [:emilghitta]]

This issue is verified fixed using Firefox 59.0a1 (BuildId:20171219100203) on Windows 10 64bit with NVDA v 2017.4.