[Inserter]: Keyboard navigation in inserter panels when panel content overflows.

[ntsekouras]

In a different PR that moves the search input of the main inserter inside each tab panel content there were comments about a11y issues for navigating through the inserter. You can read more on this thread.

After trying to figure out what the problem is, it seems there is an existing issue on trunk, that was just made more visible through my PR. After the changes made in this PR in order to implement the new design for the patterns tab:

we also need to move the "scrollable area" of the inserter to be the "tab content" instead of being the whole inserter.

we can't enter in the blocks tab panel by pressing Tab. Noting that for me at least this doesn't happen in all browsers.
In the below video I'm pressing Tab until the tab button (Blocks) is focused and the next Tab focuses the scrollable area and not the first block in the list. When the scrollable area is focused, you can press the arrow keys to scroll the tab panel content. In the same video in Patterns tab, we can enter the tab panels contents, because it doesn't overflow.

Screen.Recording.2022-11-02.at.3.54.42.PM.mov

In this video I have reduced the number in blocks tab and increased the number of patterns panel content to demonstrate the same effect in the different tabs.

Screen.Recording.2022-11-02.at.3.57.26.PM.mov

From my understanding until now, this is how it should work(ex article), that means if the content overflows focus the scrollable container. I'm not sure what is the best practice for the navigation in this issue and what to do.

Sorry for not being able to describe the issue very well, but there are lots of unknowns to me.. Please ask anything to try to clarify.

1. Is this behavior correct or we need to change things for a11y? If yes, how we can then enter the block types list(tabpanel content in general) if it's overflowing?
2. Can we achieve the wanted design (patterns explorer button at the bottom of patterns tab content) without the scrollable area change?

--cc @alexstine @youknowriad @ciampo

[ciampo]

Thank you for posting this issue!

If I understand correctly, when the contents of a tab cause the tab to overflow, we make the scrollable element focusable for accessibility reasons.

My question, then is: when the scrollable region is focused, what happens when pressing tab again? My expectation is that the next tabbable element inside the tab receives focus, but I assume this is not the case

In this video I have reduced the number in blocks tab and increased the number of patterns panel content to demonstrate the same effect in the different tabs.

Just flagging that I am not able to watch the second video

[ntsekouras]

we make the scrollable element focusable for accessibility reasons.

I didn't see any custom handling from us and I think this is just the browser handling - thus why I can't reproduce in chrome for example..

My question, then is: when the scrollable region is focused, what happens when pressing tab again? My expectation is that the next tabbable element inside the tab receives focus, but I assume this is not the case

Yes, that what I'd expect and that's part of my first question in the PR's description.

Just flagging that I am not able to watch the second video

I re-uploaded it.. Although it's the same with the first one with the difference that the overflow happens in different tabs, so no big deal.

[alexstine]

The inserter should support a roving tabindex pattern so that way focus cannot exit the inserter sidebar. It is the sidebar itself that needs to manage the focus, not the specific rendered components. Not sure what the bug is now, but I trust @ntsekouras has found it.

Thanks.