Issue metadata
Sign in to add a comment
|
STS and ChromeVox read buttons under menu in multiple native apps and on the web |
||||||||||||||||||||||
Issue descriptionGoogle Chrome 67.0.3383.0 (Official Build) dev (64-bit) Google_Samus.6300.276.0 Chrome OS with flag enabled: #enable-experimental-accessibility-features # Enable STS # Launch Text application # Open sidebar with hamburger menu # Select Settings button at the bottom # Use search key + mouse to drag focus around the list Expected: only those buttons read Actual: Buttons from underneath the settings list are read first, then the settings buttons are read. This happens with both STS and ChromeVox. Please see this video for the repro: https://drive.google.com/file/d/1O2w83cngKM8l-EKq0jl00ymi29L5uq3F/view
,
Apr 12 2018
Hi Laura, what is the Text application? What is the Camera application? If these are from the web store, could you please link to where you got them? Or are these ARC++ apps?
,
Apr 12 2018
I found a "text" app on the chrome webstore that matches what you've got in the video. It looks like they implemented the sidebar by simply placing one menu on top of the other, using a background color to hide the items in the background. We kind of need something in Blink / automation that tells us if a view is 100% obscured in order to solve this.
,
Apr 12 2018
Issue 831961 has been merged into this issue.
,
Apr 12 2018
Issue 831896 has been merged into this issue.
,
Apr 13 2018
The Text and Calculator applications shipped with my Samus and Lulu Chromebooks, nothing added from the webstore nor ARC++. I found an area that appears to be similar on the surface but does NOT show the same behavior. CrOS environment is the same as that listed above # Enable STS # Open Files, right click a file, select Get Info Note that an overlay appears. STS reads the contents of the overlay as expected. Here's a video showing the correct behavior: https://drive.google.com/file/d/14YD2PPgXnhIgM1Di338F-BLTR2Ddgw8c/view
,
Apr 16 2018
,
Apr 16 2018
Web example: photos.google.com sidebar menu Possible solution: Add a function to do a hit test over a rect, and get a percent visible as response. Then we can have a heuristic to read nodes that are greater than some % visible. (There may be a fuzzy hit test that can be used as an example.) Hit testing is async but may be the best option available.
,
Jul 2
Issue 833042 has been merged into this issue.
,
Sep 27
|
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by leberly@chromium.org
, Apr 12 2018