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](http://terrillthompson.com/tests/slider.html]
  *)

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

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!

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.

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.

P3 for ARIA spec compliance.

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.

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

The original issue reported in #913 (comment) 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 #913 (comment) 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".

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.

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!

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

@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.

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