aria-valuetext for progress bars not working

[nvaccessAuto]

Reported by jobara on 2010-09-17 13:51 http://fluidproject.org/releases/1.2.1/demos/progress/html/progress.html

The above demo uses the aria-valuetext property to provide more meaningful progress information to the user. In JAWS it reads this text as it announces updates to the progress. With NVDA there are no announcements. However, if the aria-valuetext property is removed, the tones indicating progress are sounded.

It would appear, from the aria spec, that this should be a valid use of the aria-valuetext property. http://www.w3.org/TR/wai-aria/states_and_properties#aria-valuetext

[nvaccessAuto]

Comment 1 by terrill on 2014-08-12 03:30 A bit more information about this defect: Given an HTML5 widget with role="slider", if both aria-valuenow and aria-valuetext are present, screen readers should announce aria-valuetext instead of aria-valuenow, as it's the human-readable text alternative of aria-valuenow:
http://www.w3.org/TR/wai-aria/states_and_properties#aria-valuetext

NVDA 2014.2 does this currently in Firefox, but '''not''' in IE (tested in IE11). Instead, it reads aria-valuenow. IE is apparently exposing aria-valuetext, because JAWS 15 and Window-Eyes 8.4 announce it correctly in IE11.

Here are a couple of basic test pages that I created:

• [http://terrillthompson.com/tests/slider2.html

[nvaccessAuto]

Comment 2 by jteh (in reply to comment description) on 2014-08-24 22:38 Replying to jobara:

The above demo uses the aria-valuetext property to provide more meaningful progress information to the user. In JAWS it reads this text as it announces updates to the progress. With NVDA there are no announcements. However, if the aria-valuetext property is removed, the tones indicating progress are sounded.

The issue is that value text overrides the value that NVDA receives. NVDA's progress bar reporting relies on a numeric value in order to produce beeps and to limit the amount of values spoken so the user isn't flooded (currently every 10%). However, it seems we can still get the numeric values a different way (IAccessibleValue).

[nvaccessAuto]

Comment 3 by jteh (in reply to comment 1) on 2014-08-24 22:42 Replying to terrill:

A bit more information about this defect: Given an HTML5 widget with role="slider", if both aria-valuenow and aria-valuetext are present, screen readers should announce aria-valuetext instead of aria-valuenow, as it's the human-readable text alternative of aria-valuenow:

NVDA 2014.2 does this currently in Firefox, but '''not''' in IE (tested in IE11).

This is actually a different issue. In the original issue, aria-valuetext does take effect, but it breaks progress bar reporting. This leads me to assume the reporter was using Firefox.

IE is apparently exposing aria-valuetext, because JAWS 15 and Window-Eyes 8.4 announce it correctly in IE11.

It doesn't expose it via MSAA. It seems it does via UIA, but for various reasons, we can't use that in IE. Therefore, we'll just need to do more DOM parsing (which is almost certainly how other screen readers do it).

Please file a separate ticket for this issue. Thanks!

[LeonarddeR]

CC @feerrenrut @jcsteh I wonder whether we should close either this issue or #6561, probably this one. Anyhow, there is a lot of duplicate information, and the underlying problem is quite similar.

[jcsteh]

This issue covers problems with progress bar reporting when aria-valuetext is used. #6561 covers aria-valuetext in IE for sliders. There is some conflation in some comments, but they are separate issues. Thanks.

[jcsteh]

P3 for ARIA spec compliance.

[fstrr]

Updated test case for this issue. This problem still exists in Firefox 103 running on Windows 11 and NVDA 2022.2. Interestingly, the problem only exists if role="progressbar" is used to mark up something as a progress element. If a native HTML progress element is used, the aria-valuetext property value is announced. Chromium browsers don't have this issue.

[jcsteh]

The scope of this issue has gotten very confused. :)

The original issue reported in https://github.com/nvaccess/nvda/issues/913#issue-116024040 was that aria-valuetext updates to progress bars weren't being reported. This is still the case in both Firefox and Chrome:

data:text/html,<div id="progress" role="progressbar" aria-valuetext="1 chicken" style="width: 5px; height: 5px;"></div><script>let number = 1; function update() { progress.setAttribute("aria-valuetext", ++number + " chickens"); setTimeout(update, 1000); } setTimeout(update, 1000); </script>

