Screen reader speaks the message "Occurs n times" Repeatedly When Searching For Extensions

[jhomme]

• VSCode Version:
• OS Version:

Steps to Reproduce:

• From the application, press CTRL+SHIFT+P.
• Slowly type characters and after each one, listen for the phrase. For example, slowly type the word "python."

Does this issue occur when all extensions are disabled?: Yes/No

[isidorn]

@jhomme I believe you meant Ctrl + Shift + X to open the extensions viewlet, correct?

@sandy081 I believe the issue is that in the extensions view we use alert too much. Code pointer
To be honest I think most of those alerts are not that useful.

Also I do not understand why an alert here is needed

@sandy081 for now assigning also to you. And also assigning to May as it would be cool if we look next milestone into this.

[jvesouza]

When I type in a pattern to look for an extension, I hear the number of extensions found and the message occurs N times.
The information regarding the number of extensions found is very useful and should be preserved if possible.

[MarcoZehe]

I agree, the only thing we don't need is the counter that a particular alert fired x times. This might be useful for some debugging scenario, but is nothing useful for actual users.

[isidorn]

Thanks for feedback.

The issue was the following: we "fire alerts" in a way that we write content to a container with role = alert.
So what could happen in theory is the following

1. We fire an alert "Hello User"
2. User does some work
3. We want to fie an alert "Hello User" again, however since the content of the alert container would not change the new alert would not get read by the screen reader. And due to that we were adding "Occurred n times" ending.

I have now changed this behavior and we would not add the "Occurred n times" ending and this might lead to some duplicated consectuive alerts not being read. But I think that is fine. So try it out from tomorrow's vscode insiders and let me know.

Still leaving this issue open since I am still not sure why we have an alert here. Once @sandy081 comments we can close this.

[MarcoZehe]

One way to make sure the alert always gets spoken when text changes is to set aria-atomic to true. Normally, if Chromium implements the alert role properly, this is implicitly set, in addition to aria-relevant being of value "additions text". So one thing to try is to set aria-atomic="true" on the same element that has role "alert", to see if that fixes the problem if the same text is pushed to the alert. Otherwise, first removing all text, then adding it again, might also trigger proper speaking. Just some ideas.

[isidorn]

@MarcoZehe good ideas. However we arleady set aria-atomic on the element. Code pointer.
I just tried setting the textContent to an empty string before resetting it and it did not work (at least with VoiceOver). I also tried some timeouts and also did not help.

So I do understand that my change is a bit risky since two consecutive equal alerts will not be read and we will probably revert that but would still like to try it out.

[webczat]

so not sure how that works in other screenreaders? especially if it's true aria-atomic should make it being read always on change even if the text is the same...

[sandy081]

@isidorn the alert here is to inform user that

• there are no extensions found or
• there is an error while fetching extensions

I cannot repro the alert happening N times this with the steps mentioned using Voice Over in Mac. Can you please help ti repro?

[isidorn]

@sandy081 ok makes sense.
As for the N times you can no longer repro out of source due to my commit 9f709d1

So either revert that commit or take insiders which does not have it.
Turn on VoiceOver, type in the extensions view slowly and you will notice that sooner or later he will say something like "46 extensions found (occured again)"
I always repro for the following case: type "a", wait a bit delete "a" - two messages with "occured again" happen

[jhomme]

Hi,
Maybe this comment is meant to aim at something too specialized. I have never gotten JAWS or NVDA to speak the status line by using the screen reader keys meant for that purpose. If VS Code could re-display alerts by pressing a key stroke, would that be something that should happen or is it the job of the screen reader vendor or, is it the job or whatever of someone who might make an extension meant to enhance accessibility? And I do not know which alerts I would want repeated. I'm too new a user for that right now. I happened to go into Browse mode and realize that there is a lot of good information that it might be convenient to re-read without needing to leave the editor.

[isidorn]

@jhomme thanks for providing more details. I think that as a feature makes sense, however for me it feels like it should be implemented in Screen Readers - so users can repeat what got announced.
Maybe you can start a discussion in our accessibility channel?

[jvesouza]

@isidorn Orca has a command called 'review live region announcement' that I use for this purpose. With this command I can hear the 9 latest ads. Perhaps the jaws and the nvda have something similar.

[jhomme]

Hi, I will check JAWS and NVDA for settings like these. Jim

[jhomme]

Hi,
I used the JAWS key stroke, SHIFT+INSERT+F1 to see what I could find out in the area of the status bar. I did not see aria-live. I then went to this article about aria-live to try to understand how this is supposed to work. The article made me think that perhaps the status line would behave better if it used aria-live. Another thing I thought of as a convenience might be to create a landmark or use a footer tag around the whole area where VS Code displays status information.

Finally, I checked, and the JAWS and NVDA status line reading commands are meant to show the status line of an application, and I do not think this seems to work well in browsers.

[isidorn]

@jhomme we actually do set the aria-live attribute on the container which we use to "broadcast" alerts.
We also use aria-live on the status container. This is not being read by NVDA due to this issue which they are looking into fixing nvaccess/nvda#11064

[isidorn]

This should be fixed now. Please let me know if you still see this with latest vscode insiders

[Neurrone]

Verified with NVDA and latest insiders. I suspect this was fixed a while ago because come to think of it its been a while since I've heard that when searching for extensions.

[isidorn]

Great, thanks. Adding verified label.