Remove extraneous elements placed between Tabs and Tab panels

[afercia]

Description

Splitting this out from #58942

Recent work improved the consistency of various tabbed interfaces in the editor by using the Tabs component. That's a very welcomed improvement.

However, in a few places the Tabs component is used incorrectly. The whole purpose of a tabbed interface is to allow keyboard users to save tab key presses and be able to tab directly from a selected tab to its associated tab panel.

Image courtesy of Heydon Pickering, from his accessible components, to visually illustrate the expected keyboard interaction:

Placing extraneous focusable elements between the tabs and the tab panels defeats the purpose of a tabbed interface.

There's a few places in the editor where a 'Close' button is placed in the between and adds an unexpected tab stop between the tabs and the tab panels. For example, in all the Settings panels:

And #58942 would reproduce the same problem in the List View panel.

There's two requirements to follow:

• There must be no focusable or otherwise interactive elements between Tabs and Tab panels.
• The visual order must match the DOM order.

As such, the only solution to this is to remove the Close button from that spot and place it somewhere else.

It would be great to have the Tabs component to enforce this via code: no extraneous element can be placed between Tabs and Tab panels.

Step-by-step reproduction instructions

• Go to the Post editor > Settings panel.
• Use a keyboard.
• Tab to the first tab.
• Use the right or left arrow keys to select a tab.
• Optionally activaate on of the tabs by pressing Enter or Space bar.
• Press the tab key again.
• Expected: focus to go to the Tab panel (either the tab panel itself or the first focusable element within it, depending on the configuration).
• Actual: focus moves to the Close button.

Screenshots, screen recording, code snippet

No response

Environment info

No response

Please confirm that you have searched existing issues in the repo.

Yes

Please confirm that you have tested with all plugins deactivated except Gutenberg.

Yes

[afercia]

Potential options to evaluate:

• Specifically to the Settings and List view panels: do these panels really need a Close button? There's already a toggle button to open and close them.
• Consider to move the Close button above the tabs, maybe preceded by a heading.
• Avoid non-standard workarounds like removing the button from the tab order or making it hidden from assistive technologies as that's not the expected interaction with a button and would introduce a new accessibility issue.

[afercia]

Cc @andrewfleming @alexstine @joedolson @WordPress/gutenberg-design

In #58940 / #58942 a decisionw as made to not not introeuce a temporary, partial, fix for this issue and rather fix the broader issue with teh Tabs component.
This requires to:

• Change the base component to not allow any content between Tabs and Tabpanels.
• A new design. Wherever tabs are used there shouldn't be anything between Tabs and Tabpanels. The DOM order must match the visual order. As such, nothing can be visually placed between Tabs and Tabpanels. For example, some 'X' Close buttons placed after the tabs need to be removed or placed elsewhere.

[alexstine]

@afercia

Specifically to the Settings and List view panels: do these panels really need a Close button?

Yes they do. The controlling toggle is multiple levels above in the DOM and would make this very undiscoverable. I opened an issue for it a long time ago, still no movement.

[richtabor]

I opened an issue for it a long time ago, still no movement.

I'm not following; there are close buttons for the Inspector and List Views.

[afercia]

I'm not following; there are close buttons for the Inspector and List Views.

As I mentioned in #58942 (comment) the 'inspector', also known as Settings panel, didn't use Tabs. It was then refactored to use Tabs and now it has the same problem: extraneous content between tabs and tab panels.

In the List View, the Close button is only visually placed between the tabs and the tab panels. In the DOM, it is actually placed before the tabs. While that's not correct anyways, because visual order and DOM order mismatch, at least there's no extraneous, unexpected tab stop between the tabs and the tab panels.

I the hope to make this issue more understandable and allow people to follow better, I'd like to illustrate again two fundamental principles:

• Any extraneous focusable element or even non-focusable content between Tabs and Tab panels breaks the ARIA tabs design pattern. It defeats the purpose of using an ARIA tabs interface.
• Visual / reading / DOM order must match.

As such, the only way to solve this issue is by changing the design.

This issue was previously reported (partially) in #58940. As of now, that's almost three months ago. A partial fix was proposed in #58942. I closed that PR after agreement to move to this, broader issue and get it prioritized.

Unfortunately, I don't see this issue getting prioritized and getting the support it would deserve from accessibility specialists., and it's still waiting for a first design proposal.