Issue metadata
Sign in to add a comment
|
Accessibility issues associated with search entry on local-ntp.html (Consider making it a normal/plain entry) |
||||||||||||||||||||||||||
Issue descriptionSteps to reproduce: 1. Launch Chromium and load chrome-search://local-ntp/local-ntp.html 2. Try to use Tab to give focus to the "Search Google or type a URL" entry 3. Click to give focus to the "Search Google or type a URL" entry 4. Begin typing a search term or URL 5. Enter full-screen mode (F11 in Linux; Cmd+Shift+F in macOS) 6. Repeat steps 2-4. Expected results: 1. One would be able to give focus to the entry by pressing Tab. 2. When one starts typing in the entry, focus would remain in the entry. 3. Typing a search would still be possible in full-screen mode. Actual results: 1. The entry does not appear to be focusable via Tab. 2. When one starts typing in the entry, focus moves to the location/address bar. 3. Typing a search does not appear to be possible in full-screen mode. You don't even get a cursor upon clicking like you do when not in full-screen mode. Comments: 1. Arguably one could instead use the keyboard to give focus to the location bar directly. But I don't think this is especially intuitive. If you click on the entry with a mouse, a cursor appears within the entry and blinks there until you start typing. In other words, it looks and acts like something which should be in the tab order. 2. That focus moves away from the widget where you are typing as soon as you begin typing is visually jarring: Your gaze has to move a non-trivial amount and refocus on the new location. For users of screen magnifiers at a high degree of magnification, the effect could be even more jarring. 3. The search functionality continues to be displayed even in full-screen mode, so it appears that it should work. That it doesn't is confusing. I'm not a UI person, but it seems to me that all of the above could be easily solved just by making the entry on local-ntp.html a normal/plain entry.
,
Nov 5
Thanks for your detailed report. This is the "fakebox fullscreen" issue, which occurs on both local and remote NTP. Merging into issue 243926.
,
Nov 7
Hi @ramyan. Apologies for not finding that issue. That said, I'm not sure the "fakebox fullscreen" issue fully covers this one. In addition to the fakebox needing to work in fullscreen: 1. It should also appear in the keyboard tab order, and 2. Entering text in it should not cause focus to jump to a different widget That it doesn't work in full screen mode is of less concern to me regarding accessibility issues. IF the fix for the "fakebox fullscreen" issue proves to be what I suggested (namely replace the "fakebox" with a real one), then my issues should also be resolved by side effect.
,
Nov 7
(1) is tracked in issue 778489. (2) is intentional. Once a user starts typing into the fakebox, focus shifts to the omnibox, where rich suggestions are presented. There has been some work to improve accessibility there (also discussed in issue 778489), with more to come. |
|||||||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||||||
Comment 1 by dtapu...@chromium.org
, Nov 5