New issue
Advanced search Search tips

Issue 912419 link

Starred by 1 user

Issue metadata

Status: Assigned
Owner:
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: iOS
Pri: 2
Type: Bug
Team-Accessibility



Sign in to add a comment

Voiceover for omnibox suggestions doesn't work as expected

Project Member Reported by ghendel@google.com, Dec 6

Issue description

On 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).
 
Cc: marq@chromium.org
Labels: -M-72
This is kind of expected. You're supposed to switch to Containers voiceover navigation and navigate to the popup. 

It would be really nice to have this ordered properly even without moving the cursor to another container, but this is a BVC issue that's not trivial to solve. 

Removing milestone because this is how it's been for years. 
Components: UI>Browser>Omnibox>ZeroSuggest UI>Accessibility
Cc: edchin@chromium.org
+edchin who is working on BVC refactoring. What's a reasonable target milestone for this?
Friendly ping
Cc: -edchin@chromium.org stkhapugin@chromium.org
Owner: edchin@chromium.org
To Ed for BVC. 
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. 
Components: -UI>Browser>Omnibox>ZeroSuggest UI>Browser>Omnibox
Summary: Voiceover for omnibox suggestions doesn't work as expected (was: Voiceover for zero suggest screen doesn't work as expected)
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