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.

[isidorn]

Yes we have changed the scm input box to use the editor and not the native input box.
Are you all on Linux? If yes then the issue is that Electron does not detect that you have a screen reader attached.
If you set "editor.accessibilitySupport": "on", then the SCM and Debug Console still do not work? If yes than that seems to be the actual issue which we can fix?
I am missing something here, I am trying to get the gist of your discussion.

Also can you introduce yourselfs, I see you are filling accessibility issues starting from this week @ndarilek @webczat @jvesouza

Here's about me: My name is Isidor Nikolic I am a developer working on VS Code for 8 years, I work on debug, explorer, ux, accessibility. I primarly use Mac, but also use Win and LInux. Cheers

[webczat]

yes, setting accessibility to on explicitly does not make it work. only actual code editors work.

[ndarilek]

Same here. Code editor works great, better than I expected it would, in fact. Single-line editors, and now the SCM commit message editor (which I assume is *not* single-line) don't work even with accessibility enabled. Lots of us are filing Linux-specific accessibility issues because the Chrome team is finally working on Linux accessibility, and those changes are finally trickling down to Electron. Unfortunately I don't think we'll have screen reader detection quite yet, hence the need to enable accessibility manually. But Alt-F1 definitely doesn't do anything for me, and even so, I'm not sure if it'd do anything above and beyond what I already have. To be clear, how many accessible editing widgets are there? The code editor, and whatever is used for most single-line inputs? It's interesting to me that one would work and another would completely fail. Thanks.

[isidorn]

Well I do not know how Orca works and what is specific about it.
On Win and Mac the small code editor (scm commit, debug console, extensions view) are accessible and work fine.

Can you be more precise how the scm commit box is not accessible? Is nothing read out? Or you get the "Press alt + F1.." message?
Also if you provide steps on how to attach Orca and how to enable VS Code accessibility I can try it on my Ubuntu 18.04.

@joaomoreno @alexdima here's the gist: simple code editor widgets like the scm box, debug console input are not accessibile on linux. Regular Editor works. Is there something special about them that would make the Orca code editor not be able to read content.

[webczat]

I get the message about alt+f1. :)

[isidorn]

Ok, so let's take the debug console for example. If you get the alt+f1 message that means that the simple editor widget thinks that the accessibility support is disabled, which you gave explicitly enabled.
I am trying to setup linux and screen reading so I can investigate more.

The issue seems to be that the AccessibilityService always returns disabled even if I explicitly set "editor.accessibilitySupport": "on"

@sbatten shouldn't the accessibilitySupport setting take precendence here?

What I am seeing is the following
The proper options with accessibilitySupport turnedOn are passed here
However the accessibilityService gets created and completley ignores that option and reads it from the environmentService here and the enviornmentService has it wrong.

Looks like a serious issue and it would be great if we fix this. Assigning to January.
@sbatten if you do not have time can you please provide some details so I try to fix this tomorrow. Thanks

[sbatten]

@isidorn I remember when making the accessibility service since it was really made to aggregate some of the logic spread around (and give a home to the reg key reading on windows), that some references used the configuration service to override and some did not and I kept it that way to avoid breaking someone. This meant that the function represented whether a not a screen reader was running and if the browser was giving us that flag.

The references that do override the screen reader value with the configuration settings value do so like this:

vscode/src/vs/workbench/contrib/search/browser/searchView.ts

Lines 416 to 418 in 5a1b063

	const detected = this.accessibilityService.getAccessibilitySupport() === AccessibilitySupport.Enabled;
	const config = this.configurationService.getValue<IEditorOptions>('editor').accessibilitySupport;
	return config === 'on' || (config === 'auto' && detected);

[jvesouza]

I tried to access the fiddle https://jsfiddle.net/ab0u5sxr/ using chromium and firefox and got the following:

• The focus was moved to an edit field.
• I typed some text and after that I tried to use the arrows to navigate the typed text. Nothing was announced by the orca when I moved the arrows.
• I pressed the tab key but the focus remained on the same field.

I asked Joanmarie Diggs, who keeps the orca, to get tested to see if she would find any problems.
She reported the following:

So when I arrow around or change text in the editor, the only accessibility events I'm seeing are children-changed events, sections adding sections. And they don't seem to be live regions. Thus Orca is expecting caret-moved events and the like, but failing to get them. Not sure why....

By the way, there is an orca mailing list:
orca-list@gnome.org
https://mail.gnome.org/mailman/listinfo/orca-list