The expected result of this test case is that every second, a new value - e.g. "2 chickens", "3 chickens" - should be reported. Instead, you hear nothing.

The issue reported in https://github.com/nvaccess/nvda/issues/913#issuecomment-1216896226 is that an ARIA progressbar containing another element does not get rendered in NVDA browse mode. This needs to be fixed in Firefox. I'll file a bug for that shortly. A temporary workaround is to set aria-hidden on any elements inside the element with role="progressbar".

[fstrr]

Ah, I missed the part about updates not being reported—thanks for pointing that out. On the plus side, it looks like I found another bug. Thanks for filing that.

[nmlapre]

Hiya! Wanted to circle back here to say that this aspect of the issue:

an ARIA progressbar containing another element does not get rendered in NVDA browse mode

is now fixed in the latest Firefox Nightly. More info here on bugzilla. In short, NVDA should now read out aria-valuetext on progress bars as expected. As far as I can tell, the issue with aria-valuetext updates to progress bars is still present. Thanks!

[jcsteh]

Removing Firefox label since the Firefox specific part of this is fixed.

[Adriani90]

@jcsteh only the part with appearance of the values in browse mode is fixed, but not the automatic reporting while the progress bar is updating. As far as I understand this issue, the updated value should be reported dynamically when using report of dynamic content in NVDA object presentation settings. At least this is how Jaws works.

To avoid multiple reportings of several progress bars at once, would it be possible to report only the dynamic content of the progress bar which is focused with the NVDA review cursor? Background: in some scenarios users might disable "NVDA cursor follows system focus" to get updates from a specific progress bar while doing something else in parallel.

[Adriani90]

I filled a bug on Chromium for this as well: https://bugs.chromium.org/p/chromium/issues/detail?id=1498391

[Adriani90]

The browse mode issue is now also fixed in Chromium 127.

But the automatic reporting of the dynamically changing content is also not working when this setting is enabled in object presentation settings. I think this needs to be fixed in NVDA. @SaschaCowley, @jcsteh is this correct?

[jcsteh]

Firefox fires value change events. I don't know whether Chrome does, but I suspect so. So yes, to get this reported automatically, that would require a change in NVDA.

Right now, NVDA is pretty specific about how progress bar updates are reported because of progress bar beeps, suppressing speech updates so the user isn't flooded with a lot of quick updates, etc. Thus, it only handles numeric progress bar values. A solution for this raises a couple of tricky questions:

1. What do we do if the user has beep for progress bar updates set? Strictly speaking, we shouldn't be speaking any updates in this case. On the other hand, we can't meaningfully beep for arbitrary text. It's hard to win here. If we report something, users might complain that they have it set to beeps, so it shouldn't speak. But equally, other users will complain that nothing gets reported.
2. How do we suppress excessive updates? Right now, when set to speak progress bar updates, NVDA speaks only at 10% intervals to avoid spamming the user. But for arbitrary text, we can't know which updates to speak, since they're not numeric.

[Adriani90]

1. What do we do if the user has beep for progress bar updates set? Strictly speaking, we shouldn't be speaking any updates in this case.
2. How do we suppress excessive updates? Right now, when set to speak progress bar updates, NVDA speaks only at 10% intervals to avoid spamming the user. But for arbitrary text, we can't know which updates to speak, since they're not numeric.

We could add a new checkbox setting for reporting of progress bar values with arbitrary text or numbers. Instead of definining percent intervals, we could define time intervals for this type of progress bar reporting. NVDA could show a spin button when this checkbox is enabled, and the user could adjust the time interval the progress bar updates should be reported. If the user choses 1.5 seconds, every 1.5 seconds NVDA checks the text or numbers value of the progress bar when focused with the navigator, system focus or mouse cursor.

[jcsteh]

To avoid multiple reportings of several progress bars at once, would it be possible to report only the dynamic content of the progress bar which is focused with the NVDA review cursor?

I think this is likely out of scope for this request. Progress bar reporting occurs within the foreground window across the board right now, and for a numeric progress bar, it works the same way in browsers. I'd suggest filing a separate enhancement request for that if you want it.