Notify Screenreader Users When Inline Suggestions Or Decorations Available

[hediet]

This is a follow up to the feedback given in #129677:
Screenreader users are currently not being informed if there are inline suggestions available.

They have to check explicitly if there are inline suggestions available.

We should explore a push-based approach.

However, if there is almost always an inline suggestion (as it is the case with Copilot), too many notifications might get spammy very quickly.

---

A solution here might also be applied to diagnostics and quick fixes.

[isidorn]

In general we need a more powerful hidden TextEdit field to make this happen (to make the editor content more rich accessibility wise). I have tried to make this happen in the past, but was unable due to limited API of the contentEditable. More details here: #97154 (comment)

I think this is something we will need in general, however I am not sure if it would be possible to have this with the current DOM apis.

---

In case that is not possible than we would need a more specific solution for this particular case (like the status bar updating, or a quick announcement)

fyi @zersiax

[zersiax]

In case that is not possible than we would need a more specific solution for this particular case (like the status bar updating, or a quick announcement)

The status bar updating doesn't ping the screenreader afaik. So that wouldn't really help much. What do you mean by a quick announcement exactly?

[isidorn]

@zersiax that we aria live announce whenever there is an inline suggestion. Though this might be too noisy...

[zersiax]

Hmm ... mostly out of curiosity, would the same not work for other ornaments? We'd probably need a preference section to dial in what a person wants aria-live-announced at any given point, but it feels to me that if we can detect suggestions and aria announce them, could we not do similar things for the others, granting that this would be quite noisy if you have it on all at once?

[hediet]

What would the aria-live-announcement look like? Would it say something like "(Inline) Suggestions available"? Or would it also include the suggestion text?

Maybe we could also explore playing a super short non-speech sound that could possibly be played in parallel to any text speech output?

[isidorn]

Since this would be noisy I think it should be as short as possible and not include suggestion text. So that the user is notified but if the user wants to know more Cmd + K, Cmd + I is the way to go. So something like
suggestions, Cmd + K, Cmd + I

I like the idea of super short non-speech sound, even though we try not to do this in general and we leave this to screen readers. We try to provide the context, and we leave the announcing and producing sounds to the screen reader. However I am open for exploring this option.

[isidorn]

@joanmarie @LeonarddeR is there some way to make audio cues to the screen reader through aria attributes? In this particular case we would like a short "notification sound" to be sent to the user. And there are some other use cases where this could be helpful. Thanks

[joanmarie]

@isidorn Not in Orca. But could VSCode itself play sounds? (i.e. why does this need to be done through the screen readers?)

[hediet]

i.e. why does this need to be done through the screen readers?

I think it would be nice if various standardized notification sounds were a feature of screen readers:

• Standardization would allow to have recognizable sounds
• Those sounds could be customized system-wide (in terms of volume, speed, pitch etc.)
• VS Code currently does not play any sound by itself, I guess we would need to add a lot of dependencies to play sounds just for this use-case

[LeonarddeR]

Agreed with @joanmarie. Probably best to do this in Code itself. I believe they planned something like that for full Visual Studio as well.