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.