Change:
// The primary cursor is in the viewport (at least vertically) => place textarea on the cursor <del> if (platform.isMacintosh) { </del> <ins> if (platform.isMacintosh || this._accessibilitySupport === AccessibilitySupport.Enabled) { </ins> // For the popup emoji input, we will make the text area as high as the line height // We will also make the fontSize and lineHeight the correct dimensions to help with the placement of these pickers this._doRender({

Discussion:
<!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Please search existing issues to avoid creating duplicates. --<!-- Also please test using the latest insiders build to make sure your issue has not already been fixed: --<!-- Use Help Report Issue to prefill these. --- VSCode Version: Code 1.48.2 (, 2020-08-25T10:13:11.295Z) OS Version: Windows_NT x64 10.0. Steps to Reproduce: VSCode and make sure accessibility support is enabled. /create a file. The file should be on multiple lines with decent length of lines. IE . magnifier, and ensure that it is set to follow the text cursor. 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. <!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes
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 . Alternative would be that we are just putting a subset of the whole text in the but that can be controlled via setting and changing that did not help. I am also open to ideas. might you have some idea, I know you tackled similar issue in the past.
It looks like we have a regression from , I'm not sure what has changed.
I can look into all the changes and do some bisection.
Just investigated a bit more and actually nothing changed.

It seems like the original issue was not fixed when in settings. If accessibilitySupport is disabled then all works perfectly both then and now. I have verified that the issue is . If we return then all works fine (and that is the case when accessibilitySupport is turned off). I see the method is only used 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 , however I can reproduce this problem even if I increased the setting so that we would write the whole editor content. Since this is not a regression moving to September for now.
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?
no worries. Good ideas. I will investigate further in debt week.
I have investigated a bit more into this and this is happening because as Alex suspected the cursor overflows out of the hidden content. Windows Magnifier follows the cursor that is outside of the 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 api to force the to reveal a cursor outside of the viewport. 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:
Any news on this ? I reported this as well last year.
unfortunately no news, the Windows Magnifier team did not yet respond to my email. I will ping them again.
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.
I suggest to use the workaround for now In the meantime, set in your vscode settings. I just emailed AI Squared and Freedom Scientific, however let's also check with 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.
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. you said in " 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. I would appreciate your help and input.
we have plans to fix this issue, and as we get more details I will comment here. Thank you.
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.
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.
Thanks
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
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 . User that hit this issue can you please verify if the issue is indeed fixed for you. You can tryout vscode 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! 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 .
The inside the is currently . If we would set it on all OSes I think that would help with the need to define
Thanks! Created a follow up issue
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.
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: 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...
Hi is there any update on work for this issue? I asked 2 years ago, and this issue is even older than this ticket. :(
no updates. I agree we should do another investigation here. I will try for us to get it on the plan again. Thank you
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