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

Closed
afercia opened this Issue Feb 25, 2018 · 3 comments

Comments

Projects
None yet
4 participants
@afercia
Contributor

afercia commented Feb 25, 2018

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

Ideally, the Popover component should be placed in the source immediately after the controls that opens it. This way, it would be in the natural tab order and pressing tab would move focus to the Popover.

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:

  • using only the keyboard, use the Tab key to navigate to the Gutenberg top bar
  • tab to the Inserter toggle (the "Add block" button) and press Enter
  • the Inserter opens, focus is correctly moved to the Inserter
  • tab through the Inserter
  • in a few tab key presses, you'll be outside of the Inserter and focus will be at the end of the document

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.

@afercia

This comment has been minimized.

Contributor

afercia commented Mar 1, 2018

See related #4621

@afercia

This comment has been minimized.

Contributor

afercia commented May 2, 2018

Worth noting #6261 is going to introduce a withFocusContain HoC. Still to verify if it can be reused on components like the Popover and the like.

@anevins12

This comment has been minimized.

Contributor

anevins12 commented May 2, 2018

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