Issue metadata
Sign in to add a comment
|
Voiceover for omnibox suggestions doesn't work as expected |
||||||||||||||||||||||
Issue descriptionOn Chrome Canary with Voiceover enabled. From a website, tap on omnibox. Note that zero-suggest suggestions are now shown (either in a list or in tiles for experiment). Swipe right until Voiceover gets to these. Notice that Voiceover does not describe the suggestions that are actually on the screen, but describes elements of the site that the user just left. Voiceover should either describe the text in suggestions, or just skip them entirely to describe items on the keyboard (like it does when user opens the fakebox).
,
Dec 6
,
Dec 13
+edchin who is working on BVC refactoring. What's a reasonable target milestone for this?
,
Jan 2
Friendly ping
,
Jan 14
To Ed for BVC.
,
Jan 14
What does voiceover for zero suggest have to do with BVC? I'm happy to work on this when I have time, but I doubt that I'm any better fit to work on this because of my work on BVC.
,
Jan 15
The bug is not correctly named at this point, the voiceover issue is present for all omnibox suggestions, so I'm renaming this. The reason this is BVC-related is that when we display the omnibox and its suggestions, they are added as subviews of BVC. The way the a11y cursor iterates over BVC's container is not obvious: from the top toolbar, it usually goes to the web page, then to the suggestions, then back to the web page, or something crazy like this. A voiceover user can use container navigation to jump to the suggestions list. But really we would not want the voiceover cursor to access the web page at all at this point. In order to achieve this, the BVC's view has to implement custom a11y, specifically hiding the web view container from voiceover while the omnibox is displayed. |
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by stkhapugin@chromium.org
, Dec 6Labels: -M-72