Accessibility Issues with NVDA in Recent VSCode Releases

[GabrieleBattaglia]

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

• VS Code Version: last released
• OS Version: win11

Steps to Reproduce:

1. simple use it
   Description:
   I am using the stable release of VSCode with the latest version of NVDA and have noticed some accessibility regressions. I'm writing this message to ask for your feedback and to understand if these are real issues or a result of incorrect settings on my three machines.

Problem 1: Lack of Immediate Feedback on Edits

This first issue is a serious one. When I type, delete, or replace text in a document (for example, in a Python script), the change is not immediately reported by the screen reader. The change does occur visually on the screen, but it's as if NVDA is frozen until I move the cursor away from and then back to the modified area.

This also happens when pasting text. For example:
I am at the beginning of a line that I want to replace. I select the entire line with Shift+End, and the selection is read correctly. I then paste with Ctrl+V, and absolutely nothing happens—there is no speech feedback and no update on my Braille display. However, if I move the cursor vertically off the line and then back onto it, I can confirm that the text has been replaced correctly. This behavior is incredibly disruptive and is ruining my user experience with VSCode, which is my favorite piece of software and is always running on all my computers.

Problem 2: Change in Backward Word Selection

The method for selecting words has changed. If I am at the start of a sentence and press Ctrl+Shift+Right Arrow, I can correctly select consecutive words. This has always worked and continues to work as expected.

Previously, the same was true for selecting words backward from the end of a sentence using Ctrl+Shift+Left Arrow. Now, however, backward selection no longer works correctly. When I press the key combination, the word to the left of the cursor is selected. On the next press, that word is deselected, and the cursor moves to the beginning of that same word. Subsequent presses repeat this process for the next word to the left, and so on. This behavior seems illogical and does not serve a useful purpose.

Is anyone else experiencing these issues?
Are there any known solutions or workarounds? Are there any open issues on these topics?

Thank you very much for your help.

[meganrogge]

@GabrieleBattaglia sorry you're experiencing issues. Which version of VS Code are you on? I work with screen reader users and have not heard similar feedback.

[Neurrone]

I'm definitely experiencing these issues when editing markdown files. I'm still trying to pin it down because it doesn't happen all the time.

[meganrogge]

Which version of vs code?

[Neurrone]

Version: 1.103.0-insider (user setup)

Commit: 3b2551c

I don't have the first issue - when I paste text over a selection, I get feedback that the previously selected is no longer selected which is what I expect

However, I can reproduce the second issue.

If I have the following text in a blank document:

The quick brown

1. Place the cursor at the space between k and b
2. Press ctrl+shift+left. The word "quick" is selected, as expected
3. Press ctrl+shift+left again. This is where the bug happens: instead of extending the selection to the left, the word "quick" is now unselected.
4. Press ctrl+shift+left again. This selects "the", which is puzzling since this behaviour is not symmetrical with how extending the selection to the right works.

[meganrogge]

Thanks for the info. Did this occur in prior versions? If not, could you pls take these steps:

If this is a confirmed regression, it would help to know which change caused it. We maintain a node.js based CLI tool vscode-bisect that automatically downloads and runs previous VS Code insiders and asks for each build if the issue reproduces. It takes up to 8 steps to find exactly the build that caused the regression.

Steps:

• install node.js (if not yet done)
• npx --yes @vscode/vscode-bisect@latest
• follow the instructions until you found the offending build (its fine to leave the commit empty)
• report back the commit range in this issue

Thanks!

[rperez030]

setting editor.editContext to false seems to solve the problem for me.

@meganrogge

[meganrogge]

cc @aiday-mar

[Neurrone]

Ran the bisect tool and found the first bad build

[build] 6d98db08819f07a8541bfb396be1b0e6819f5d71 is the first bad commit after 6609ac3d66f4eade5cf376d1cb76f13985724bcb.

√ Would you like to open GitHub for the list of changes? ... yes

Run the following commands to continue bisecting via git in a folder where VS Code is checked out to:

git bisect start && git bisect bad 6d98db08819f07a8541bfb396be1b0e6819f5d71 && git bisect good 6609ac3d66f4eade5cf376d1cb76f13985724bcb

6609ac3...6d98db0

[aiday-mar]

Hi thanks a lot for bisecting. I have to look at this issue.