Use contentEditable for our hidden accessibility textArea

[isidorn]

Investigate into using contenteditable instead of a plain textArea for our hidden accessibility field.
It migh have performance implications, but it would allow us to have richer accessibility content on each line. Including line number, breakpoints etc..

[LeonarddeR]

cc @bramd @zersiax

Note that line number support will probably conflict with the ability of the screen reader to provide line numbers itself. NVDA is able to do this. In Visual Studio, this is also an issue.

[zersiax]

While that is true, I would say line numbers can be toggled, so I don't necessarily see that as an obstacle for this. If this allows for breakpoint, error and line number indication, I'd say go for at least giving it a test run. The performance implications are one to keep an eye on, though.

[derekriemer]

NVDA's line number reading is not going to work in vscode, because vscode can only page n lines at a time to the hidden textarea used for accessibility.

[isidorn]

Unfortunetly I did not have time to look into this this milestone. In july I am on vacation, thus pushing this out to August.

[MarcoZehe]

@isidorn since you brought this up in another issue, did you have time at all yet to look into this?

[isidorn]

@MarcoZehe yeah I found some time, however I hit some bigger issues with this approach. I believe none of them are unsolvable but they showed that this is a bigger effort. So we would use a HTMLDivElement instead of an HTMLTextArea, here are the issues I could not figure out:

• How to get selection indexes of the HTMLDivElement. It does not have the selectionStart and selectionEnd like the textArea
• I could not figure out how to set programatically setSelectionRange on an HTMLDivElement
• Not sure if composition events would work nicely since I noticed that they do not work as expected on google docs. Composition we use when user is inputing Korean for example, or when holding the a to get the ä.

If somebody has ideas how to tackle these let me know. Especially the first two with selection.

[MarcoZehe]

Does the contentEditable attribute not handle these automatically?

[isidorn]

@MarcoZehe contentEditable indeed allows for the selection to be changed by the user and it will be automatically updated. However for us the contentEditable is not the truth it is hidden away beneath our editor.
So when the user changes the selection in our Editor we need to update the selection in the hidden contentEditable. And that is the reason why we have to manipulate the selection programatically.
Keep in mind that the selection in our editor is not a "real" HTML selection.

Hopefully I explained this correctly, let me know if not and I can try again :)

[yume-chan]

For contentEditable elements, the Selection API (https://developer.mozilla.org/en-US/docs/Web/API/Selection) can be used to retrieve and manipulate selection programmatically.

It is more difficult to use than textarea, because Selection API manages selections on the whole page. Any element without user-select: none can be selected by user and the selection will be returned by Selection API. It may not be a problem in Code, but definitely need attention when Monaco is hosted in users' page.

[isidorn]

@yume-chan that's a good idea, and if I am not mistaken I also tried with that, however I found that API to be much less powerful. Selection.addRange was a bit clunky to use with our model. Another problem was if the editor does not have focus and something is selected in another part of vcscode the underlying editor contentEditable selection should still work - and I am not sure that is the case.
However I should just try it out again and report here, instead of trying to remember what I did.

[LeonarddeR]

However for us the contentEditable is not the truth it is hidden away beneath our editor.

Probably a not too smart question, but what is holding you back from implementing something accessible in the true editor?

[isidorn]

@LeonarddeR it's a good question. Because our true editor is a bunch of html divs, spans and what not. It is not only text, as there can be inline decorations and other details. it is not a textArea or an input field and screen readers do not really work well with our editor HTML structure. Also the cursor is not the real cursor, the selection is not the real html selection and so on.

I believe @alexdima the author of the editor considered this and he can probably explain in more detail if needed.