Closed
Bug 1460378
Opened 7 years ago
Closed 4 years ago
HTML <meter> not spoken by screen readers
Categories
(Core :: Disability Access APIs, defect, P2)
Core
Disability Access APIs
Tracking
()
VERIFIED
FIXED
87 Branch
Tracking | Status | |
---|---|---|
firefox87 | --- | verified |
People
(Reporter: aaronlev, Assigned: morgan)
References
(Blocks 3 open bugs)
Details
Attachments
(5 files)
(deleted),
text/html
|
Details | |
(deleted),
patch
|
Details | Diff | Splinter Review | |
(deleted),
patch
|
Details | Diff | Splinter Review | |
(deleted),
text/x-phabricator-request
|
Details | |
(deleted),
text/x-phabricator-request
|
Details |
The HTML <meter> element represents either a scalar value within a known range or a fractional value.
The HTML meter element does not currently speak at all in Firefox. (In Chrome, it gets spoken as a progress meter).
CORE-AAM maps a <meter> to IA2_ROLE_LEVEL_METER. Unfortunately, NVDA + JAWS don't currently support IA2_ROLE_LEVEL_METER. I've sent them each emails to ask them to support it.
Example attached.
Comment 1•6 years ago
|
||
Taking a guess at P3 - please retriage as necessary.
Updated•6 years ago
|
Priority: -- → P3
Comment 2•6 years ago
|
||
it seems there's no role yet on os x https://bugs.webkit.org/show_bug.cgi?id=164051
Assignee: nobody → surkov.alexander
Attachment #8996798 -
Flags: review?(jteh)
Comment 3•6 years ago
|
||
Comment on attachment 8996798 [details] [diff] [review]
meter role - part1
Review of attachment 8996798 [details] [diff] [review]:
-----------------------------------------------------------------
This doesn't expose a value or the value interfaces, which it needs to do. It's not useful without this. (I realise the HTML AAM doesn't specify this. It should, and it does for ATK.) I guess the text Value should probably just be the @value attribute, rather than 70% or similar like it is for progress. FWIW, this is what Chrome does. (The spec doesn't cover this either, even for ATK.)
With this patch, there is also a div (section) accessible beneath the meter. We probably want to prune that.
Attachment #8996798 -
Flags: review?(jteh)
Comment 4•6 years ago
|
||
good point, I will update the patch and file the fix to HTML AAM.
Comment 5•6 years ago
|
||
Comment on attachment 8996798 [details] [diff] [review]
meter role - part1
Review of attachment 8996798 [details] [diff] [review]:
-----------------------------------------------------------------
let's keep the things separately, I'll put value interface stuff in follow-ups
Attachment #8996798 -
Flags: review?(jteh)
Updated•6 years ago
|
Attachment #8996798 -
Attachment description: meter → meter role - part1
Comment 6•6 years ago
|
||
Attachment #8997091 -
Flags: review?(jteh)
Comment 7•6 years ago
|
||
Thanks. However, this exposes a percentage as the value. I'm not sure if that's really what we want to do for meter, as I noted in comment 3. Aside from the way the control is described (its role), the other reason for creating this new role was because of the value:
> The element has an incorrect default ARIA role of progressbar which causes some assistive technology (I've tested in VoiceOver on OSX 10.11) to announce the element as a "progress indicator" and the value of the element as a percentage rather than the defined value (for example "80%" instead of "4 out of 5").
( https://github.com/w3c/html-aam/issues/2 )
Now, it's probably not reasonable for us to expose something like "4 out of 5"; that would be a localised string, it doesn't handle the case where the minimum isn't 0, etc. However, I tend to think we should just expose the raw value as Chrome does (350 in the attached example), rather than a percentage. The spec doesn't provide any guidance, so that's no help. :(
Comment 8•6 years ago
|
||
In some ways, I think it makes sense to use the fallback content (if specified) like aria-valuetext. There's some discussion on that here: https://github.com/w3c/html-aam/issues/27
Comment 9•6 years ago
|
||
Comment on attachment 8996798 [details] [diff] [review]
meter role - part1
Cancelling review because I don't think Alex is working on this any more and we need to re-think this based on comment 7 and bug 1499947.
Attachment #8996798 -
Flags: review?(jteh)
Comment 10•6 years ago
|
||
Comment on attachment 8997091 [details] [diff] [review]
value interface
Cancelling review because I don't think Alex is working on this any more and we need to re-think this based on comment 7 and bug 1499947. Note that bug 1499947 completely breaks this patch, since it gets rid of the base ProgressMeterAccessible template.
Attachment #8997091 -
Flags: review?(jteh)
Comment 11•6 years ago
|
||
Marco, I'd appreciate your thoughts on comment 7 and comment 8. Also, would you care to take this on?
Flags: needinfo?(mzehe)
Updated•5 years ago
|
Comment 14•5 years ago
|
||
Would be great to get support for this and also the aria role=meter that was recently added: https://w3c.github.io/aria/#meter
Assignee | ||
Updated•4 years ago
|
Assignee: nobody → mreschenberg
Assignee | ||
Comment 15•4 years ago
|
||
:Jamie, do we need to create a new type flag for this? based on the discussion in the github issue here, and the resolution that meter should be distinct from progress, it feels wrong to map mType = eProgressType, but I'm not sure we have something that fits better at the moment.
Flags: needinfo?(jteh)
Assignee | ||
Comment 16•4 years ago
|
||
Assignee | ||
Comment 17•4 years ago
|
||
Depends on D104759
Updated•4 years ago
|
Attachment #9202443 -
Attachment description: Bug 1460378: Map role description on mac for meter element r?eeejay → Bug 1460378: Verify role, role description mapping for meter element on mac r?eeejay
Comment 19•4 years ago
|
||
Pushed by mreschenberg@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/d03c36cdbc21
Introduce meter role and HTMLMeterAccessible class. r=Jamie
https://hg.mozilla.org/integration/autoland/rev/9c26b7582208
Verify role, role description mapping for meter element on mac r=eeejay
Comment 20•4 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/d03c36cdbc21
https://hg.mozilla.org/mozilla-central/rev/9c26b7582208
Status: NEW → RESOLVED
Closed: 4 years ago
status-firefox87:
--- → fixed
Resolution: --- → FIXED
Target Milestone: --- → 87 Branch
Updated•4 years ago
|
Flags: qe-verify+
Comment 21•4 years ago
|
||
Confirmed with ESR68 that the element is skipped from reading.
Verified with 87.0, it being read as "selected" element.
Updated•3 years ago
|
You need to log in
before you can comment on or make changes to this bug.
Description
•