Issue metadata
Sign in to add a comment
|
[A11y Assessment - NTP] Focus issues with accessing the search box |
||||||||||||||||||||||||||
Issue descriptionChrome Version: 56.0.2924.87 OS: Mac What steps will reproduce the problem? (1) Press Ctrl T to open a NTP (2) Press tab to try to access the search field in the middle of the page It's a really confusing experience if you try to use just the keyboard to get to the search bar in the page. If you press tab to go through the focusable items on the page, you skip the search box and go straight to the mic icon. This is a weird instance, since I know the search box is fake and when you put your mouse in it, it puts your focus in the omnibox instead. But for keyboard users, it makes it seem like this simply isn't keyboard focusable (which it's not). Placing keyboard focus there should do the same thing that placing mouse focus there does - take you to the omnibox.
,
Feb 26 2017
,
Feb 27 2017
,
Feb 27 2017
FWIW, this is not a Mac-only bug, and it's going to be non-trivial. This has been a source of frustration for years, ever since the 1993 launch. Happy to re-open this longstanding bug but we should probably figure out who's the current owner of the NTP and try to figure out the path forward.
,
Feb 28 2017
Looking at this in-product, I wonder why we are skipping the fakebox in the tab order. If you click on the fakebox, focus is *not* immediately put on the omnibox. Instead, the fakebox gets focus and a blinking caret. Only once you start typing focus is transferred to the omnibox. I think we should do the same as part of the tab order: Once tabbing takes you to the fakebox, the fakebox gets the usual blue highlight and blinking caret. Marc, is this something you can take on? We should send this as a proposal to UI review to make sure we are not missing implications from the previous discussions Dominic referred to.
,
Feb 28 2017
The fakebox is weird. As the name implies, it's not actually a text box; it's just designed to look like one. We do explicitly set its tabIndex="-1" and aria-hidden="true", but I couldn't find any justification for that. I can explore changing it, but as this has been around since the original 1993 launch, I expect it won't be easy to change.
,
Feb 28 2017
As this has been around since ~forever, I challenge that it's actually a P1. My proposal would be to fix this after the remote NTP is gone (see go/ntp-refactor).
,
Mar 7 2017
,
Mar 27 2017
,
Apr 21 2017
,
Nov 16 2017
cross-reference: crbug.com/778489
,
Nov 27 2017
,
Jan 17 2018
|
|||||||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||||||
Comment 1 by lpalmaro@chromium.org
, Feb 26 2017