Issue metadata
Sign in to add a comment
|
"Splitter" should not be read out by ChromeVox |
||||||||||||||||||||||||
Issue descriptionVersion: 56.0.2903.0 (Official Build) dev (64-bit) OS: Chrome What steps will reproduce the problem? (1) Activate ChromeVox and MD System Menu (chrome://flags#ash-md) (2) Focus the system menu (Alt+Shift+S) (3) Navigate through the audio row / tiles row (Search+Shift+<right-arrow>) What is the expected output? Splitters are not read out by ChromeVox What do you see instead? Splitters are read out by ChromeVox See also crbug.com/587725 Please use labels and text to provide additional information.
,
Nov 4 2016
1.) tab navigates you through focusable items 2) search+left/right navigates over all items including views that are not usually focusable but that provide context or additional information For 2, the question really is whether visually, the splitters are significant. If they are not, then we should remove their |GetAccessibleState| methods. From what I can tell, the splitters separate the main set of settings (e.g. network, bluetooth) from core system settings (volume, lock, etc). Note that I'm seeing splitters in other places like the network popup, bluetooth popup. It's really up to the folks re-doing the views here to make a decision.
,
Nov 4 2016
To help guide the decision and for comparison: <hr> elements are read out in HTML as "separator" or "horizontal line" on Windows. On the Mac splitters and separators are also read out when navigating using the Voiceover reading keys.
,
Nov 10 2016
The splitter in the audio row will be removed in material design. The only remaining splitters are in the user row, tiles row, and date/power row. These are not read out by ChromeVox / are not part of the focus ring, and I don't think reading them out would provide any value. Let's leave things as-is. |
|||||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||||
Comment 1 by tdander...@chromium.org
, Nov 4 2016