Windows Magnifier not following text caret when accessibility support is enabled

[SaschaCowley]

• VSCode Version: Code 1.48.2 (a0479759d6e9ea56afa657e454193f72aef85bd0, 2020-08-25T10:13:11.295Z)
• OS Version: Windows_NT x64 10.0.19041

Steps to Reproduce:

1. Launch VSCode and make sure accessibility support is enabled. 2.open/create a file. The file should be on multiple lines with decent length of lines. IE settings.json.
2. Launch magnifier, and ensure that it is set to follow the text cursor.
3. Try to navigate the file without editing it (IE with just the arrow keys).

Expected behaviour

• Magnifier should follow the caret as it moves.

Actual behaviour

• Magnifier may initially follow the caret, but will drift away from it over time.
• Inserting new characters seems to reset the detected caret position to the actual one, but deleting characters doesn't.

I conjecture that this is because the textbox used for the accessible editor isn't properly syncronised with the displayed editor, but I'm not familiar enough with the internals to know for sure.

There are a number of closed issues for this bug, but, testing both in stable and nightly, I am still experiencing it.

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

[isidorn]

@SaschaCowley thanks a lot for filling this. I can reproduce this. The textbox used for the accessible editor is properly synchronised with what is displayed - we always properly update the cursor position (otherwise many more things would be broken). I just checked and this works fine with just Chrome 83.

So I believe that what is confusing the Magnifier is that we are hidding our textArea. Alternative would be that we are just putting a subset of the whole text in the textArea but that can be controlled via accessibility.pageSize setting and changing that did not help.

I am also open to ideas. @alexdima might you have some idea, I know you tackled similar issue in the past.

[alexdima]

It looks like we have a regression from #83276 , I'm not sure what has changed.

[isidorn]

@alexdima I can look into all the changes and do some bisection.

[isidorn]

Just investigated a bit more and actually nothing changed. It seems like the original issue was not fixed when "editor.accessibilitySupport": "on" in settings. If accessibilitySupport is disabled then all works perfectly both then and now.

I have verified that the issue is here. If we return TextAreaState.EMPTY then all works fine (and that is the case when accessibilitySupport is turned off).

@alexdima I see the method getScreenReaderContent is only used here but I do not know how that would influence the behavior of the magnifier. Might you have an idea? I thought that there might be a problem because we write a subset of the actual editor content to the hidden textArea, however I can reproduce this problem even if I increased the editor.accessibilityPageSize setting so that we would write the whole editor content.

Since this is not a regression moving to September for now.

[alexdima]

@isidorn I'm sorry, I don't really know. I can speculate that perhaps the textarea is positioned at the cursor location, but the text inside the textarea overflows the 1px by 1px textarea and the native cursor is somewhere else. And perhaps the magnifier follows the native cursor?

[isidorn]

@alexdima no worries. Good ideas. I will investigate further in debt week.

[isidorn]

I have investigated a bit more into this and this is happening because as Alex suspected the cursor overflows out of the hidden textArea content. Windows Magnifier follows the cursor that is outside of the textArea and since the native curser is off the whole magnifier gets off.

I sent some email to the magnifier team and we can see if they have ideas on a work around in vscode on how to tackle this. We basically need to tell the magnifier to follow our cursor and not the native hidden cursor.

I could not figure out any native textArea api to force the textArea to reveal a cursor outside of the viewport. @alexdima let me know if you have some trick for this maybe.

In the meantime, the workaround for this issue is to set the following setting: editor.accessibilityPageSize: 2

[coryj627]

Any news on this @isidorn ? I reported this as well #77842 last year.

[isidorn]

@coryj627 unfortunately no news, the Windows Magnifier team did not yet respond to my email. I will ping them again.

[rafa11rodrigues]

I use ZoomText and Fusion, from AI Squared and Freedom Scientific, as screen magnifier. The behavior is exactly the same as described. I thought it was a specific problem of these softwares, but now I see it's related to VS Code. Cursor tracking works perfectly when editor.accessibility is off, but it causes VS Code to be unaccessible to screen readers like JAWS or NVDA. Yes, I'm parcially visual impared, so I use both screen reader and magnifier. It would be great if this issue was solved. Maybe you could try to get in touch with AI Squared and Freedom Scientific to get some help about this issue. They have a lot of experience about accessibility.

[isidorn]

@rafa11rodrigues I suggest to use the workaround for now In the meantime, set editor.accessibilityPageSize: 2 in your vscode settings.

I just emailed AI Squared and Freedom Scientific, however let's also check with @ggordon-vispero if he knows how do magnifiers follow native cursors and if VS Code could tell the magnifier to follow our cursor and not the native one.

