Closed Bug 1460378 Opened 3 years ago Closed 3 months ago

HTML <meter> not spoken by screen readers

Categories

(Core :: Disability Access APIs, defect, P2)

defect

Tracking

()

VERIFIED FIXED
87 Branch
Tracking Status
firefox87 --- verified

People

(Reporter: aaronlev, Assigned: morgan)

References

(Blocks 2 open bugs)

Details

Attachments

(5 files)

Attached file meter.html
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.
Taking a guess at P3 - please retriage as necessary.
Priority: -- → P3
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 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)
good point, I will update the patch and file the fix to HTML AAM.
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)
Attachment #8996798 - Attachment description: meter → meter role - part1
Attached patch value interfaceSplinter Review
Attachment #8997091 - Flags: review?(jteh)
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. :(
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 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 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)
Marco, I'd appreciate your thoughts on comment 7 and comment 8. Also, would you care to take this on?
Flags: needinfo?(mzehe)
I'll take a look at this after my PTO.
Flags: needinfo?(mzehe)
Duplicate of this bug: 559770
Assignee: surkov.alexander → nobody
Blocks: html5a11y, 555985
Priority: P3 → P2

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: nobody → mreschenberg

: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)

Answered in Phab.

Flags: needinfo?(jteh)
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
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
Status: NEW → RESOLVED
Closed: 3 months ago
Resolution: --- → FIXED
Target Milestone: --- → 87 Branch

Confirmed with ESR68 that the element is skipped from reading.
Verified with 87.0, it being read as "selected" element.

Status: RESOLVED → VERIFIED
Flags: qe-verify+
You need to log in before you can comment on or make changes to this bug.