meter role should have optional aria-valuemin/max with defaults

[zcorpan]

The meter role was added to ARIA for parity with HTML.

https://w3c.github.io/aria/#meter

However, it's inconsistent with all other roles in that it doesn't have default values for aria-valuemin or aria-valuemax, and they are required for authors to provide. With the exception of spinbutton, the defaults are 0 and 100, respectively.

This is also inconsistent with the HTML meter element, which allows omitting the min and max attributes. The default values in HTML are 0.0 and 1.0, respectively. In HTML, this is consistent with the progress element (except progress doesn't have a min attribute).

https://html.spec.whatwg.org/multipage/form-elements.html#the-progress-element
https://html.spec.whatwg.org/multipage/form-elements.html#the-meter-element

This seems like an unnecessary source of confusion. I suggest the meter role is changed to allow omitting aria-valuemin and aria-valuemax and that their default values are 0 and 100, like the other roles.

[zcorpan]

Another difference is that in HTML, the value attribute is required for the meter element. In ARIA, aria-valuenow is not required for the meter role.

[scottaohara]

@zcorpan

aria-valuenow is listed in the Required States and Properties row of the characteristics table for meter. Are you saying it shouldn't be?

That aside for now though, I agree that it should have similar default values as you indicated.

I took a stab at revising the definition, pulling some bits from progressbar.

An element that represents a scalar measurement within a known range, or a fractional value. See related progressbar.

Authors MAY set aria-valuemin and aria-valuemax to make the minimum and maximum values available to assistive technologies. Otherwise, their implicit values follow the same rules as <input[type="range"]> in [HTML]:

• If aria-valuemin is missing or not a number, it defaults to 0 (zero).
• If aria-valuemax is missing or not a number, it defaults to 100.

If authors do not set aria-valuemin and aria-valuemax, the value of aria-valuenow MUST NOT fall below or exceed the implicit aria-valuemin and aria-valuemax values, respectively.
Authors SHOULD NOT use the meter role to indicate progress; the progressbar role exists to address that need.

An Implicit Value for Role row would then be added to the characteristics table and aria-valuemin and aria-valuemax would be listed there, rather than in the required states and properties row, as they are in the progressbar characteristics table.

Happy to revise further if you or anyone else would rather this worded differently.

[carmacleod]

Note that there's a fallback table in the ARIA spec - maybe some of this needs to go in there, too?
Interesting that progressbar min and max aren't in the fallback table either.
I suspect there may be other inconsistencies around other "missing required attributes" as well.

Fallback values for missing required attributes

[zcorpan]

aria-valuenow is listed in the Required States and Properties row of the characteristics table for meter. Are you saying it shouldn't be?

My bad, I missed that. aria-valuenow should be required for meter.

[zcorpan]

@scottaohara your suggested revisions LGTM.

@carmacleod maybe. Why is that in a separate section, though? (Maybe we should have a separate issue about this.)

[carmacleod]

@zcorpan

Why is that in a separate section, though?

We did a bunch of work on that section a year ago because:

1. Someone asked whether required attributes with default values should actually be required.
2. We decided to move some attributes from required to supported.

In case it's useful to know, here are some issues that were related to that work and a wiki page that lists which attributes were problematic.

I think it's in a separate section because it's intended for User Agents, not authors. Authors should be able to get all of the info they need from the role spec, i.e. if an attribute is required, then it's required. They don't need to know what fallback value the UA might use... and they definitely shouldn't rely on it.

(Maybe we should have a separate issue about this.)

Agree. I'll open one after I look through the spec for "missing required attributes" inconsistencies.

[scottaohara]

@carmacleod regarding why progressbar min/max aren't in the table you referenced, and why it looks like meter's min/max shouldn't go there either, here's the note following that table:

Implicit Values for non-required states and properties appear in the characteristics table for each role. These are not considered fallback values so are not included here.

meter's valuenow, being required, should be added to this table though.

[css-meeting-bot]

The ARIA Working Group just discussed Meter role.

The full IRC log of that discussion

<carmacleod> TOPIC: Meter role
<carmacleod> github: https://github.com//issues/1123
<carmacleod> carmacleod: related to https://github.com//issues/1206
<carmacleod> joanie: we should do this for 1.2
<carmacleod> jamesn: changing to 1.2
<carmacleod> mck: still an issue around valuetext - if using that, why do you need min and max at all?
<carmacleod> zakim, next item
<Zakim> agendum 5. "Wide Review Comments with PRs" taken up [from jamesn]
<carmacleod> https://github.com/w3c/aria/issues?utf8=%E2%9C%93&q=is%3Aopen+label%3A%22WR+comments%22+label%3A%22has+PR%22+

[carmacleod]

From the ARIA Working Group discussion in the comment above:

mck: still an issue around valuetext - if using that, why do you need min and max at all?

Note that the valuetext issue is captured in #1128.