[snufas]

I am trying to reactivate this issue, it is important, is ruining my experience for sure. I am using both screenreader and magnifier together, and this cursor tracking issue is annoying when you want a smooth experience. @isidorn you said in #149166 " this is one of those issue that we should invest in the future. I could not get far when contacting the magnifier software people to try to figure out how the magnifier follow the native cursor and if we could "trick it"." I would appreciate your help in raising this issue, and get it solved finally.

can someone do something about that, it cannot be left unsolved, it's a serious UX issue. VS team is doing great job regarding accessibility issues, someone needs to investigate this properly. Is it possible to escalate this issue a bit, it seriously important, of course is not a major problem, but it breaks the experience as I mentioned previously.

@isidorn @@alexdima @kieferrm @Tyriar I would appreciate your help and input.

[isidorn]

@snufas we have plans to fix this issue, and as we get more details I will comment here. Thank you.

[snufas]

@isidorn Please give more priority to this issue, it is very annoying to code while using magnifier... Because I cannot use magnifier properly in VS code, my back actually hurts... I have to use VS code more and more, and it is very annoying now to be honest, please track it down and fix that issue. I have to say most of the issues are fixed very quickly, but not this 1...

I am asking as a developer, please make my job easier, and save my back from pain, seriously... How much do I have to mention this issue until it's fixed??? I would really, really, really appreciate if this issue get some priority, because I will repeat myself again, it's getting very annoying, because I have to use this editor more and more daily.

[isidorn]

@snufas thanks for your feedback, as I mentioned above we do have plans to fix this, however the issue is not trivial. Let me assign it to September for an initial investigation.

[snufas]

@isidorn Thanks

[meganrogge]

@isidorn I do not have my windows computer with me. Could you pls test this on Windows given we think it might now be fixed? Otherwise, good to defer until November

[isidorn]

I have just tried it out on my windows machine and the issue seems to be fixed for me. With the caveat that the following setting has to be set "editor.accessibilityPageSize": 1. User that hit this issue can you please verify if the issue is indeed fixed for you. You can tryout vscode insiders https://code.visualstudio.com/insiders/ or wait for the stable release next week.

I am going to go ahead and close this issue, and if you still see the issue we will reopen. Thank you!

@meganrogge as a follow up I think we should investigate why is it really needed that pageSize is set to 1. It seems like the vertical positioning is not 100% correct when more than one line is put into the textArea.

[alexdima]

@isidorn @meganrogge The .scrollTop inside the <textarea> is currently only set on mac. If we would set it on all OSes I think that would help with the need to define "editor.accessibilityPageSize": 1

[isidorn]

Thanks! Created a follow up issue https://github.com/microsoft/vscode/issues/164591

[snufas]

@isidorn This issue is not fixed, because tracking doesn't work using left and right arrow keys. The cursor tracking works fine when you use Up Down ctrl + up,down, left, right. But doesn't work when you use left and right arrow keys on its own. So basically, the tracking does not work when you go through the code letter by letter. As you understand, it is quite an issue when you're trying to edit the existing code... I recommend to reopen this issue and keep it open until it's fully resolved. I have the latest VS code stable release running.

[rafa11rodrigues]

I just updated VS Code to last stable release, and it doesn't work even with ctrl+arrows. The issue is more evident when you have a long line. For example:

def foo():
    return 'Lets have a very long line to check if cursor track works fine with screen reader and magnifier enabled'

When I was typing, it worked perfectly, the screen moved so I could see the exact position of the cursor. But after typing, if I move by letter or word, it moves to somewhere else. Also happens when I try to select (holding shift).

And the most weird part is that the internal cursor looks to follow the blinking carret. I use JAWS as screen reader and ZoomText as screen magnifier, and ZoomText has a focus enhancement to highlight where the system cursor is. Before the VS Code update the highlight always got stuck at the first character of the line, now it's moving correctly following the blinking carret. But somehow the screen doesn't follow it correctly...

Why cannot it work as a regular text box? Even in Java applications the cursor is tracked correctly, and Java accessibility is a mess...

[coryj627]

Hi @isidorn is there any update on work for this issue? I asked 2 years ago, and this issue is even older than this ticket. :(

[isidorn]

@coryj627 no updates. I agree we should do another investigation here. I will try for us to get it on the plan again. Thank you

[isidorn]

@meganrogge pushed a fix for this issue. We have verified that this indeed improves the behaviour of ZoomText software on Windows.

Please try it VS Code Insiders from next Monday (23 October) and let us know if this is indeed fixed for you. Thank you 🙏