Progress Bar label is not read

[jnurthen]

Summary

The ARIA spec states that Progress Bars MUST have an accessible name. JAWS ignores this accessible name when reading the progress bar

Expected result

JAWS should read the accessible name and the value

Actual result

Only the value is read

Example

1st progressbar at https://codepen.io/jnurthen/full/qBErmdB Chrome & FF both read -50% Progress Bar

Accessibility Viewer shows the following IAccessible2 information: Name: Loading... Role: progress bar Value: 50%

so all of the information required is being exposed by the browser.

Additional Information

JAWS version and build number JAWS 2018.1811.30

Operating System and version Windows 10 19013.1122

Browser and version: FF 71.0 Chrome 79.0.3945.88

[JAWS-test]

The problem occurs in addition to Firefox and Chrome also in IE 11 (and also with JAWS 2019 and JAWS 2020)

@jnurthen The example from you uses the same IDs several times, e.g. for aria-labelledby. This is not the cause of the problem, but can be fixed to avoid distorting the test

[jnurthen]

@JAWS-test thanks. I’ll fix the test case tomorrow. I thought I’d got the duplicates when I copied pasted but must have missed some.

[JAWS-test]

The IDs a-1 and a-2 occur twice

[kurtjwolf]

Similar progress bar issues filed with internal bug #113675

[jelbourn]

This issue is quite a thorn for building any sort of progress-bar component on the web. Because JAWS does not read labels for role="progressbar" elements, it effectively prevents the use of this role in any way, forcing common components to fall back to less effective patterns, negatively impacting the experience for all users, even the ones not using JAWS.

[scottaohara]

This remains an issue with JAWS 2021

[vick08]

Can we please get a confirmation and the ETA from JAWS developers as to when this issue will be addressed? As mentioned above, we would like to avoid creating hacks to deviate from ARIA spec to provide good user experience.

[stevefaulkner]

Tested in JAWS 2024.2405.48 and Chrome Version 126.0.6478.127 (Official Build) (64-bit). Agree the progress bar label is not announced by default, but is announced consistently when insert+tab is pressed when the progress bar has virtual focus.

Read Control and Help - INSERT+TAB

INSERT+TAB speaks the tutor message for the current control or window, and the access key to move directly to that control, if one exists. Using this keystroke is a great way to review tutor and access key information without moving away from a control and back, and without needing to turn on automatic announcement of these messages.

Source: JAWS help file

@BrettLewisVispero do you consider this to be a JAWS bug?

[patrickhlauke]

This is still an issue with JAWS 2024 (latest). using <progress> or an element with role="progressbar", the accName is simply not announced (whether it's using a separate <label> for the progress element, or aria-label/aria-labelledby).

simple test of a few variations ... they all announce the variations as "Download" in NVDA and Narrator, in Chrome/Edge/Firefox, as well as VoiceOver on iOS, macOS, Talkback on Android... JAWS is the only odd one out at the moment.

(as an aside, noticed while researching how various browser/SR combos deal with progress bars...there's other/different oddities here https://github.com/w3c/aria/issues/2260 ... but that's a separate discussion)

[stevefaulkner]

Yeah I noticed this too. It is not announced by default but is announced when insert+tab is used. It would be nice if announced by default but is it a requirement in any spec?

[patrickhlauke]

The spec doesn't say how/when UAs/SRs should announce the accessible name of a component. However, JAWS' current behaviour is an anomaly compared to all other tested SRs, so it's not following the de-facto standard behavior that is arguably expected. Makes it unnecessarily cumbersome/obtuse for users who have to know to do insert+tab when reading through the content and encountering a progress bar.