New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 827443 link

Starred by 1 user

Issue metadata

Status: Available
Owner: ----
Cc:
Components:
EstimatedDays: ----
NextAction: 2018-03-29
OS: Chrome
Pri: 3
Type: Bug
Team-Accessibility



Sign in to add a comment

ARC++ accessibility nodes get destroyed when scrolled ofscreen

Project Member Reported by dtseng@chromium.org, Mar 30 2018

Issue description

When a view is recycled, Select to Speak reading stops immediately. This is the correct behavior in non-ARC because we don't want to read nodes after the pages they are from are closed. But it's not right in ARC, where recycler views cause things to pop in and out all the time. Repro: Read some gmail overview with STS, then scroll it offscreen. Reading stop suddenly.

Possible solutions:
- STS should cache text content within a scrollable. (note the existence of AutomationNode.prototype.scrollable)
This pattern is currently only used in ARC++, but could easily be translated to web and other tree sources
- AXTreeSourceArc could retain offscreen nodes, keeping their data, but potentially not their parent links. This would be something like ref counting in the extension renderer and would likely require some additional fleshing out
 

Comment 1 by yawano@chromium.org, Mar 30 2018

Cc: f...@chromium.org
Components: UI>Accessibility>SelectToSpeak
Labels: -Pri-2 Pri-3
Note: Reading no longer stops suddenly because we have a new default behavior in STS to keep reading even if the node goes away. However, if the user scrolls back up again the node doesn't just get the same ID, so the focus ring is lost.

Marking as P3 since this no longer is as bad for users -- reading continues, focus is lost.

Sign in to add a comment