[A11y Assessment - Omnibox] Permission dialog cannot be reached with keyboard navigation after it loses focus |
||||||||||||||||||||||
Issue descriptionChrome Version: 56.0.2924.87 OS: Mac What steps will reproduce the problem? (1) Mac > Preferences > Keyboard > Shortcuts > Full keyboard access > All controls ON (2) Go to http://permission.site and click Notification to open a permissions popover (3) Click on the page to move the focus out of the popover (4) Cmd+L to focus Omnibox and tab or shift-tab What is the expected result? Keyboard access to the permission popover What happens instead? Keyboard access unavailable
,
Mar 7 2017
,
Mar 8 2017
,
Mar 16 2017
Same issue on the added platforms What steps will reproduce the problem? (1) Go to http://permission.site and click Notification to open a permissions popover (2) Click on the page to move the focus out of the popover (3) F6 or Search+6 to focus Omnibox and shift-tab or tab to try to access to the popover
,
Mar 27 2017
,
Mar 27 2017
,
Apr 21 2017
,
Aug 1 2017
tapted, I think you are working on this for MacViews? this is the Cocoa dialog.
,
Aug 2 2017
I'm working on improving the initial announcement - Issue 748221 . But haven't looked at this, and don't know the right fix. It's a separate window so Tab/Shift+Tab doesn't seem to me like it should jump into another window (a11y experts?). The dialogs take focus, so you need an unusual repro to get into the "keyboard-inaccessible" state. That is, I don't think we should focus on clicking being required to enter a state that requires more clicking to be accessible again. But, you can enter the inaccessible state with Cmd+` on Mac. That cycles windows, and the permissions dialog isn't in the window cycle list. That should be easy to fix. We could also allow the dialog to be refocussed if a website requests it again (and the dialog is still showing). However, maybe that can be abused. Mac also has Ctrl+F6 "Move focus to the floating window", but I don't know how that's supposed to work, or if a11y users make use of it normally.
,
Dec 14 2017
,
Dec 15 2017
,
Dec 15 2017
,
Dec 15 2017
,
Dec 20 2017
,
Feb 16 2018
David added support for Alt+Shift+A to focus a popover Need to maybe add F6 support Make sure this announces when it opens
,
Feb 16 2018
,
Mar 16 2018
Peter is working on adding F6 support for bubbles, maybe reassign to him?
,
Mar 16 2018
Not actively working on it anymore (got assigned to material design refresh work which takes >=100% of my time), I added F6 support for location-bar icons as a quick-and-dirty fix to make the state of the world a little bit better. See issue 764918 which I think should be the master bug for a unified strategy fixing all of them. If you want an off-by-one fix for this perhaps LocationBarView::ActivateFirstInactiveBubbleForAccessibility could be extended so that it can reach this dialog. Assigning back to previous owner as I'll be swamped with the MD refresh work.
,
Apr 11 2018
The issue described is not solved by the alt+shift+a or f6 fixes. the only way to refocus the unfocused popover is to click into it.
,
Apr 11 2018
,
Apr 11 2018
Right, this is because the f6/alt+shift+a solutions only find bubbles if they are part of the location bar bubble icons, there's no GetAllBubblesFor(window_) equivalent which would probably be the right thing to do.
,
Aug 1
,
Sep 18
,
Sep 18
,
Sep 18
|
||||||||||||||||||||||
►
Sign in to add a comment |
||||||||||||||||||||||
Comment 1 by tapted@chromium.org
, Mar 2 2017Status: Available (was: Untriaged)