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.

Sign up for GitHub

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

Jump to bottom

Should aria-valuenow be required if aria-valuetext is used? #2260

Open
scottaohara opened this issue Jun 26, 2024 · 5 comments · May be fixed by #2290
Open

Should aria-valuenow be required if aria-valuetext is used? #2260

scottaohara opened this issue Jun 26, 2024 · 5 comments · May be fixed by #2290
Assignees
@adampage

Comments

@scottaohara
Copy link
Member

Happened across this issue in axe-core today - dequelabs/axe-core#4515, and I think it raises a good question. Is there a good reason (for a user) for an author to need to maintain both an aria-valuenow and an aria-valuetext?

take for instance the youtube video scrubber:

<div class="ytp-progress-bar" tabindex="0" role="slider" 
  aria-label="Seek slider" aria-valuemin="0" aria-valuemax="30" aria-valuenow="13" 
  aria-valuetext="0 Minutes 13 Seconds of 0 Minutes 30 Seconds" style="">

if one were to remove the aria-valuenow, from my quick testing with Narrator, VoiceOver (macos/ios), NVDA and JAWS, there was no negative user impact to understanding the slider since the aria-valuetext was still being conveyed.

the visual styling of the indicator for sliders, progressbars, etc., are often not even based on the value of aria-valuenow

so largely this seems like it might just be 'extra work' for developers if they're using aria-valuetext, but still being required to declare an aria-valuenow which doesn't get exposed to users, and is not often the source of the visual styling for the slider/progressbar/etc. indicator.

But, maybe i'm missing something and this attribute still can be accessed and has value to users I'm not thinking about???

I'm less concerned about if authors might have use for it - cause if they do, great. Keep using it. This issue is just focused on determining why it needs to be an author requirement to specify the attribute if an author doesn't need it / it isn't being exposed to users anyway?
@patrickhlauke
Copy link
Member

I've been doing some random testing just today, coming at this from the different side (just having aria-valuenow and how horribly inconsistently it's announced across browser/SR combinations, particularly on Windows, which leads me to say currently authors should always use aria-valuetext to try and harmonise things). The programmer in me sees the difference between having the actual hard numerical value of aria-valuenow, and the human-understandable string exposed via aria-valuetext - though of course, they're all just strings, I know.

Incidentally, in at least some variation (it may have been Safari/VoiceOver/macOS), it seems that using both aria-valuenow and aria-valuetext leads to double announcements of the value (once for the valuetext, then once more for the - computed - percentage value of valuenow in relation to aria-valuemax ... a calculation/computation that not all browser/SR combos do, incidentally, as the Windows ones seem to just blurt out valuenow verbatim).

(hat-tip to @aardrian for pointing me to this issue just now)

@patrickhlauke
Copy link
Member

patrickhlauke commented Jul 6, 2024 •
edited
Loading

a few quick points from my testing - using just aria-valuetext and no aria-valuenow

<div class="progress" aria-label="Download"
     role="progressbar" aria-valuemin="0" aria-valuemax="100"
     aria-valuetext="custom indeterminate">
  …
</div>
  • Chrome/NVDA and Edge/NVDA announces this as "Download, busy indicator" (completely ignores aria-valuetext)
  • Chrome/Narrator and Edge/Narrator announces this as "Download, 0% progress bar" (completely ignores aria-valuetext)
  • Firefox/Narrator announces this as "Download, 50% progress bar" (not only completely ignores aria-valuetext, but also assumes that absence of aria-valuenow means it's at 50%)
  • Chrome/JAWS and Edge/JAWS announces this as "0 progress bar indeterminate" (ignores both aria-label and aria-valuetext)
  • Safari/VoiceOver/iOS announces it as "Download Indeterminate" (ignores aria-valuetext)
  • Safari/VoiceOver/macOS and Chrome/VoiceOver/macOS announces it as "custom indeterminate, Download, indeterminate, progress indicator" (it prefixes it with aria-valuetext, but still reckons it's "indeterminate")
  • Firefox/VoiceOver/macOS announces it as "Download, 50%, progress indicator" (ignores aria-valuetext and assumes absence of aria-valuenow means it's 50%)
  • Firefox/Talkback/Android announces it as "50.0, Download, progress bar" (ignores aria-valuetext and assumes absence of aria-valuenow means it's 50%)

from my quick testing with Narrator, VoiceOver (macos/ios), NVDA and JAWS, there was no negative user impact to understanding the slider since the aria-valuetext was still being conveyed

haven't got the energy to run my whole battery of tests again using slider rather than <progress>/role="progressbar" at this point, but it sounds like there's definitely a problem when it comes to those, compared to <input type="range"> / role="slider" ?

@patrickhlauke patrickhlauke mentioned this issue Jul 8, 2024
Open
@spectranaut
Copy link
Contributor

Discussed briefly in today's meeting, no conclusion was reached: https://www.w3.org/2024/07/11-aria-minutes.html#t08

@scottaohara
Copy link
Member Author

per the way the conversation was going towards the end of the call today, i think it's important to reiterate that the proposal here isn't to say there is no value to aria-valuenow, or to even try and say that authors don't need the attribute, or that there couldn't be uses cases for using both together.

the point is to acknowledge that there are use cases where using both together is unnecessary and potentially even unwanted for the intended user experience. but right now it is "required" to specify both, and that seems overly prescriptive.

@jnurthen jnurthen removed the Agenda label Jul 18, 2024
@spectranaut
Copy link
Contributor

Discussed in today's meeting: https://www.w3.org/2024/07/18-aria-minutes.html#t08

@adampage adampage linked a pull request Jul 20, 2024 that will close this issue
Open
6 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@adampage adampage

Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Relax aria-valuenow requirement on slider role adampage/aria
5 participants
@spectranaut @patrickhlauke @adampage @jnurthen @scottaohara