Unclear purpose of `aria-valuemin` and `aria-valuemax` when `aria-valuetext` is used

[zcorpan]

See https://github.com/w3c/aria-practices/pull/1279#issuecomment-561665079

I'm not certain what to say about the purpose of aria-valuemin and aria-valuemax when aria-valuetext is used. Any suggestions?

I think the ARIA spec could be clearer about how ATs are expected to use these attributes. As it is, if an AT only ever exposes aria-valuetext, it is unclear what the purpose is for providing aria-valuemin, aria-valuemax and even aria-valuenow.

If an AT communicates that there is a minimum and maximum value, should it use the numbers? The number won't make much sense if changing to that value is then communicated differently with aria-valuetext. But the AT can't know ahead of time what the app will change aria-valuetext to after changing the value.

Maybe when aria-valuenow matches either aria-valuemin or aria-valuemax, the AT could say that the current value is the minimum or maximum value?

How do existing AT handle these attributes?

Roles where they apply:

• meter
• progressbar
• scrollbar
• separator (if the element is focusable)
• slider
• spinbutton

[joanmarie]

ATs can also use min and max to express where in the range the current value is (i.e. as a percentage).

ATs get this information for native host language range elements as well as for native/desktop toolkits. Exactly how they choose to use this information is (I would argue) up to them. But I think we want consistency: Users, and their ATs, should not have to worry if something is native web, native desktop, or divs and spans ARIAed up into widgethood (widgetocity?). :smile:

[JAWS-test]

If aria-valuenow is output as a percentage value (for progressbar and scrollbar) it is unclear what aria-valuemin and aria-valuemax are needed for, since their value is irrelevant. So the following would lead to the same output (50%) <div role=progressbar aria-valuemin=1 aria-valuemax=3 aria-valuenow=2>

<div role=progressbar aria-valuemin=20 aria-valuemax=40 aria-valuenow=30>

In my opinion it would be sufficient if only aria-valuenow or aria-valuetext is given.

[carmacleod]

If aria-valuenow is output as a percentage value (for progressbar and scrollbar) it is unclear what aria-valuemin and aria-valuemax are needed for

I guess it lets the author choose numbers that make sense for their domain, i.e. if there are 17 files to load, set min=0 and max=17, and then valuenow can just be how many files are loaded. It might make the code look cleaner than calculating the percentage.

Also, AT could hypothetically say "5 of 17" instead of percentage if the user asked for details.

[carmacleod]

When discussing the current issue: "Unclear purpose of aria-valuemin and aria-valuemax when aria-valuetext is used", we should probably include thinking about issue https://github.com/w3c/aria/issues/711 "aria-valuetext would be useful on many more roles".

[JAWS-test]

@jscholes wrote:

I'm not sure I agree with that, particularly in a slider using aria-valuetext where the accepted range (e.g. days of the week) could potentially be inferred by the user. Really, I'm not sure why aria-valuemintext/aria-valuemaxtext (or similar) don't exist.

[brennanyoung]

I don't think aria-valuemin and aria-valuemax always being announced as percentages serves users very well.

There are many cases when there is a numerical value that is not a percentage, as in @carmacleod's "5 of 17" example.

And I think there should be much clearer guidance about what should happen when aria-valuemin is not zero.