Version: 1.43.0-insider
Commit: 8d17dc1
Date: 2020-02-10T10:04:08.445Z
Electron: 7.1.11
Chrome: 78.0.3904.130
Node.js: 12.8.1
V8: 7.8.279.23-electron.0
OS: Linux x64 5.5.2-arch1-1

Maybe I'm doing something wrong, but I couldn't find in the file explorer a simple way to identify the name of the folder being displayed.
I can navigate the files with the arrows, expand, colapse and open folders without problems.

To identify the name of the displayed folder I use an orca feature called flat review mode. It works, but it is not in my opinion very natural.

and there are some slowdowns like when closing editors. but note that both of that could be chromium related and it is even possible they are already fixed. I do not usually experience such things in actual google chrome, but it is version 80 (stable) or 81 (unstable).

I just tried our Orca on Linux with VS Code (with the flag --force-renderer-accessibility) and I have some questions for you:

1. When you focus on the Editor is the text nicely being read out when you navigate left, right, up? It is not being read out for me, only when I do some editing the edited characters get read out. Do I have to setup Orca specially or what am I missing here?
2. Is it possible to configure Orca that it just display what it reads and that it does not read it out? This is just easier for me, since I use NVDA and VoiceOver like that
3. Reading in other parts of the UX outside the Editor seems to work fine

We always try to update the use the later chromium and electron version. However Electron usually has some issues that are blockers so it takes quite some time before we test, fix and make sure an Electron version is working fine. Thus we do want to use Electron 8 and 9, but that will happen in one of the following milestones.

As for the name of the explorer: you can focus on the title area of the explorer via Shift + tab to read that out. Or you could Ctrl + R to browse through recent workspaces, just press up and the current one should be read out.

For the slowdownes: if you also see this in previous Chrome versions than that is probbly the same issue and should be fixed once we adopt to later Electron.

Hmm if you enable accessibility in editor settings it should work fine provided you are on electron 7. on 6 it has some issues because it didn't read when pressing up/down arrows.
But you have to enable it explicitly in addition to adding the --force-renderer-accessibility flag.
Things work fine except that sometimes it seems to join adjacent lines when reading by up/down arrows. not quite sure how it is possible and what it is about, try editing xml files.

I have accessibility enabled via vscode setting, i am on electron 7, and I have passed the --force-renderer-accessibility when launching vscode from the command line.
Looking at the docs here https://wiki.gnome.org/Projects/Orca/Chromium
I seem to be missing having ACCESSIBILITY_ENABLED=1 in my environment.
Trying it out...

oh sorry, forgot about that detail. :) yes, it needs to be orca master. not necessarily latest commit, but definitely would be the best.

@ndarilek @webczat ok thanks. I was just trying the orca that I have as part of my Ubuntu 18.04.
Let me search for how to get latest orca. If you have some pointers let me know :)

first issue confirmed here.

Issue with alt+# not working is not confirmed for me, although the change of editor is not announced.

1. Do you also see that behvior with a simple Chrome textArea, in this example site for instance? https://developer.mozilla.org/en-US/docs/Web/HTML/Element/textarea If yes that means it is a Chrome bug and I can file it against the Chromium repository
2. I personally always use Ctrl + E to navigate between editors. Since after that command I can type to filter editors or go up / down to go through the open ones. Not sure if that works for you. Alt-# navigation I am not aware of, is that something which is Orca specific?
3. I am having issue setting up Orca with latest from master since I am not a Linux user primarily. If there are steps for this let me know.

note that the bug, even if it is chrome specific, could disappear already. none of us is using chromium 78.x, and that is the one underlying electron 7.

@webczat we can easily double check that if you try to open that site https://developer.mozilla.org/en-US/docs/Web/HTML/Element/textarea with different Chrome versions and check how the <textarea> is read out between versions. Or if I succesfully setup latest Orca :)

@ndarilek it works fine on Windows and NVDA. However I use the shortcut Ctrl-1, Cltr-2 there. Once the Editor gets focus NVDA properly reads out the content.

I just tried our Orca on Linux with VS Code (with the flag --force-renderer-accessibility) and I have some questions for you:

1. When you focus on the Editor is the text nicely being read out when you navigate left, right, up? 

It is not being read out for me, only when I do some editing the edited characters get read out. Do I have to setup Orca specially or what am I missing here?
Yes, I have no dificulties to access the editor.
Probably you're using aa wrong version of orca. I don't use ubuntu so I don't know how to get the most current version of orca for this distro. I can however ask on the orca list if anyone has any tips on how to do it.
If I'm not mistaken you are using Ubuntu 18.04 version, are you?>

2. Is it possible to configure Orca that it just display what it reads and that it does not read it out? This is just easier for me, since I use NVDA and VoiceOver like that

Orca has a series of options that can be configured with, for example, verbosity, punctuation, speed and much more. These settings are on the orca preferences screen which can be accessed by pressing the orca key together with the space bar.
3. Reading in other parts of the UX outside the Editor seems to work fine

We always try to update the use the later chromium and electron version. However Electron usually has some issues that are blockers so it takes quite some time before we test, fix and make sure an Electron version is working fine. Thus we do want to use Electron 8 and 9, but that will happen in one of the following milestones.

