Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
zcorpan opened this issue Dec 6, 2019 · 6 comments
Labels
clarification clarifying or correcting language that is either confusing, misleading or under-specified
Milestone

Comments

@zcorpan
Copy link
Member

zcorpan commented Dec 6, 2019

See w3c/aria-practices#1279 (comment)

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
Copy link
Contributor

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?). 😄

@jnurthen jnurthen added this to the ARIA 1.3 milestone Dec 19, 2019
@JAWS-test
Copy link
Contributor

JAWS-test commented Dec 20, 2019

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
Copy link
Contributor

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
Copy link
Contributor

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 #711 "aria-valuetext would be useful on many more roles".

@JAWS-test
Copy link
Contributor

@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
Copy link
Contributor

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.

@jnurthen jnurthen added the clarification clarifying or correcting language that is either confusing, misleading or under-specified label Sep 9, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
clarification clarifying or correcting language that is either confusing, misleading or under-specified
Projects
None yet
Development

No branches or pull requests

6 participants