Orca fails to reliably speak the settings tree

[ajborka]

@isidorn: In Linux, when Orca is in focus mode, it doesn't reliably speak the settings tree when navigating with the arrow keys. This causes problems because the user has no reference point when navigating the tree. I am thinking that the selection is moving the focus, but the focus itself isn't reported to Orca.

• VSCode Version: 1.44 (Insider's)
• OS Version: Ubuntu 20.04, Orca master (3.37.1 pre).

Steps to Reproduce:

1. Start Orca screen reader.
2. Start vscode with accessibility mode turned on.
3. Press ctrl+, (comma) for the settings window.
4. Press e to navigate to the settings search.
5. Press TAB twice to navigate to the settings tree. Note: This is the only way to access the settings tree with Orca. Everything else fails.
6. Press arrows to navigate the settings tree.

Actual results: In most cases, Orca remains silent. However, Orca will announce the tree items, but only after revisiting a tree node. Expected results: Orca should reliably speak each tree item when in focus mode.

[vscodebot[bot]]

(Experimental duplicate detection) Thanks for submitting this issue. Please also check if it is already covered by an existing one, like:

• Orca not reading languages list (#92324)
• Provide screen reader users a keyboard shortcut to jump between settings tree and settings panel (#92487)
• Test: VS Code with Orca screen reader (#91063)
• In some situations, the orca is muted when the focus is moved to the file explorer (#91884)
• Simple editor widgets not accessible on Linux (debug console, scm, extensions input) (#88893)

[isidorn]

@ajborka this is basicaly a duplicate of this issue https://github.com/microsoft/vscode/issues/57372 The settings tree is designed to be navigated only by tab which I think is wrong and I think a user should be able to navigate it via arrow keys. Forwarding this to @roblourens since he owns the settings tree and he said he might reconsider the navigation design if users complain. And now you are complaing which is great :)

@roblourens this makes the settings tree very unfriendly to accessiblity users and almost unusable. Thus adding important label. Hope that is ok.

If we do not want to change the settings UI design an alternative is to always use the JSON editor when we detect a screen reader is attached.

[ajborka]

@isidorn, See #92485 for an explanation on why the json editor isn't a wise choice as a default, especially for new users.

[joanmarie]

@isidorn I can reproduce what @ajborka says regarding Orca being silent the first time a tree node is navigated to. Will investigate that aspect.

[ajborka]

@isidorn , @joanmarie I investigated more on this. When going into focus mode with Orca, and the settings tree has focus, pressing down arrow changes focus or (selection?). However, when using flat review (numpad keys), the focus or selection does not change.

1. Turn on Orca.
2. Start vscode.
3. Press ctrl+, (comma).
4. Press TAB twice to enter the settings tree.
5. Press numpad+5. Orca speaks 'commonly used'.
6. Press down arrow a few times.
7. Repeat step 5.

Actual result: Orca still speaks 'commonly used.'. Expected results: Orca tracks the focus change.

Even though this might be an Orca problem, I am putting it here in case vscode might contribute to the problem.

[joanmarie]

@isidorn. Ok, I can reproduce the problem without Orca, but using an accessibility event listener.

Steps to reproduce in Linux:

1. Run the attached listener in a terminal (after removing the ".txt" extension; github complained about ".py").
2. Launch VSCode (relaunch it if it is already running)
3. Arrow Down several times in the Settings tree

Expected results: The listener would print out state-changed events for items in the tree. Actual results: The listener does not print out any state-changed events in the tree.

4. Arrow Back up in the Settings tree

Now there are events. And if you arrow back down there are events. This is why Orca initially isn't presenting anything.

state-changed.py.txt

[joanmarie]

@ajborka Does the flat review problem only occur when Orca is not presenting the items as you arrow? If so, then that's the same issue as in your opening report and what I just stated above.

[ajborka]

@joanmarie flat review remains on the commonly used node even when Orca speaks the tree items. The problem seems to be inconsistent. When arrowing up and down the tree, some items that were announced may not get announced a second time, but do a third. This is not a problem for JAWS and NVDA though.

[joanmarie]

@ajborka Ok, I was just able to reproduce the flat review issue after Orca did present a tree item. That's very likely an Orca bug. Will see about fixing that.

The missing events (i.e. Orca not initially presenting items when you navigate down) is a bug in either VSCode or Chromium.

[joanmarie]

@ajborka So this is going to be a good-news/bad-news thing. The good news is that the flat review issue is now fixed in Orca master. The bad news is that the fix means Orca needs to rebuild the flat review context when you switch between focus mode and flat review. In the particular case of VSCode, which has a zillion accessible objects, that's not a very performant task for Orca to perform.

So.... I will see if there's a way to make the context-rebuilding more performant for very objectful web apps. In the meantime, it's a known issue.

[isidorn]

@joanmarie @ajborka thanks for looking into this!

If I understand the full issue correctly the problem in VS Code is the following: up / down keyboard navigation does not correctly traverse the Settings tree. That can be fixed in VS Code and is the cause of the issue on our end. Up / down should go through each element and not go into the values of settings. This issue is unrelated to screen readers, focus movement is simply wrong. Am I missing something here or am I oversimplifiying?

[ajborka]

@isidorn , @joanmarie To summarize: the settings tree which contains categories such as commonly used, editor, workbench, application, etc is not properly read by Orca in Linux. Based on @joanmarie 's testing, the tree isn't sending out focus change events when first navigated so screen readers can properly read the focus change. Settings pane itself has its own issues that we discussed in another report.

[isidorn]

@ajborka thanks for the summery. However that tree is just like all other trees in vscode (it is using a same tree implementation). It nicely sets the activedescendent based on the focused element. So not sure what would be special about it.

[ajborka]

@isidorn : as @joanmarie said in an earlier post, vscode is not firing some events when keyboard navigation is performed. Try running her sample code. She can reproduce the problem without a screen reader running.

[joanmarie]

@isidorn I've attached a modified pyatspi accessibility-event listener which you can use without Orca and which potentially sheds some more light on where the problem might be: vscode-tree-issues.py.txt

Here's what I did using the listener:

1. Preparation (we want VSCode to not have trees of interest showing until we interact with them) a. Close settings b. Click on the Search button in on the left c. Quit VSCode
2. Launch the attached accessibility listener (again, nuke the ".txt" from the file name)
3. Press Ctrl+Shift+E to cause the Explorer to be visible. Note what the event listener prints out.
4. Press Ctrl+comma to cause Settings to be visible.
5. Arrow down in the tree. Note what the event listener prints out.
6. Arrow up in the tree. Note what the event listener prints out.

My output from performing these steps is below. But what I find interesting is that as soon as the explorer is showing, the tree gets populated (see the object:children-changed:add events). But this doesn't happen when the settings tree is initially shown. In fact, there are no events from the settings tree descendants until you start arrowing down in the settings tree. And when you do that, children get removed/destroyed; not added. It's not until you start up arrowing that children get added.)

So.... I get that the tree is just like all the others. But is there something else which you're doing for the explorer tree which causes their accessibility objects to be immediately created? Alternatively, are you doing something to the settings tree which would cause container to destroy its children?

# This happens when the explorer is initially shown with Ctrl+Shift+E
[section | ] object:children-changed:add [tree item | test]
[section | ] object:children-changed:add [tree item | orca-scalable.svg]
[section | ] object:children-changed:add [tree item | po]
[section | ] object:children-changed:add [tree item | .gitignore]
[section | ] object:children-changed:add [tree item | ChangeLog]
[section | ] object:children-changed:add [tree item | acinclude.m4]
[section | ] object:children-changed:add [tree item | AUTHORS]
[section | ] object:children-changed:add [tree item | orca-symbolic.svg]
[section | ] object:children-changed:add [tree item | orca-splash.svg]
[section | ] object:children-changed:add [tree item | configure.ac]
[section | ] object:children-changed:add [tree item | ChangeLog-pre-2.27.1]
[section | ] object:children-changed:add [tree item | src]
[section | ] object:children-changed:add [tree item | orca-256x256.png]
[section | ] object:children-changed:add [tree item | m4]
[section | ] object:children-changed:add [tree item | .cvsignore]
[section | ] object:children-changed:add [tree item | autogen.sh]
[section | ] object:children-changed:add [tree item | orca-24x24.png]
[section | ] object:children-changed:add [tree item | help]
[section | ] object:children-changed:add [tree item | AUTHORS]
[section | ] object:children-changed:add [tree item | orca-16x16.png]
[section | ] object:children-changed:add [tree item | Makefile.am]
[section | ] object:children-changed:add [tree item | icons]
[section | ] object:children-changed:add [tree item | orca-32x32.png]
[section | ] object:children-changed:add [tree item | orca-48x48.png]
[section | ] object:children-changed:add [tree item | orca-22x22.png]
[section | ] object:children-changed:add [tree item | COPYING]
[section | ] object:children-changed:add [tree item | docs]

# This happens when I Tab to give part of the tree focused and then arrow
[tree item | docs] object:state-changed:focused True
[tree item | docs] object:state-changed:focused False
[tree item | help] object:state-changed:focused True
[tree item | help] object:state-changed:focused False
[tree item | icons] object:state-changed:focused True
[tree item | icons] object:state-changed:focused False
[tree item | AUTHORS] object:state-changed:focused True

# When I press Ctrl+comma to open settings causing the settings tree
# to be shown, the listener prints nothing.

# Each time I arrow down in the settings tree, children get removed.
# One press of Down (e.g. from "Text Editor" to "Workbench" in the tree)
[section | ] object:children-changed:remove [DEAD]
[section | ] object:children-changed:remove [DEAD]
[section | ] object:children-changed:remove [DEAD]
[section | ] object:children-changed:remove [DEAD]
[section | ] object:children-changed:remove [DEAD]
[section | ] object:children-changed:remove [DEAD]

# Another press of Down (e.g. from "Workbench" to "Window" in the tree)
[section | ] object:children-changed:remove [DEAD]
[section | ] object:children-changed:remove [DEAD]
[section | ] object:children-changed:remove [DEAD]
[section | ] object:children-changed:remove [DEAD]
[section | ] object:children-changed:remove [DEAD]
[section | ] object:children-changed:remove [DEAD]

# One press of Up:
# Don't worry about the events from text. That's a known issue and irrelevant to this problem.
# What is interesting is NOW we get the children being added.
[text | Window] object:children-changed:remove [DEAD]
[text | Features] object:children-changed:remove [DEAD]
[section | ] object:children-changed:remove [DEAD]
[section | ] object:children-changed:add [tree item | window.autoDetectColorScheme Auto Detect Color Scheme Auto Detect Color Scheme. If set, automatically switch to the preferred color theme based on the OS appearance.]
[tree item | Window, group] object:state-changed:selected True
[tree item | Window, group] object:state-changed:focused True
[section | ] object:children-changed:add [tree item | window.enableMenuBarMnemonics Enable Menu Bar Mnemonics Enable Menu Bar Mnemonics. Controls whether the main menus can be opened via Alt-key shortcuts. Disabling mnemonics allows to bind these Alt-key shortcuts to editor commands instead.]
[section | ] object:children-changed:add [tree item | window.menuBarVisibility Menu Bar Visibility Control the visibility of the menu bar. A setting of 'toggle' means that the menu bar is hidden and a single press of the Alt key will show it. By default, the menu bar will be visible, unless the window is full screen. Menu Bar Visibility. ]
[section | ] object:children-changed:add [tree item | window.closeWhenEmpty Close When Empty Close When Empty. Controls whether closing the last editor should also close the window. This setting only applies for windows that do not show folders.]
[section | ] object:children-changed:add [tree item | Window]
[section | ] object:children-changed:add [tree item | window.doubleClickIconToClose Double Click Icon To Close Double Click Icon To Close. If enabled, double clicking the application icon in the title bar will close the window and the window cannot be dragged by the icon. This setting only has an effect when Window: Title Bar Style is set to custom.]
[section | ] object:children-changed:add [tree item | window.customMenuBarAltFocus Custom Menu Bar Alt Focus Custom Menu Bar Alt Focus. Controls whether the menu bar will be focused by pressing the Alt-key. This setting has no effect on toggling the menu bar with the Alt-key.]

[isidorn]

@joanmarie thanks a lot for this testing. I wrote the Explorer tree, however I did not write the Settings tree. For that @roblourens would be best to answer if we are doing something special there. If he is busy I can also investigate deeper, but for now let's wait for Rob to reply.

@joanmarie can you please clarify are you navigating the actual settings or the settings tree of content on the left?

[joanmarie]

@joanmarie can you please clarify are you navigating the actual settings or the settings tree of content on the left?

The settings tree on the left where it says "Text Editor", "Workbench", "Window", "Features", .... That is the thing that Orca is failing to present when the user initially down arrows.

I appologise if you are visualy impaired and if these gifs are not very helpful

I am sighted. But the fast movement of the second is literally making me motion sick. Assuming we're on the same page, perhaps delete that image?

I also just edited the listener output to make where I was arrowing more clear (I hope!).

[roblourens]

I replaced the inline gif with a link.

Yeah, I don't do anything weird with that list as far as I know. I don't implement getActiveDescendantId but it looks like that should be ok right @isidorn? And the attribute on the list element is still set properly. Also this works with VoiceOver on mac.

Maybe all the changes in the tree on the right that happen when it scrolls are interfering somehow?

I am trying to run your script, but it doesn't print anything out. Are you using python3? Can you tell me how you installed pyatspi?

[roblourens]

Oh, my Ubuntu VM is not GNOME. That is probably an issue

[roblourens]

Hm I still don't get any output, do you think there are some other prereqs I have to install? I had to modify the script to get rid of errors, changed the top part to

import gi
gi.require_version('Atspi', '2.0')
from gi.repository import Atspi
import pyatspi

I am not a python person, I'm not sure what that's doing.

[isidorn]

@joanmarie appologies for the gifs, I have removed them. @roblourens you do not need to implement getActiveDescendantId that is only if you have a sub-element that gets focus (like the explorer for multiple compacted folders in one element). Tree will handle the activeDescendent setting automatically. And yes I also see all the attributes properly set on the Table of Contents tree.

My main suspect is the overall structure of the Settings UX page. And what @roblourens suggest: when I change the Table of Contents a lot of elemnts are changing in the other tree. Note when I inspect the monaco-list-rows for the content of the actual settings it takes the whole page real estate (coverring the Table of Contents section). So they seem to be somewhat overlapping, could this potentialy confuse Orca?

I suggest the following: 1) Remove the second Tree which shows the settings, and only render the Table of content tree 2) Check if the issue still reproduces

Once we know that it will be easier to investigate in the right direction. Let me know what you think. Thanks!

[ajborka]

@roblourens that Python code tries to import the GTK+ user interface library. It has nothing to do with atspi in this context. It technically should be something like:

gi.require_version('Gtk', '3.0')

@isidorn there is a possibility that the settings design is interfering with Orca since it is the only tree in the entire application that fails to work as expected. It would be worth getting a build of vscode with only the settings tree displayed on the settings screen so I can test the theory. Thinking about the difference between the file explorer tree and the settings tree, this is what I came up with:

1. The settings tree dynamically loads UI elements as you arrow through the tree contents, the files list doesn't change UI elements.
2. Since you are using an older version of electron, is it possible the chromium implementation is not yet accessible under linux?

It is worth trying to rebuild the UI screen a component at a time to see where the tree breaks, and possibly upgrade electron to 8 or 9 to see if it fixes the problem.

[isidorn]

@ajborka makes sense. For a build without a settings tree, I suggest that @roblourens just makes to changes and runs VS Code out of source and tries it out. We could try a newer version of electron, however I could not find an exploration build of electron 8 or 9 for Linux. @deepak1556 do we have that somehwere? Not sure if this will solve the issue, but does not hurt to try it out.

[ajborka]

@isidorn Electron is cross-platform. There are no linux builds. Here is the github repo for electron's releases. They are already up to 10.x prerelease, but I recommend 8.1.1 since it is a stable build, although it might not hurt to try a prerelease of 10.x since it should have chromium 82 in it.

[isidorn]

@ajborka sorry, I meant our VS Code built that is on top of electron. We have an internal page for these. And @deepak1556 manages our electron adoption. I am aware Electron is cross platform :)

[joanmarie]

Hm I still don't get any output, do you think there are some other prereqs I have to install? I had to modify the script to get rid of errors, changed the top part to

import gi
gi.require_version('Atspi', '2.0')
from gi.repository import Atspi
import pyatspi

I am not a python person, I'm not sure what that's doing.

That suggests you have a fairly old version of AT-SPI2. That said, in this particular case, it shouldn't change anything.

If you don't get any output at all it suggests that accessibility support is not enabled for VSCode.

[joanmarie]

@roblourens that Python code tries to import the GTK+ user interface library. It has nothing to do with atspi in this context. It technically should be something like:

gi.require_version('Gtk', '3.0')

I'm not sure what you mean @ajborka. But to be clear, my python listeners are not trying to import Gtk+. Nor are @roblourens's changes. What his changes to the listener do is work around an issue in pyatspi which was fixed four years ago: https://gitlab.gnome.org/GNOME/pyatspi2/-/commit/5cf4dc4.

[joanmarie]

So they seem to be somewhat overlapping, could this potentialy confuse Orca?

@isidorn I don't think so.... Especially not in the case of this particular bug.

Again, the functional bug is "Orca doesn't present the Settings tree items when you down arrow. You have to up arrow back to them."

The reason Orca fails to present the Settings tree items when you initially down arrow amongst them is that Orca doesn't get any state-changed events (like focused or selected). That's not a case of Orca getting confused; that's a case of Orca failing to be informed. And the lack of events can be seen in my listener.

Orca does start presenting items when you arrow back up and then down in the same tree. It does so because at that point it is getting focused/selected events from the tree items.

HTH and thanks again for all your work on this!

[isidorn]

@joanmarie ok, thanks for clarifying. From all of the above it smells like a Chromium issue. We should verify if we can reproduce with new VS Code electron builds. Also we should try to distill this into a chromium issue.

[joanmarie]

@joanmarie ok, thanks for clarifying. From all of the above it smells like a Chromium issue. We should verify if we can reproduce with new VS Code electron builds. Also we should try to distill this into a chromium issue.

Cool. I'm afraid I'm not an author / web app developer. Any chance you could make a stand alone tree that exhibits the problem or would that be a lot of work?

[roblourens]

@joanmarie can you tell me how you installed pyatspi? Sorry I am not a python person

I can try to produce a stripped down build to confirm the issue, but it will be easier if I can figure out how to repro the issue. As a quick check, if you are comfortable using the Developer Tools on vscode, you could try deleting the settings list and check whether the issue still happens.

• Help > Toggle Developer Tools
• Elements pane
• Open the settings UI
• Find the element .settings-tree-container, under that element, delete .monaco-list
• Try to reproduce the issue

Don't worry about it if you aren't able to get those steps to work

[ajborka]

@isidorn , @joanmarie , @roblourens Give me until later tonight and I will try to reproduce with the vscode developer tools. I am a web developer so am familiar with the DOM. Will get back with you later this afternoon.

[joanmarie]

@roblourens I use a current version of Fedora and the GNOME desktop, so I didn't have to install pyatspi; it was automatically installed. What version of Ubuntu are you running?

That said, if you have made the errors go away as you described (gi.require_version...), then what you have installed is presumably good enough for the purposes of reproducing the lack of events.

In addition to enabling accessibility support explicitly within VS Code, you might need to set ACCESSIBILITY_ENABLED=1 in the environment from which you launch VS Code.

I just tried deleting .monaco-list and it didn't make a difference.

@ajborka I'm afraid that the developer tools are emitting tons of events which lead to at-spi2 timeouts and Orca becomes unresponsive until the spam is over with. I'll see if I can make that better on the Orca side. In the meantime, sorry!!

[ajborka]

Setting ACCESSIBILITY_ENABLED=1 is required to make Chrome 82.0.4068 and higher work with accessibility features in linux. After testing this by commenting out the variable in my .profile file, there is no difference in how the settings tree works. It still doesn't speak the first time you arrow to a settings group. However, @joanmarie and @roblourens , navigating the tree works as expected when browse mode in Orca is turned on. The notable exception to this rule is that you can't tell what is expanded/collapsed, nor can you get the item count of that group in the list. For example: editor collapsed, 1 of 15. I am still curious if Chromium 80/Electron 8.1.1 will help with this problem.

[joanmarie]

@ajborka when browse mode is enabled, Orca isn't waiting for events; instead it's drilling down the accessibility tree looking for items to present. That drilling down might be sufficient to cause accessibility items to be created for the treeitems. As for identifying expanded/collapsed, let me look into that. Thanks!

[ajborka]

@joanmarie also be aware that you have to press ENTER on the tree items to collapse/expand them. Also, have you found a reliable way to navigate the settings pane with Orca? It seems quite difficult.

[joanmarie]

@ajborka So Orca master will now present the expanded/collapsed state and tree level for the tree items in settings in browse mode. If you have speak child position enabled, Orca says "0 of 0". This is because that is what is exposed to us for posinset and setsize. Not sure yet if that's a Chromium bug or a VSCode bug.

As for expanding and collapsing those items, Enter doesn't work for me. I'm using Left/Right.

As for navigating the settings pane (if you mean between the treeitem, like "workbench", and then all the settings related to "workbench") I thought somewhere you or someone else filed a bug asking for a keyboard shortcut to navigate between those two things. Such a shortcut sounds nice to me. I may have some other ideas, but this bug here should be about fixing the issue(s) causing Orca to not present the settings tree items (imho).

[ajborka]

@joanmarie I will take a look at the Orca fixes a little later. When I made mention of navigating the list of settings, it is also a tree, but it looks like a different implementation. It happens that Orca can't navigate those as well. I am wondering if it suffers from the same problem as the TOC (as vscode calls the settings tree). @isidorn , is the settings list also a tree like the settings TOC? If so, Orca might have problems with it as well. @joanmarie , can you navigate the actual list of settings while in browse mode, with the arrow keys (please don't tab through) because it works as expected there. If there is a problem, maybe we should open another bug report for the settings list while we work on this one.

[roblourens]

This is Ubuntu 16.04. After messing with it for quite awhile, I haven't been able to get rid of errors or get any correct output. Also tried setting ACCESSIBILITY_ENABLED. I have a Fedora VM but I'm just getting the same result, are you sure you didn't have to install anything from somewhere to get pyatspi?

The settings list is also a tree, but it is different since rows of the tree can't be highlighted, just controls inside the rows. It should be set up so that setting names and descriptions will be read by the screen reader when a control is focused.

[roblourens]

Actually it seems to be loading pyatspi ok in Fedora, realized I wasn't using python 3. But it's not giving me any output.

If I start Orca, it reads stuff in Firefox and the terminal, but doesn't read anything from vscode.

[isidorn]

@roblourens please check this thread out for troubleshooting / setting up Orca with vscode https://github.com/microsoft/vscode/issues/91063

[deepak1556]

@isidorn I haven't kicked electron-8 exploration in a while, just updated to electron 8.1.1 and have triggered a new exploration build https://monacotools.visualstudio.com/Monaco/_build/results?buildId=69877&view=results . Should be available soon.

[ajborka]

@isidorn , @roblourens , @deepak1556 when will the electron 8.1.1 build be available to the general public to test?

[isidorn]

@deepak1556 has released latest electron-8 exploration vscode builds. Tried this issue a bit on my Ubuntu and here are my findings: 1) It is not fixed with Eletron 8 2) If I manualy remove the settings tree from the DOM the issue is no longer reproducable. Thus our suspicion is correct that having two trees in the DOM somehow confuses Chrome / Orca.

[isidorn]

In case people want to try electron 8 VS Code for themselves here are the download links

• https://az764295.vo.msecnd.net/exploration/7344a09a727e850b912d81f99b5fd98d2d61af95/code-exploration-1584528271.tar.gz
• https://az764295.vo.msecnd.net/exploration/7344a09a727e850b912d81f99b5fd98d2d61af95/code-exploration_1.44.0-1584527948_amd64.deb
• https://az764295.vo.msecnd.net/exploration/7344a09a727e850b912d81f99b5fd98d2d61af95/code-exploration-1.44.0-1584528095.el7.x86_64.rpm
• https://az764295.vo.msecnd.net/exploration/7344a09a727e850b912d81f99b5fd98d2d61af95/code-exploration-1584528575.snap

[ajborka]

@isidorn I don't want to rule out Electron 8.1.1 entirely. Orca's performance in the exploration build is amazing. It is definitely better than code-insiders build with Electron 7.1. The first improvement deals with the settings TOC. #90161 might be partially fixed if we use it. There are other areas to explore with Orca in the exploration build though. At the moment, the exploration build fixes the problem where screen readers aren't provided an item count on the tree nodes. What else do you want me to check out with the exploration build in relation to the insiders build?

[isidorn]

@ajborka great to hear that Orca performance is better with newer version of Chrome. I think you got the issue number wrong, #90161 seems unrelated to our discussion. If you find issues that are fixed with explroation build just ping me on those issues, then we add a label "fixed-with-electron-8" and once we adopt that electron we just close all those issues. That's our process.

Here's a list of accessibility issues which are marked as upstream. Though please note that a lot of those are on Windows and Mac. Though some items from that list might be interesting to check https://github.com/microsoft/vscode/issues?q=is%3Aopen+is%3Aissue+label%3Aaccessibility+label%3Aupstream

[joanmarie]

2. If I manualy remove the settings tree from the DOM the issue is no longer reproducable. Thus our suspicion is correct that having two trees in the DOM somehow confuses Chrome / Orca.

I guess then file a bug against Chromium. Again, what my dead-simple pyatspi listener does is listen for events and spit them out. That shows the problem exists independent of Orca.

[roblourens]

I haven't forgotten about this issue - I spent a while this morning trying to get this to work in a couple different Linux vms in Parallels and had a variety of issues. After trying to update one of them it ended up totally broken, so my current status is setting up a fresh one so I can start over form scratch. So basically, the same thing that happens every time I spend a lot of time debugging Linux issues 😆😭

And my understanding is that something about the way the two trees on the settings page are arranged is interfering with the left one's accessibility events, so I should figure out why and probably find a different way to arrange them.

[roblourens]

And on a totally new VM, espeak just crashes when orca starts.