HTML-AAM: how to map Inner Phrasing Content for <meter>?

[jasonkiss]

From @cyns on February 2, 2016 18:24

HTML spec on has examples like this

<meter value="0.5">Moderate activity</meter>

Where should the inner phrasing content "Moderate activity" be mapped in the AAPIs? Is this a value? Part of name or description? Something else?

Copied from original issue: w3c/aria#240

[jasonkiss]

From @cyns on April 23, 2016 21:9

@stevefaulkner @jasonkiss @joanmarie we're blocked on this one. should it be mapped at all?

I thought about mapping it to aria-valuetext, but that uses the same uia property that we're using for the result of optimal calculation (Value.Value).
The fallback content doesn't seem like it would make a good name.

[jasonkiss]

From @cyns on April 23, 2016 21:22

#334 is related

[jasonkiss]

My initial impression is that the element subtree would be used for the accname. So similar to how button gets its name computed.

But I note that meter (and button and output for that matter) is a labelable element that can also have a phrasing content subtree.

So wouldn't the name computation be the following?

1. Use aria-label or aria-labelledby if provided
2. associated label element if provided
3. content subtree
4. title attribute

And if so, should we also update the name computation for button and "Other Form Elements" to account for potential use of label and/or element subtree if applicable? @stevefaulkner? This should probably be followed up on in issue #29.

Regardless, given that final mappings for meter (see issue #2) have been deferred to AAM v2, I think it makes sense to do the same with this one.

[asurkov]

confirming: the sequence looks reasonable, and shouldn't be different from HTML:button one.

However I would say instead that elements like HTML:button are labellable and allow name computation from subtree leaving ARIA behind, since this is universal rule and we don't have to repeat it all over.

[jasonkiss]

Thanks, @asurkov. I've carried on the conversation over at #29.

[jcsteh]

@jasonkiss commented on Feb 7, 2018, 9:50 AM GMT+10:

My initial impression is that the element subtree would be used for the accname. So similar to how button gets its name computed.

I don't really follow this. Yes, button is similar in that it can have content, but the similarity ends there. Button's content is visible to all users. In contrast, meter's content is fallback content. If anything, fallback content is more likely to be a textual representation of the value. An author is likely to do something like this:

<p>Heat the oven to <meter min="200" max="500" value="350">350 degrees</meter>.</p>

rather than this:

<p>Heat the oven to <meter min="200" max="500" value="350">temperature of the oven</meter>.</p>

I'd suggest that aria-valuetext (as discussed above) is a better mapping. I don't quite understand mapping of optimal to value; low, optimal and high seem difficult/impossible to map with current accessible value interfaces.

[scottaohara]

the fallback content for the meter isn't exposed to anyone when the browser supports meter.
and for legacy browsers that don't support meter, the author provided fallback content is exposed as text.

it doesn't seem necessary to expose the fallback content if the meter is rendered, especially since if the meter value updates the fallback content would likely become out of sync and then the meter would need to drop that and just expose the updated values - which it could have done / should already be doing now.

so i'm going to close this issue, i no longer think this should be done.

[jcsteh]

the fallback content for the meter isn't exposed to anyone when the browser supports meter.

FWIW, Firefox currently exposes the fallback content as the value of a meter. Obviously, that's incorrect per the spec. However:

it doesn't seem necessary to expose the fallback content if the meter is rendered,

We had concerns about user understanding of a meter, given the difficulty (and current lack) of mapping for optimal, low and high. As I understand it, those attributes fundamentally alter the way meter is rendered visually, and without some way of communicating that to accessibility APIs (and I don't have any useful thoughts on that), AT users could be missing out on required info for interpreting the meter correctly. Our thought was that the fallback content might provide better info in this case.

especially since if the meter value updates the fallback content would likely become out of sync

Are you thinking it would get out of sync because most authors just wouldn't bother updating it? I guess that's reasonable.

To be clear, I'm not necessarily arguing that what Firefox is doing is the way we should go. It would seem Firefox is the odd one out here. However, I thought it might be worth providing this additional context as to why we went that direction.