Tabs block: Keyboard Accessibility

[joedolson]

Description

The front-end keyboard accessibility of the tabs block is very buggy. It works when navigated using tab and enter to activate tabs, but the arrowkey support is quite buggy. Unfortunately, tablists preferably should not be navigable using tab and enter; when the tablist is focused, focus should go to the first tab, then navigating between tabs should be done using arrow keys.

1. The initially selected tab is not focusable. The active tab has tabindex="-1", preventing focus.
2. When navigating by arrows, the tabs automatically change. This is OK, but it should be optional. Having the tabpanel activate on arrow navigation is only recommended if the panel will load with minimal latency, and while this should generally be true, we can't guarantee it, and it would be better to allow the user to choose their preferred behavior.
3. When navigating by arrows, navigation breaks. This is caused by the floating tabindex being mismanaged, I think. The active tab becomes unfocusable, and because of this you can no longer reach the tab.
4. Pressing spacebar on a tab causes a focus jump. The tabs are using a elements, which are only triggered by enter. But tabs expect button behaviors, so they need to be triggered by either space or enter. Enter should trigger on keydown, space should trigger on keyup.

Step-by-step reproduction instructions

1. Create a new tab block with at least three tabs
2. Place focus on something before the tab block.
3. Hit tab. Note that the focus moves to the second tab, bypassing the first.
4. Successful path: hit 'enter' on the second tab to select it. Repeat by navigating using tab, then pressing enter. This will successfully navigate the tablist, but is not the recommended tab navigation pattern.
5. Failure path: Use the left arrow key to navigate to the previous tab and the right key to navigate to the next tab. Note that behavior is quite unpredictable, depending on which tab was selected initially. Sometimes focus doesn't change, sometimes the tabpanel is hidden, etc.
6. Failure path: Use the spacebar to activate a tab. Note misplaced focus.

Screenshots, screen recording, code snippet

Environment info

-WP 7.0-alpha-61605
-Gutenberg 22.5.1
-MacOS/Firefox 146.0.1

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

Please confirm which theme type you used for testing.

• Block
• Classic
• Hybrid (e.g. classic with theme.json)
• Not sure

[joedolson]

@t-hamano I'd consider this a major blocking issue for 7.0.

[t-hamano]

I'd consider this a major blocking issue for 7.0.

I agree, I think we should stick to the patterns recommended by the W3C as much as possible.

Having the tabpanel activate on arrow navigation is only recommended if the panel will load with minimal latency, and while this should generally be true, we can't guarantee it, and it would be better to allow the user to choose their preferred behavior.

Perhaps we could consider making manual tab activation the default behavior, plus add a toggle option like "Auto-activate tabs on keyboard navigation". However, I think the option for auto-activation is not a blocker to stabilizing the block or releasing it to 7.0, and can be addressed as a follow-up to 7.0 or later.

Pressing spacebar on a tab causes a focus jump. The tabs are using a elements, which are only triggered by enter. But tabs expect button behaviors, so they need to be triggered by either space or enter. Enter should trigger on keydown, space should trigger on keyup.

I don't understand why it's an a element and not a button element in the first place.

@mikachan @sethrubenstein Is there any reason why we can't use the button element for tab menus?

[mikachan]

Thanks for reporting 🙇

Is there any reason why we can't use the button element for tab menus?

I don't think so - I can't remember there being a specific reason for not using buttons. I've just tried switching the a elements for button, and things seem to work well still.

I've attempted some fixes for these issues in #75471.