Closed Bug 1409731 Opened 3 years ago Closed 3 years ago

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

Categories

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

All
Windows
defect

Tracking

()

VERIFIED FIXED
mozilla59
Tracking Status
firefox57 --- wontfix
firefox58 --- wontfix
firefox59 --- verified

People

(Reporter: emilghitta, Assigned: eeejay)

References

(Blocks 1 open bug)

Details

Attachments

(1 file, 1 obsolete file)

[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".
Priority: -- → P3
Jamie, any idea what's going on here?
Flags: needinfo?(jteh)
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.
Flags: needinfo?(jteh)
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.
Flags: needinfo?(eitan)
Yeah. It looks like no work was done for accessibility API. I'll take this on.
Assignee: nobody → eitan
Flags: needinfo?(eitan)
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?
Attachment #8930293 - Flags: feedback?(mzehe)
Comment on attachment 8930293 [details] [diff] [review]
Expose input[type=date/time] correctly in a11y. r?

This looks correct.
Attachment #8930293 - Flags: feedback?(mzehe) → feedback+
Attachment #8930293 - Flags: review?(surkov.alexander)
Attachment #8930293 - Flags: review?(mconley)
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
Attachment #8930293 - Flags: review?(surkov.alexander) → review+
Attachment #8930293 - Attachment is obsolete: true
Attachment #8930293 - Flags: review?(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?
Attachment #8930708 - Flags: review?(mconley) → review?(scwwu)
(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 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!
Flags: needinfo?(jjong)
Attachment #8930708 - Flags: review?(scwwu)
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 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!
Attachment #8930708 - Flags: review+
Flags: needinfo?(jjong)
ready for landing?
Flags: needinfo?(eitan)
Flags: needinfo?(eitan)
Keywords: checkin-needed
Pushed by ryanvm@gmail.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/4d05087275dd
Expose input[type=date/time] correctly in a11y. r=surkov, r=jjong
Keywords: checkin-needed
https://hg.mozilla.org/mozilla-central/rev/4d05087275dd
Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla59
This involves string changes so I'll call it wontfix for 58.
This issue is verified fixed using Firefox 59.0a1 (BuildId:20171219100203) on Windows 10 64bit with NVDA v 2017.4.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.