Simple editor widgets not accessible on Linux (debug console, scm, extensions input)

[jvesouza]

I am testing the accessibility of vscode in linux using the orca screen reader and the following version of VSCode:

Version: 1.42.0-insider
Commit: fd13e449f5f2fe300f187129d6065ed1cfad74d3
Date: 2020-01-17T16:32:04.733Z
Electron: 7.1.7
Chrome: 78.0.3904.130
Node.js: 12.8.1
V8: 7.8.279.23-electron.0
OS: Linux x64 5.4.12-arch1-1

In some situations when I need to edit some text, I get the following message:

The editor is not accessible at this time. Press Alt+F1 for options

Despite this message it is possible to type although it is not possible to use the arrows to review what was typed.

Steps to reproduce:

• Make sure that at least orca version 3.34.1 is running.
• Launch VSCode using the flag --force-renderer-accessibility
• When VSCode is active, press ctrl + alt + x to activate the extenssions view.

Result:
As soon as the key sequence is pressed, the focus is moved to a text field and the message mentioned above is read by the orca.

• Type for exemple the word java

Result:
Orca announces the number of extensions found.

• use the left arrow and the right arrow to review what was typed.
  Result:
  Orca is silent.

Additional information:
This problem does not happen when I access the command palette using ctrl + shift + p

[webczat]

clarification: this problem does not happen on code editors and similar. It happens only on things such as these, even though accessibility is turned on explicitly.

[isidorn]

@webczat can you reproduce the issue if you explicitly set "editor.accessibilitySupport": "on" in your settings?
Also please note this issue #19522
We have unfortunetly never supported screen readers on Linux and that issue has all the details

[webczat]

confirmed. this is actually the case, as vscode fails to detect a screenreader (for obvious reasons as even chromium doesn't yet activate accessibility on linux by default). So if I want to do anything interesting I in fact have to set this setting to on. And the single line editors like search are not accessible, but code editing works well. The versions of vscode that support this are these that have electron 7.1.x, and we are all using insider builds, so this is up to date info. I should comment on the linked issue, btw

[jvesouza]

In the file ~/.config/Code\ -\ Insiders/User/settings.json I have the following content:

{
    "editor.accessibilitySupport": "on",
    "workbench.startupEditor": "newUntitledFile",
    "workbench.commandPalette.history": 48,
    "editor.suggestSelection": "first",
    "vsintellicode.modify.editor.suggestSelection": "automaticallyOverrodeDefaultValue"
}

When the focus is on the field where the message is announced by the orca I can type text without problems. The problem is that I can't use the arrows to revise the text, which makes it partly difficult to use.

The interesting thing is that this does not happen for example in search, ctrl + shift + f, quick picker ctrl + shift + p / ctrl + p and etc.

[isidorn]

The reason for that is that ctrl + p, ctrl + shift + F use an input box, not a textArea which the editor uses.
So it seems like you are hitting a chromium issue that the textArea with LInux screen readers hits issues.

For example can you reproduce the same issues just using chrome and this fiddle? https://jsfiddle.net/ab0u5sxr/

[webczat]

well, the text areas report themselves as being inaccessible, except code editor, so not sure if this is really a chrome bug. Anyway I myself don't yet use accessible chrome here and can't test.

[jvesouza]

Please excuse my ignorance, but what kind of field ctrl + shift + x uses? I ask because one of the points where the problem appears is when I press this key combination.
The editor seems to work perfectly when I am editing a file.

When I tried to test using chromium and the fiddle suggested, I got no feedback from orca.
The problem is that the behavior was the same when I tried to use firefox.
I'm probably doing something wrong.

[isidorn]

ctrl + shift + x opens the extensions view input which uses our Editor. Which deep down uses the native TextArea for accessibility.

[ndarilek]

Hitting this as well. Was the source control commit message editor recently changed in an insiders build? Worked well last week but failed after an update. Kind of annoying since things like search failing to provide accessibility are one thing, but I'd like to spell/grammar-check commit messages and now can't. :(

Thanks.

[webczat]

also hit that in the debug console/repl :) that is also quite critical as you'd rather want to be able to read your expressions before pressing enter. And yes, commit messages worked for me before, so if they would be broken after an update it would be a regression. Unless you lost the accessibility setting. Are you sure normal code editor still works, or it regressed?

[ndarilek]

Normal code editor works nicely still. I'm trying to get code-insider-1578639570.tar.gz which I think worked.

[ndarilek]

Found the 2020-01-10 build in a backup. There indeed seems to have been a regression in the git commit editor's accessibility since then. Or, at least, it was reclassified into whatever widget class seems to be used for what I assume are single-line, in accessible fields.

The code editor still works nicely. I'll stick with this older version for now, and hope the commit editor change doesn't make it into a release.