New ARIA role for a <meter> element?

[fstorr]

The <meter> 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 <meter> 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").

The HTML spec for the <meter> element states that:

"The meter element should not be used to indicate progress (as in a progress bar). For that role, HTML provides a separate progress element."

Can we have a new ARIA role for a <meter> element? With browser support for the element improving, I would like to use it but currently can't as the progressbar role is proved too confusing for some users.

[jasonkiss]

The element has an incorrect default ARIA role of progressbar

The HTML-AAM (now moved to its own repository) specifies no corresponding role for meter. The ARIA in HTML spec does incorrectly specify progressbar as the default role. I've created issue 44 against that repo.

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").

See issue #2 in the new HTML-AAM repo.

Can we have a new ARIA role for a element?

Since ARIA seems committed to delivering roles for every native HTML semantic, it's a good question. @joanmarie, @halindrome, @cookiecrook?

[AmeliaBR]

Would it be acceptable to expose the meter as a read-only input range/slider?

If a new role was created, it would of course be a subclass of the (abstract) range role, and therefore inherit the aria-min/max/valuenow properties that are used for both progress bars and input sliders. These should directly map to the HTML meter's max/min/value properties.

However, if Voiceover and other screen-readers correctly expose these values (without converting to percentages) for <input type="range"> or custom ARIA sliders, then a new role may not be required.

The HTML meter has additional properties, to divide the range into low, middle, and high sections and to indicate which point in the range is optimum. For visual users, however, this metadata is only currently exposed by converting the current value into a color status (green, yellow, or red). So the equivalent information could be exposed to the accessibility APIs in the same way as aria-valuetext, e.g., by adding "good", "poor", or "bad" after the numerical value.

(Demo of the different cases; Chrome, Firefox, and Edge all use green/yellow/red bars with no additional metadata markings.)

So, in sum, a <meter> could be exposed in the same way as a custom element with the ARIA attributes:

• role=slider
• aria-readonly=true
• aria-valuemin = parsed value of the min attribute
• aria-valuemax = parsed value of the max attribute
• aria-valuenow = parsed value of the value attribute
• aria-valuetext = the parsed numerical value, plus a localized string for "good", "poor", or "bad" based on how the value maps to regions defined by the low, high, and optimum attributes, if provided

This mapping would, I think, make meters more accessible to screen reader users than to visual users. As currently implemented, the actual numerical values are not visually exposed by any browser, and the color status codes are probably not very useful to color-blind users. But that's another issue...

It still might be useful, in the long term, to have an ARIA role for a meter or gauge that isn't a progressbar. But using the existing mappings for input sliders means that we can make this change via the HTML-AAM, and hopefully get it into browsers quickly, without needing to first spec a new ARIA roles or implement new Accessibility API roles.

[joanmarie]

There are, I think, a couple of questions/issues:

1. Should there be a new ARIA role?
2. What are the appropriate platform mappings?

Regarding the latter, on my platform (ATK), the mapping is correct: ATK_ROLE_LEVEL_BAR (which is not the same as ATK_ROLE_PROGRESS_BAR). Maybe we should add a new ARIA role (for HTML5 parity). But I think the issue stated in the opening report can be solved independently of that.

[AmeliaBR]

If at least some platforms have a native role that is a direct equivalent of a meter (a range that is not a progress bar, and not an input slider), then that is a good argument for defining a distinct ARIA role.

For short term, better platform mappings could still be added to the HTML-AAM, without having an ARIA role to map to. But as I've argued elsewhere, I don't like having custom mappings for HTML elements without having an equivalent role in the ARIA taxonomy.

[asurkov]

On Mon, Oct 10, 2016 at 10:06 PM, Jason Kiss notifications@github.com
wrote:

The element has an incorrect default ARIA role of progressbar

The HTML-AAM (now moved to its own repository
https://github.com/w3c/html-aam) specifies no corresponding role for
meter. The ARIA in HTML spec does incorrectly specify progressbar as the
default role. I've created issue 44 against that repo
w3c/html-aria#44.

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").

the VoiceOver issue has to be not related with ARIA stuff, as they have
their own set of roles [1], which doesn't have a match for HTML5 meter.

See issue #2 in the new HTML-AAM repo
w3c/html-aam#2.

Can we have a new ARIA role for a element?

Since ARIA seems committed to delivering roles for every native HTML
semantic, it's a good question. @joanmarie https://github.com/Joanmarie,
@halindrome https://github.com/halindrome, @cookiecrook
https://github.com/cookiecrook?

I would say that HTML AAM shouldn't force addition for new ARIA roles, even
if they are committed to replicate all HTML semantics.

[1]
https://developer.apple.com/reference/appkit/nsaccessibility/1663038-roles

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#451 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/ABdnqQ62EE87SZ9CqF_6dA7qZLNw1zlIks5qyu80gaJpZM4KTDA9
.

[cookiecrook]

I filed https://webkit.org/b/164051 for the WebKit bug.

I'm generally only board with a 1:1 mapping to HTML elements, though many of the generic ones (div, span, b, etc.) should map to the same generic role. <meter> is probably unique enough for its own role, but we should avoid adding ARIA roles for things that aren't possible to implement custom versions accessibly (e.g. <video>). I don't expect <meter> is one of those so a role seems reasonable.

[cookiecrook]

Re: previous comment from October, I filed a new issue #525

[joanmarie]

I'm blocking this issue on issue #892 based on the consensus of today's ARIA WG meeting. We want to be sure there's no unexpected fall out of addressing #892 as described.