make <input type="number"> accessible

RESOLVED FIXED in Firefox 28

Status

()

Core
Disability Access APIs
RESOLVED FIXED
8 years ago
3 years ago

People

(Reporter: surkov, Assigned: surkov)

Tracking

(Depends on: 2 bugs, Blocks: 1 bug, {access})

unspecified
mozilla29
x86
All
access
Points:
---
Dependency tree / graph
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(firefox28 fixed, firefox29 fixed)

Details

(Whiteboard: [qa-], URL)

Attachments

(1 attachment)

(Assignee)

Description

8 years ago
Manage invalid state, expose nsIAccessibleValue
(Assignee)

Updated

6 years ago
Summary: make <input type="number"> accessible → add a11y mochitests <input type="number">
(Assignee)

Updated

6 years ago
Summary: add a11y mochitests <input type="number"> → add a11y mochitests for <input type="number">
(Assignee)

Comment 1

6 years ago
changed summary by accident, sorry for spam
Summary: add a11y mochitests for <input type="number"> → make <input type="number"> accessible
(Assignee)

Comment 2

5 years ago
per HTML spec (https://dvcs.w3.org/hg/html-api-map/raw-file/tip/Overview.html) we need to expose ROLE_SYSTEM_SPINBUTTON role.

Also see open HTML spec bug https://www.w3.org/Bugs/Public/show_bug.cgi?id=13562
Assuming the patch for bug lands, the patch for this bug should be sure to back out that patch.
C&P fail. Comment 3 is referring to bug 927326.
(Assignee)

Comment 5

5 years ago
marking it blocking bug a11y q4 bug since bug 635240 seems breaks basic accessibility we have by freshing the layout for the control.
Blocks: 923199
The implementation that's currently in mozilla-central should be complete enough to work on a patch for this now. The dom.forms.number pref just needs to be flipped to true.
Just pinged surkov about this, and he said he will aim to take a look this week.

Here's a quick summary of the essential things to know: input type=number> contains a native anonymous tree that looks like this:

  <input type=number>
    <div>                - outer wrapper with "display:flex" by default
      <input type=text>  - text input field
      <div>              - spinner box wrapping up/down arrow buttons
        <div>            - spin up (up arrow button)
        <div>            - spin down (down arrow button)

The anonymous text field grandchild can take focus for the number input. If the a11y code looks at the focused element and it is a text field, it needs to be careful to check HTMLInputElement::ownerNumberControl to see if what it's dealing with is actually a number control and not a text control.
Also note that the pref is on for v28, so hopefully this can be uplifted. I'm very much hoping to keep it on since Tom's Hardware's Browser Grand Prix puts a fair bit of focus on <input type=number> and there's a reasonable chance v28 will be the next version they test.
(Assignee)

Comment 9

4 years ago
Created attachment 8344953 [details] [diff] [review]
patch
Assignee: nobody → surkov.alexander
Status: NEW → ASSIGNED
Attachment #8344953 - Flags: review?(trev.saunders)
Attachment #8344953 - Flags: review?(bugs)

Updated

4 years ago
Attachment #8344953 - Flags: review?(bugs) → review+
Comment on attachment 8344953 [details] [diff] [review]
patch

>+++ b/layout/forms/nsNumberControlFrame.cpp
>+#ifdef ACCESSIBILITY
>+#include "nsAccessibilityService.h"
>+#endif

mozilla/a11y/AccTypes.h should be enough right?
Attachment #8344953 - Flags: review?(trev.saunders) → review+
https://hg.mozilla.org/mozilla-central/rev/21ecf45dd590
Status: ASSIGNED → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla29
Thank you!
Comment on attachment 8344953 [details] [diff] [review]
patch

[Approval Request Comment]
Bug caused by (feature/regressing bug #): N/A
User impact if declined: <input type=number> not accessible in v28
Testing completed (on m-c, etc.): landed m-i, merged to m-c
Risk to taking this patch (and alternatives if risky): low and early
String or IDL/UUID changes made by this patch: none

We're early in the cycle so hopefully this is fine to uplift. Probably neded to keep <input type=number> on in v28.
Attachment #8344953 - Flags: approval-mozilla-aurora?
So, Jonathan, we do want this in Aurora (Mozilla 28), right?
(In reply to Jonathan Watt [:jwatt] from comment #14)
> Bug caused by (feature/regressing bug #): N/A

Bug 344616 and its dependencies if you need one to blame.

(In reply to Marco Zehe (:MarcoZ) from comment #15)
> So, Jonathan, we do want this in Aurora (Mozilla 28), right?

Yes, which is why I requested approval.

Updated

4 years ago
Blocks: 344616
No longer depends on: 344616
Comment on attachment 8344953 [details] [diff] [review]
patch

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

Looks good we will go ahead approve this for uplift.
Attachment #8344953 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
(Assignee)

Updated

4 years ago
Keywords: checkin-needed
https://hg.mozilla.org/releases/mozilla-aurora/rev/4d297d712792
status-firefox28: --- → fixed
status-firefox29: --- → fixed
Keywords: checkin-needed
Given in-testsuite coverage this fix will not be manually verified by QA. If you believe this warrants extra QA attention please nominate for testing by removing this whiteboard tag and adding the verifyme keyword. Please also provide any details you have that may inform our testing.
Whiteboard: [qa-]
You need to log in before you can comment on or make changes to this bug.