[jvesouza]

Here's about me: My name is José Vilmar
My name is José vilmar, I live in Brazil, I have been blind since I was born and I write computer programs since 1976.

I currently develop in java using linux as the basic OS and also started to develop using the dotnet core.

The IDE I use on linux is eclipse but in my opinion the accessibility of eclipse on linux is declining. Besides, I didn't find a good support for dotnet core in eclipse.

[isidorn]

@sbatten ok thanks for the explanation. I plan to update the accessiblityService that it always contains the true and than everybody should just use it. Everything else can cause errors and issues like this one imho. Hope that makes sense.

@jvesouza nice to meet you. We found the issue, I will try to fix it and will keep you posted on the state here.

[ndarilek]

Amazing! Thanks. Been having a great time using VSCode this past week. Has a few minor issues under Orca, but certainly nothing near the level I expected when I got started.

[webczat]

yeah, the accessibility level is surprising, even more so when considering it was never officially supported on linux. All or at least most other issues are annoyances.

[isidorn]

I have pushed the fix to the Simple editor widgets via 66d2137

So the git commit box the debug console input and all the small editors should be accessibile.
You can try it out in vscode insiders from Monday.
Also feel free to file any other issues / annoyances that you encounter and feel free to ping me @isidorn on the issues. Thanks a lot!

[ndarilek]

Cool, thanks! I'd rather not lose access to the commit message box, and don't really want to re-downgrade. When are insiders builds usually made? And will Monday's be between Sunday-Monday or Monday-Tuesday? Thanks again.

[jvesouza]

I will try to generate VSCode this weekend to test the fix. As soon as I can test it, if I can, I'll post the results on that ticket. I would like to thank you for your efforts in solving this problem. It is very good when the developers of a tool put in efforts to make it accessible.

…

On 1/24/20 2:27 PM, Isidor Nikolic wrote: I have pushed the fix to the Simple editor widgets via 66d2137 <66d2137> So the git commit box the debug console input and all the small editors should be accessibile. You can try it out in vscode insiders from Monday. Also feel free to file any other issues / annoyances that you encounter and feel free to ping me @isidorn <https://github.com/isidorn> on the issues. Thanks a lot! — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#88893?email_source=notifications&email_token=AAPRNEW3FIPBFOPJKR247ILQ7MQIZA5CNFSM4KIRVXA2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEJ3QBBI#issuecomment-578224261>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAPRNEULTTXL3WW7P5N5FCTQ7MQIZANCNFSM4KIRVXAQ>.

[jvesouza]

Monitoring the VSCode repository I found the following commit:

commit 5d49873
Author: Benjamin Pasero benjpas@microsoft.com
Date: Fri Jan 24 23:39:40 2020 +0100
revert back to electron 6 (#89245)

I'm not quite sure, but I believe that this would bring accessibility problems for those using Linux, wouldn't it?

[ndarilek]

Yup, good catch. Sticking with my January 10 build after all.

[isidorn]

This is unfortunate timing. Since my collegue @bpasero reverted the Electron version before we do our stable release since we still have some regressions with it.
Due to that I have triggered a custom build which has Electron 7 and has my fix for the scm, debug console and all the input boxes. Here are the builds

• Linux x64 https://az764295.vo.msecnd.net/insider/0fd5117d0655a76178414266dd74edfeeb550c0d/code-insider-1580120500.tar.gz
• Deb https://az764295.vo.msecnd.net/insider/0fd5117d0655a76178414266dd74edfeeb550c0d/code-insiders_1.42.0-1580120238_amd64.deb
• Rpm https://az764295.vo.msecnd.net/insider/0fd5117d0655a76178414266dd74edfeeb550c0d/code-insiders-1.42.0-1580120376.el7.x86_64.rpm
• Snap https://az764295.vo.msecnd.net/insider/0fd5117d0655a76178414266dd74edfeeb550c0d/code-insider-1580120943.snap

Insiders will again have Electron 7 in 10 days and then you can use it again.

Also feel free to create other issues on GitHub and feel free to ping me @isidorn
We care about accessibility and we want to make the experience as smooth as possible.

Thank you

[webczat]

hmmm does not seem to work here. can anyone confirm?

[webczat]

sorry, now it does. not quite sure what was the problem.

[isidorn]

@webczat thanks for trying it out. Adding verified label.
Soon the VS Code insiders will have electron 7 and than it shuold just nicely work on VS Code insiders. This should happen in a couple of days.