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

[scottaohara]

Happened across this issue in axe-core today - https://github.com/dequelabs/axe-core/issues/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]

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]

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" ?

[spectranaut]

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

[scottaohara]

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.

[spectranaut]

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