TabPanel: support manual tab activation

[ciampo]

Closes #45390

What?

Adds support for manual tab activation to the TabPanel component (see #45390 and W3C docs for more info)

Why?

New feature for the TabPanel component, for enhanced accessibility when necessary.

How?

• Introduced a new prop hasManualTabActivation (name TBD)
• The component keeps behaving as before when the new prop is not specified (backwards-compat)
• Added unit tests for both automatic and manual tab activation (including a necessary mock to test keyboard interactions)

Testing Instructions

• Load the default TabPanel example in Storybook
• Click on the first tab, then use arrow key to switch tab. Note how the currently shown tabpanel changes as the arrow keys are pressed
• Via Storybook controls, change the value of the hasManualTabActivation prop to true
• Click on the first tab, then use arrow keys to navigate through the list of tabs. Notice how focusing a tab doesn't cause the currently shown tab panel to change.
• Make sure that the tabpanel changes only when the space or enter keys are pressed while focusing a tab.

Screenshots or screencast

Kapture.2022-11-23.at.13.50.08.mp4

[codesandbox]

  Open in CodeSandbox Web Editor | VS Code | VS Code Insiders

[ciampo]

@jasmussen and @jameskoster , this may require design feedback as I don't think that TabPanel styles ever accounted for a tab to be focused while not being active.

[ntsekouras]

Thanks for the PR Marco! We just need to take a look at the non-active but focused styles, as you already mention. Other than that this looks good.

[jameskoster]

It's working for me:

tabpanel.mp4

I don't have a great idea for the name either, but perhaps something that relates more to the states involved; openPanelOnFocus?

[ciampo]

I don't have a great idea for the name either, but perhaps something that relates more to the states involved; openPanelOnFocus?

On a similar note, ariakit calls this feature selectOnMove — do we think it would be a better prop name?

[jameskoster]

@jasmussen and @jameskoster , this may require design feedback as I don't think that TabPanel styles ever accounted for a tab to be focused while not being active.

We can probably consider this when we get to #41904.

[chad1008]

One thing that's occurring to me is that ariakit and this change both default to displaying the tab on focus, which is good, but we come at it from opposite directions. To enable manual selection:

• ariakit wants selectOnMove to be false
• This PR will want hasManualTabActivation (or whatever we name it) to be true

So we'd eventually end up managing the ariakit prop with something like selectOnMove = { ! hasManualTabActivation }

That's doable, of course, but maybe it'd be more readable in the long run if we went (as @ciampo suggests) with the same selectOnMove prop name, and flipped our boolean accordingly. That way our component and ariakit's implementation are completely in sync.

[alexstine]

@ciampo Thanks for getting this done quickly. Hopefully, once this is merged, other PRs can progress and further enhancements can be made to code already in trunk.

Giving the PR an approval while the last few bits of feedback are addressed. I agree using the same prop name as we'll have in Ariakit could be useful.

[tyxla]

This is looking great, there's not much to add to what has been suggested in prior review already. 🚀

[tyxla]

Nit: should this be declared right before we override it in beforeAll? This would then be a let and we'd just set it in beforeAll().

[ciampo]

Done in 3128c26

[ciampo]

I renamed the prop to selectOnMove as agreed, and addressed all remaining feedback.

I guess the last thing to decide is whether we're ok to merge this PR with the current way tabs look in manual activation mode, when they are focused but not active (see video in the description).

[tyxla]

Looks great 🚀

[ciampo]

whether we're ok to merge this PR with the current way tabs look in manual activation mode

Given the absence of strong feedback against merging, I'll go ahead and merge this PR once CI is ✅ . As @jameskoster mentioned above:

We can probably consider this when we get to #41904.