Issue metadata
Sign in to add a comment
|
Regression: Unnecessary tab focus is seen on 'Previous Menu' option in Accessibility menu at Uber Tray |
||||||||||||||||||||
Issue descriptionChrome Version: 70.0.3499.0/10902.0.0 dev channel Daisy,Kip and Reks OS: Chrome What steps will reproduce the problem? (1)Sign into User ->click on Uber Tray -> now press 'Tab' until focus is on r on 'Accessibility' text -> press 'Enter' from keyboard for Accessibility menu is seen (2)Observe unnecessary tab focus on 'Previous Menu' option (Please refer Video) Expected: Unnecessary tab focus should not be seen on 'Previous Menu' option in Accessibility menu at Uber Tray Actual: Instead unnecessary tab focus is seen on 'Previous Menu' option This is Regression Issue as New Uber Tray UI is seen from 69.0.3480.0/10862.0.0 dev-channel Reks Note: Issue is also seen for 'Previous Menu' option in Keyboard menu @tetsui : please confirm the Issue
,
Jul 27
What is the reason why this is unnecessary? Or alternatively, is it OK to just make the button not focused by tab without having a way to go back by keyboard? Currently [esc] key closes the tray window rather than coming back to the previous menu, and [backspace] key does nothing. I think this applies to all other submenus, which are Ethernet, Bluetooth, Notifications, and Input methods (keyboard). We also have a plan to change the first item focused after menu transition, but we still need to decide if this back button can be focused or not.
,
Jul 31
C#2>> In Previous builds tab focus is not seen on 'Previous Menu' option and only after pressing 'Tab' focus is seen on it. Thanks..!!
,
Jul 31
I think there are 2 things going on here. Potentially flaky behavior of tab focus, and detailed spec with tab focus show/hide. For the first thing, I still see the tab focus appears by the repro steps, with the tip of the master branch. (70.0.3508.0) This needs more input. For the second topic, what is the intended behavior of the tab focus for each of these cases? case 1. using mouse or touch only (directly click the button) case 2. using only keyboard (tab multiple times, then enter) case 3. hit [tab] key once, then clicked the button by mouse/tap what I see with current code is: 1--hide 2--show 3--show my proposal: 1--hide 2--show 3--hide The original report says it should hide focus in case of #2, IIUC. I think that is another option we can consider. However I think it'd make some sense to show the keyboard focus in the 2nd case, because the last operation was done by keyboard and user is likely continue operation by keyboard. This is up to our overall UX design decision, I think. Currently the menu shows tab focus at the first element in #3 as well, which could be considered a bug if not intended.
,
Dec 17
The proposal seems fine by me. If the sub-panel was accessed by tab, the keyboard navigation should be able to be continued by highlighting the first element in the tab cycle. Arguably, I'd say this element should be the first row of the sub-panel. |
|||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||
Comment 1 by tetsui@chromium.org
, Jul 27Owner: yamaguchi@chromium.org