inform SR users of indeterminate progress bar updates

[meganrogge]

          > Another use case is in the scm view, when changes are getting committed or pushed, there's a progress bar. We should play the cue for this to indicate the non-visual state.

Screen.Recording.2024-04-04.at.7.53.21.AM.mov

if the proper markup is used, screen readers such as NVDA that support the progress bar pattern can communicate that using their standard mechanism. I don't oppose providing a vS Code signal if we believe it to be valuable, but I would prioritize supporting established accessibility practices first whenever possible.

Originally posted by @rperez030 in #196396 (comment)

The SCM view, settings search, and anywhere else with a progress bar should do this

[meganrogge]

@rperez030 this is already set 🤔

vscode/src/vs/base/browser/ui/progressbar/progressbar.ts

Line 65 in 8cf1fbe

this.element.setAttribute('role', 'progressbar');

[meganrogge]

It seems this is an issue for when we have infinite progress

#109219 (comment)

Looks like we're doing the right thing though:

A progressbar indicates that the user's request has been received and the application is making progress toward completing the requested action. The author SHOULD supply values for aria-valuenow, aria-valuemin, and aria-valuemax, unless the value is indeterminate, in which case the author SHOULD omit the aria-valuenow attribute. Authors SHOULD update these values when the visual progress indicator is updated. If the progressbar is describing the loading progress of a particular region of a page, the author SHOULD use aria-describedby to point to the status, and set the aria-busy attribute to true on the region until it is finished loading. It is not possible for the user to alter the value of a progressbar because it is always readonly.

[meganrogge]

After looking into this, I wonder if we should instead implement this on a case by case, as requested basis. My rationale is most of our progress indicators run for a very short duration, so this would rarely play. There's also a chance that a few signals could play at once, such as when a user reloads the window, would that be noisy?

Maybe this should be behind a setting and off by default?

cc @rperez030 and @jooyoungseo for input.

[rperez030]

in my opinion, unless we are certain that a progress can last more than 3 seconds and the duration is indeterminate, this is not needed.