Accessibility challenges while navigating and reading in vscode

[rgpkms]

I am currently using windows10(Microsoft® Windows® Operating System Version 10.0.19041.329), vscode(Visual Studio Code Version 1.49.2), JAWS 2020 screen reader for reading code in vscode. I have encountered the following issues:

1. In order to navigate and read character by character we require to press right arrow key to move to next character and left arrow key to move to previous character. But in vscode while I am pressing right arrow key to move to next character the cursor is moving, but the screen reader is reading the previous character it read previously. This issue is causing difficulty in reading because 2 scenarios can occur which can be difficult to identify:
   a. The word is 'need'. so if the screen reader reads the character 'e' twice it is correct behavior.
   b. The word is 'read'. If after reading character 'e' it again reads 'e' instead of 'a' it is incorrect behavior.
   Also this issue is not occurring frequently, rather an intermittent behavior which randomly springs up.
2. similar issue comes up when we use down arrow key to move to next line in the code and up arrow key to move to previous line. While pressing down arrow key the cursor has moved to next line, but the screen reader reads the previous line. Again as mentioned above there are 2 scenarios possible which are difficult to differentiate and identify:
   a.
   i. if() {
   ii. console.log('Hello');
   iii. }
   If the screen reader reads 'if statement' twice it is incorrect behavior in above snippet because second line is 'console.log()'.
   b.
   i. console.log('hello');
   ii. console.log('hello');
   If now screen reader reads the line twice it is correct as same line is written 2 times in the snippet.
   The first scenario I have mentioned is again a intermittent behavior observed in vscode while reading the code and it causes a person using screen reader to skip a particular line of code.
   Comment: While checking with another open source screen reader 'NVDA', the same issue is not observed by me , but needs further investigation using ‘NVDA’ as the issue might be present in NVDA as well since it is not a very frequent behavior and primary screen reader used by me is 'JAWS'.

[isidorn]

@rgpkms thanks a lot for providing feedback.
Here's a similar issue #90578

If you use NVDA it would be great if you can check if you reproduce this with NVDA?
Apart from that it would be great if you check if you can reproduce this behavior with just Chrome textArea, for example this site has a textArea https://bocupp-microsoft.github.io/sample-code/textarea/setselectionrange-performance.html and you could double check if JAWS behaves the same there

[rgpkms]

I do not use NVDA, JAWS is my primary screen reader. Though I tried a bit with NVDA and I was unable to reproduce the same issue. Also I can not reproduce the same issue with chrome text area while using JAWS.

[isidorn]

@rgpkms if you can not reproduce the issue with NVDA then it might be a JAWS limitation and maybe we should mention it here #95225
Also fyi @ggordon-vispero

If you can not reproduce the issue with Chrome and JAWS then it might be fixed in later Chrome versions, which means we would pick up the fix with Electron updates.

[isidorn]

Closing this, as we already have an issue where we listed the jaws limitations with VS Code.