As for the name of the explorer: you can focus on the title area of the explorer via Shift + tab to read that out. Or you could Ctrl + R to browse through recent workspaces, just press up and the current one should be read out.

For the slowdownes: if you also see this in previous Chrome versions than that is probbly the same issue and should be fixed once we adopt to later Electron.

1. Do you also see that behvior with a simple Chrome textArea, in this example site for instance? https://developer.mozilla.org/en-US/docs/Web/HTML/Element/textarea  If yes that means it is a Chrome bug and I can file it against the Chromium repository

Using version 82.0.4055.0 of chromium I have not found any problems on this site.>

2. I personally always use `Ctrl + E` to navigate between editors. Since after that command I can type to filter editors or go up / down to go through the open ones. Not sure if that works for you. Alt-# navigation I am not aware of, is that something which is Orca specific?

I can use ctrl + e to select the editor, but it seems that it does not display only active editors, I need to understand it better. I can also use alt + 1, alt + 2 and etc., but orca does not announce the name of the editor in focus when I use these keys.

@jvesouza yes I am on Ubunutu 18.04.
I have issues triggering the Orca preferences menu since it requires the Orca modifier key + space. Since I am using a Linux VM on my Mac the Orca modifier key is either Ctrl or Insert + space. However whatever I press the preferences are not triggered. And to change this modifier key I have to open the preferences. My questions is: is there any other way to open the preferences?

Ctrl + E shows the whole editor history, not only the open editors.
I do not know why orca would not announce when using alt + 1, alt + 2. I can investigate further, though that does not seem like something that is under our control (since we properly set the ariaLabel on the item that gets focus). So I think this is an Orca issue.
Another alternative to achieve this is: F1 > focus on open editors view than navigate through the via via up / down and press Enter to open the editor you are interested in.

Great thanks. I can also join the Orca mailing list if you think that makes sense.

hello @ndarilek. you can use Ctrl with up or down arrow to read lines.

also @isidorn. is force-renderer -accessibility is needed in current insiders? i want to ditch my code wrapper.

@alex19EP no, it is not needed. Latest insiders is from Monday and I did the change on Friday, so should be good.
If for some reason it does not work please let me know. Thanks!

Updated the docs to mention terminal navigation mode (ctrl+up/down) microsoft/vscode-docs@3c0e8d4

@jvesouza the screen reader's feature to read by word or character should work when using the navigation mode.

@ndarilek this is very good feedback for the SCM viewlet. And I 100% agree, to track this I have created #90893 feel free to comment there if I did not cover the issue nicely.
@Tyriar thanks for updating the docs.

@jvesouza 1) sounds expected
2) Yeah when focus is moved to the file explroer for the first time we first focus the overall tree. Once you have acutally set the focus in the tree to something every other focus in the explorer will move there. If you find this annoying and counter intuitive please file a new issue :)

generally the rule is that what was selected in the tree should be selected/announced when I return to it. othervise I don't know where I am, and have to press down/up arrow for example to reread. and imagine if there is only one item in the whole tree...

Well the focus should always be preserved when you return to the file explroer. We only focus the whole tree if nothing was focused before.
If that is not the case we would need a new issue with reproducable steps..

it may be it is indeed preserved, but that screenreader does not get enough info to know what is the focus in tree. it is quite common bug in my experience :)

@webczat when I try it on the Mac with VoiceOver it works just fine. I believe we are doing the correct thing with ActiveDescendent inside the tree. It might be an Orca issue.

Since this turned into a chat room, if you have feedback on word navigation feel free to chime in here #90578

hello @isidorn. unfortunately --force-renderer-accessibility still required. i installed current insider build (595f984)

and added in settings.jsong

"editor.accessibilitySupport": "on"

wen i launch code-insiders from the terminal i get nothing.

@alex19EP good catch. I was doing something stupid and was only writting it on setting change. So can you please try it out tomorrow and let me know if it works for you then. Thanks a lot!
Already it should work if you just toggle on and off your editor.accessibilitySupport setting. Though please try it out tomorrow.

The experience should be the following:
You have no editor.accessibilitySupport, you set it, VS Code asks you to reload and everythig just works.
You already have editor.accessibilitySupport. VS Code will nicely update chrome renderer on next startup, but will not prompt you to restart (which you should do). So I might polish this case.

@alex19EP good catch. I was doing something stupid and was only writting it on setting change. So can you please try it out tomorrow and let me know if it works for you then. Thanks a lot!
Already it should work if you just toggle on and off your editor.accessibilitySupport setting. Though please try it out tomorrow.

yay. now it works like a charm! thanks @isidorn

i tested all cases.

@alex19EP awesome, thanks a lot for trying it out.

Next week we plan to do some testing in our team of Orca screen reader with VS Code. For reference here's the test plan item #91063

Also I tried sending some email to the Orca mailing list, not sure if you recieved them or they are still waiting for administration?

@isidorn I did not receive any email from you on the orca list.
It may be worth sending an email to Joan Marie Diggs diggs@igalia.com because if I am not mistaken, she is the administrator of the list.

on the other hand I am surprised that the list requires admin approval...

Ok, I will send her an email. Thank you

What Linux version are you all using?
For us all seems to work nicely on Ubuntu 18.04, but on Ubuntu 19.10 does not seem to work...

same here. archlinux seems quite popular among us. It definitely has newer packages than even ubuntu 19.10 and things work here.