Buttons exposed as children of <input type="number"> break text reporting for screen readers
Categories
(Core :: Disability Access APIs, defect, P1)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox-esr68 | --- | unaffected |
| firefox72 | --- | unaffected |
| firefox73 | --- | unaffected |
| firefox74 | --- | fixed |
People
(Reporter: Jamie, Assigned: emilio)
References
(Regression)
Details
(Keywords: regression)
Attachments
(1 file)
Bug 981248 gets rid of the anonymous input for <input type="number"> controls. For the most part, this is good for a11y. However, the buttons being children of the control (which is itself editable) means that they also get exposed as part of the text of the control. That causes a bunch of problems for screen readers:
- Sometimes, you unexpectedly hear "button" while interacting with the control.
- Worse, when the caret is after the number (which happens whenever you press up/down arrow), it isn't reported by screen readers because the caret offset is 1, which is the offset of the first button.
While I generally believe we should expose UI equivalently for accessibility, these buttons cause breakage and I also don't think they're overly important. The simplest fix is to hide them with aria-hidden. Note that Chrome doesn't expose them, though I don't know what their implementation looks like visually.
If we do want to expose them still, they'd need to be exposed as siblings of the editable area. However, I don't know how we'd pull that off given that the editable area is the input itself.
|
||
Updated•4 years ago
|
|
Assignee | |
Comment 2•4 years ago
|
||
I may have missed a couple tests to update, running through try atm.
Pushed by ealvarez@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/ec30f3802e22 Hide spin buttons from the a11y tree. r=Jamie
|
||
Comment 4•4 years ago
|
||
| bugherder | ||
|
||
Updated•4 years ago
|
|
||
Updated•4 years ago
|
Description
•