aria-valuenow range requirement for meter role, non-consistent with other "similar" roles

[giacomo-petri]

Concern description:

Concerning the "meter" role, ARIA doc states:

The value of aria-valuenow MUST NOT fall below or exceed the computed values of aria-valuemin and aria-valuemax, respectively.

However, this requirement does not seem to apply to other "similar" roles such as:

• scrollbar
• separator
• slider
• spinbutton

or scrollbar, separator (if focusable), and slider roles, aria-valuenow is required but doesn't have a strict range requirement.

Is there a specific reason why this requirement is not applicable to these particular roles?

If it's just an inconsistency, might be worth if we remove the first requirement from meter role

The value of aria-valuenow MUST NOT fall below or exceed the computed values of aria-valuemin and aria-valuemax, respectively.

and maybe add this requirement into the definition of aria-valuenow, adding something like:
"if aria-valuemin and aria-valuemax are set, then ..."

or, in alternative, add the statement

The value of aria-valuenow MUST NOT fall below or exceed the computed values of aria-valuemin and aria-valuemax, respectively.

also to the other roles?

[spectranaut]

@giacomo-petri to check if this behavior is consistent with HTML then we will discuss

[rahimabdi]

Should this guidance change also apply to role="progressbar"?

[giacomo-petri]

I'm listing below the output of my analysis, role by role, with references to the html5 specs:

• ARIA ROLE: meter
  RELATED CONCEPT in HTML: <meter>
  HTML SPECS: https://html.spec.whatwg.org/#the-meter-element

  If the min attribute is specified, then let minimum be that attribute's value; otherwise, let it be zero.

  If the max attribute is specified, then let maximum be that attribute's value; otherwise, let it be 1.0.

  The following inequalities must hold, as applicable:

  minimum ≤ value ≤ maximum
  minimum ≤ low ≤ maximum (if low is specified)
  minimum ≤ high ≤ maximum (if high is specified)
  minimum ≤ optimum ≤ maximum (if optimum is specified)
  low ≤ high (if both low and high are specified)

  RESULTS: ARIA specs align with HTML specs.

• ARIA ROLE: progressbar
  RELATED CONCEPT in HTML: <progress>
  HTML SPECS: https://html.spec.whatwg.org/#the-progress-element

  The value and max attributes, when present, must have values that are valid floating-point numbers. The value attribute, if present, must have a value equal to or greater than zero, and less than or equal to the value of the max attribute, if present, or 1.0, otherwise. The max attribute, if present, must have a value greater than zero.

  RESULTS: ARIA specs DO NOT align with HTML specs.

• ARIA ROLE: scrollbar
  RELATED CONCEPT in HTML: No direct related concept, but similar to <input type="range">
  HTML SPECS: https://html.spec.whatwg.org/#range-state-(type=range)

  When the element is suffering from a step mismatch, the user agent must round the element's value to the nearest number for which the element would not suffer from a step mismatch, and which is greater than or equal to the minimum, and, if the maximum is not less than the minimum, which is less than or equal to the maximum, if there is a number that matches these constraints. If two numbers match these constraints, then user agents must use the one nearest to positive infinity.

  RESULTS: ARIA specs align with HTML specs.

• ARIA ROLE: separator
  RELATED CONCEPT in HTML: No related concept if focused, <hr> if statics
  HTML SPECS: https://html.spec.whatwg.org/#the-hr-element

  HTML 5.2 covers only static <hr> element, nothing interesting to reference

  RESULTS: Since this is specific to ARIA, it might be advisable to request the author to ensure that min ≤ value ≤ max.

• ARIA ROLE: slider
  RELATED CONCEPT in HTML: <input type="range">
  HTML SPECS: https://html.spec.whatwg.org/#range-state-(type=range)

  When the element is suffering from a step mismatch, the user agent must round the element's value to the nearest number for which the element would not suffer from a step mismatch, and which is greater than or equal to the minimum, and, if the maximum is not less than the minimum, which is less than or equal to the maximum, if there is a number that matches these constraints. If two numbers match these constraints, then user agents must use the one nearest to positive infinity.

  RESULTS: ARIA specs align with HTML specs.

• ARIA ROLE: spinbutton
  RELATED CONCEPT in HTML: <input type="number">
  HTML SPECS: https://html.spec.whatwg.org/#number-state-(type=number)

  No mention about the value range

  RESULTS: ARIA specs align with HTML specs.

[giacomo-petri]

I forgot to say that the review above also match with the w3 html validator:

[scottaohara]

a use case to consider in determining what to do here:

a meter could very well be used to present the amount of storage space a user has for a product of some sort, a mailbox, file storage, web hosting, whatever.

generally the meter would only allow a user to have their storage usage fall between the 0 to 100% of what their account allows. but, there are instances where a user's account is modified and their available storage is decreased. but the product won't typically delete their content to get them back down to their storage ceiling. Rather, the value can become larger than the maximum.

This can be handled by adding extra text to say the account is over the limit, potentially even removing the instance of the meter so that there isn't a disconnect with the element stating it's at 100% with additional content saying it's more than 100%. So, really don't mind if it stays the way it is, esp. since it aligns with HTML. But, also, maybe HTML is being too strict...