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

Issue 779300 link

Starred by 1 user

Issue metadata

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

Blocking:
issue 920004



Sign in to add a comment

[A11y Assessment - Voice Search] Popover iframe not indicated is present, not read

Project Member Reported by leberly@chromium.org, Oct 28 2017

Issue description

Google Chrome 64.0.3251.0 (Official Build) canary (64-bit) (cohort: 64-Bit)
Windows 10 Enterprise Version 1607 Build 14393.1770
NVDA 2017.3
JAWS 2018.1710.42 private preview release
ZoomText Private Beta -  11.7.11.410

# Open AT software, Chrome NTP
# Navigate to the Voice Search button, press space 
Expected: feature popover opens
Actual: In JAWS and ZoomText, space nor enter invokes the button. Instead, focus goes off into an unknown part of the site. 
In NVDA, space and enter both invoke the popover.
With ZoomText, the mouse click works 

# After invoking, read popover dialog indicating that it is listening, etc.
Expected: popover is announced, focused/focusable, text inside read
Actual: For NVDA and ZoomText, popover is not announced, focus is not brought there, and tabbing around reads the site under the popover as if it wasn't there. Popover goes away on its own. 

When navigating only by keyboard, the space bar doesn't invoke the button. Other than that, it doesn't let you tab to the text in the popover but otherwise works. 

 
Is it possible that this popover text is an image, and not text? I'm not sure, it's just something to look into. 

Comment 2 by treib@chromium.org, Nov 3 2017

Cc: treib@chromium.org sfiera@chromium.org
Components: UI>Browser>NewTabPage
This might be fixed already on the local NTP - at least, both space and enter work to activate voice search. Focus *should* go into the popover, but I haven't verified with NVDA or ZoomText.
Labels: zine-triaged

Comment 4 by treib@chromium.org, Nov 29 2017

Cross-ref: The focus issues are tracked in bug 779300.
Labels: win-a11y
Labels: ntp
Labels: dialogs

Comment 8 by treib@chromium.org, Jan 11 2018

Labels: ntp-starter-bug

Comment 9 by treib@chromium.org, Jan 12 2018

Looks like I linked this bug to itself in #4 above :)
Probably meant to link to  bug 706908  instead, which is closely related.
Chrome: 68.0.3418.0 (Official Build) canary (64-bit) (cohort: Clang-64)

More info:

The 'Search by voice' text is not indicated to screen reader users as actionable.
Adding role="button" to the inner-most element containing the text would make this control appear to be a <button> for screen reader users.

Chrome: 68.0.3418.0 (Official Build) canary (64-bit) (cohort: Clang-64)

More info:
The dialogues indicating "Search by voice is disabled" disappears too quickly for me to read with a screen reader.
There are links in this dialog to access more info on the error, but I cannot locate and activate them before the dialog disappears.

Cc: kristip...@chromium.org
Cc: -treib@chromium.org
Cc: adriennetran@google.com
Labels: -a11y-Dialogs
Labels: -dialogs a11y-Dialogs
Labels: --a11y-Dialogs
Labels: NTPVoice
Blocking: 920004
Labels: KR-GAR4 O-Robust-NTP
Owner: kristip...@chromium.org
Status: Assigned (was: Available)

Sign in to add a comment