-
Notifications
You must be signed in to change notification settings - Fork 4.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Constrain tabbing within popovers and similar components #5242
Labels
[Focus] Accessibility (a11y)
Changes that impact accessibility and need corresponding review (e.g. markup changes).
[Priority] High
Used to indicate top priority items that need quick attention
Milestone
Comments
afercia
added
the
[Focus] Accessibility (a11y)
Changes that impact accessibility and need corresponding review (e.g. markup changes).
label
Feb 25, 2018
See related #4621 |
karmatosed
added
the
[Priority] High
Used to indicate top priority items that need quick attention
label
Apr 13, 2018
This was referenced Apr 13, 2018
This was referenced Apr 25, 2018
Worth noting #6261 is going to introduce a |
I would also say that popovers which contain further hide/show interactions may be a bad experience and difficult to implement; as the last item in the focus order would be changed (and keybindings need to be unbound and rebound). |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
[Focus] Accessibility (a11y)
Changes that impact accessibility and need corresponding review (e.g. markup changes).
[Priority] High
Used to indicate top priority items that need quick attention
Follow up to #2306 see also #2323 that partially addressed keyboard navigation for this kind of components /cc @aduth
There's one thing left to do though: treat this kind of components like sort of "modals" and constrain tabbing with the Tab key within the component.
As mentioned in #2306
Instead, now the Popover is mounted in the DOM very far from the control that opened it, typically close to the closing body tag. That's fine but it breaks the natural tab order, for example:
This applies to various components, for example:
Inserter
Content structure
Visibility setting
Publish setting
This implementation makes using the interface with a keyboard very hard: great part of the interface gets basically "skipped", context is lost, and users are forced to start keyboard navigation from scratch or tab backwards.
In this kind of scenario, tabbing should be constrained within the component.
Gutenberg has already the tools to get all the focusable / tabbable elements, so I'd suggest to consider to implement a new tool, probably a so called Higher Order Component, to constrain tabbing within components, where necessary.
This would be a first step to make popovers and the like usable with a keyboard. As a further improvement (to be addressed in a separate issue) we should evaluate if this kind of components need to be really treated as modals, that is: hiding all the other content from assistive technologies while they're open. For inspiration, see what react-modal does.
The text was updated successfully, but these errors were encountered: