Issue metadata
Sign in to add a comment
|
Accessibility tree doesn't reflect re-ordering of apps in shelf or tabs: view_model bug |
||||||||||||||||||||||
Issue descriptionGoogle Chrome 67.0.3383.0 (Official Build) dev (64-bit) Google_Lulu.6301.136.57 Chrome OS with flag enabled: #enable-experimental-accessibility-features # Enable STS # Invoke the feature using search key + drag the mouse around the shelf (aka taskbar) # Note the order the apps are read # Move the app ordering around, for example, move the Chrome icon to the second to last item in the list Expected: STS still reads from left to right Actual: STS retains the original ordering, reading Launcher, then Chrome, then back to Gmail
,
Apr 10 2018
STS should be using ordering from the Automation tree, so it should match switch access and chromevox. I tried this with Switch Access as well and saw that the order is also switched there. So the underlying a11y tree is not being updated when items on the shelf are re-ordered.
,
Apr 10 2018
,
Apr 11 2018
The backing view is likely not sending an event (and thus updated tree data), when you reorder using the mouse. Katie, want to take this one on? I can help you find the offending native view if you need.
,
Apr 12 2018
Google Chrome 67.0.3383.0 (Official Build) dev (64-bit) Firmware Version Google_Samus.6300.276.0 Chrome OS with flag enabled: #enable-experimental-accessibility-features This is also affecting apps that have been closed previously but STS and ChromeVox still treat them as there. Video 1 STS will read closed programs all together with the last program in the shelf. See that I close calculator and text and the last program is called "Calculator Settings Text". After I close the last program, Settings, it goes back to reading the icons as expected. https://drive.google.com/file/d/1anKKVjBOvYw4cTi4XVL_yVXXMi6uV2Nf/view Video 2 STS with the same bug behavior only the last icons in the shelf are all clo sed. STS shows a highlight where Text and Calculator used to be https://drive.google.com/file/d/10ZZyzcJlc_OJAFnMxKbajg153qZ6qoRp/view ChromeVox does the same.
,
Apr 12 2018
Digging deeper, this seems to be related to using view_model::Move. The same thing happens when tabs are re-ordered, and they also use view_model.
,
Apr 16 2018
Tried a fix in https://chromium-review.googlesource.com/c/chromium/src/+/1011592 but after discussion with dmazzoni it might not be the right direction. May want to instead have the a11y tree be able to sort by x,y order of children or similar. Setting back to 'available'.
,
Apr 16 2018
As a datapoint, other platforms do this in the opposite way: - by default, they sort left-to-right, top-to-bottom - given an explicit attribute set on a container, accessibility will use the tree ordering *for* that container's children.
,
Jul 18
|
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by leberly@chromium.org
, Apr 10 2018