Orca fails to reliably speak the settings tree #92488
Comments
|
(Experimental duplicate detection)
|
|
@ajborka this is basicaly a duplicate of this issue #57372 @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. |
isidorn
added
accessibility
|
@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.
Actual result: Orca still speaks 'commonly used.'. Even though this might be an Orca problem, I am putting it here in case vscode might contribute to the problem. |
|
@isidorn. Ok, I can reproduce the problem without Orca, but using an accessibility event listener. Steps to reproduce in Linux:
Expected results: The listener would print out state-changed events for items in the tree.
Now there are events. And if you arrow back down there are events. This is why Orca initially isn't presenting anything. |
|
@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. |
|
@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. |
|
@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. |
|
@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. |
|
@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? |
|
@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. |
|
@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 |
|
@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. |
|
@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:
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? |
|
@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. @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 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!). |
|
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 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 |
|
Oh, my Ubuntu VM is not GNOME. That is probably an issue |
|
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 pyatspiI am not a python person, I'm not sure what that's doing. |
|
@joanmarie appologies for the gifs, I have removed them. 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. I suggest the following:
Once we know that it will be easier to investigate in the right direction.
|
|
@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:
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. |
|
@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. |
|
@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. |
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. |
|
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. |
|
And on a totally new VM, espeak just crashes when orca starts.
|
|
@roblourens did you figure out your espeak problem? What linux distro are you trying to use? |
|
Ok I actually got it to work and can reproduce the issue. Here are some things I know
So what else is different? When the selection changes in the TOC, it scrolls the settings editor. I will try disabling that. |
|
Ok, so if I disable the action that the TOC takes when a row is focused, then this actually works. That might be one workaround - in accessibility mode, we can require the user to press enter to select a TOC row. Would that be acceptable? But I'd like to fix the issue. Trying to reduce to a Chromium bug. It works fine in Firefox. The workaround doesn't actually fix it in Chromium but there are other issues there with the web UI too, like it doesn't read the search tree or the explorer at all. @isidorn do you know if there are issues there or is there something else I have to do to set it up? I did have to check these two checkboxes to get it to read anything:
|
|
<!--
/* Font Definitions */
@font-face
{font-family:Wingdings;
panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
.MsoChpDefault
{mso-style-type:export-only;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
/* List Definitions */
@list l0
{mso-list-id:821850961;
mso-list-template-ids:-1;}
@list l0:level1
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l0:level2
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:1.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:"Courier New";
mso-bidi-font-family:"Times New Roman";}
@list l0:level3
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:1.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l0:level4
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:2.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l0:level5
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:2.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l0:level6
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:3.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l0:level7
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:3.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l0:level8
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:4.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l0:level9
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:4.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
ol
{margin-bottom:0in;}
ul
{margin-bottom:0in;}
-->Put a panel on the settings page along with the settings TOC. Wire the focus/selection change event of the settings TOC row to make the settings panel visible with the correct settings. Another problem screen reader users have is the inability to determine what settings are connected with each TOC row. For example, a screen reader user has no way to determine when they are finished with the commonly used settings group because the settings tree keeps scrolling until it reaches the end of the tree. This synchronized scrolling between trees also makes it difficult to understand your placement in the settings. For instance, the commonly used group takes about 2-3 visible screens. Unfortunately, the only way screen reader users have to scroll the settings contents is to constantly press TAB, losing their ability to understand their placement in the settings. We also mistakenly think that the first visible page of settings for each TOC group is the only settings available for that particular group. If you need a new bug report for the synchronized scrolling problem with the trees, let me know and someone can make a new bug for it.
|
|
It sounds like other contributing issues are that the settings list is virtualized, but the actual rows don't get focused so you can't interact with it like other trees in vscode. Maybe it could work in a different mode like that when a screen reader is in use. Will have to think about it. Not a straightforward change. Could you open a new issue? |
|
@roblourens it seems like you are also hitting this issue #94404 |
|
Oh that would be it, thanks @isidorn. |
|
I think that this should be fixed now, between the accessibility changes this summer to make this work like a normal list, and electron updates. Please let me know if that's not the case. |
|
@roblourens , @isidorn the settings tree works as expected. FYI, the new implementation is represented as two treeviews: one for the settings TOC, and another for the settings. |
|
Yeah, I think that is expected. |
@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.
Steps to Reproduce:
Note: This is the only way to access the settings tree with Orca. Everything else fails.
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.
The text was updated successfully, but these errors were encountered: