Tabs: Fallback to first enabled tab if no active tab Id #60681
Conversation
If there is no selectedTabId, focus will be placed on the tab container which requires an arrow keypress to move focus to the first tab. This behavior isn't as user friendly as focus should be placed on a tab. To prevent focus on the wrapper, if no element is focused and there is no activeId, fallback to the first enabled tab.
jeryj
added
[Type] Enhancement
|
The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message. To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook. |
mirka
changed the title
| useEffect( () => { | ||
| // If there is no active tab, fallback to place focus on the first enabled tab | ||
| // so there is always an active element | ||
| if ( selectedTabId === null && ! activeId && firstEnabledTab?.id ) { | ||
| setActiveId( firstEnabledTab.id ); | ||
| } | ||
| }, [ selectedTabId, activeId, firstEnabledTab?.id, setActiveId ] ); |
There was a problem hiding this comment.
I feel like it'd be safer to move this out to a designated effect like so, instead of piggybacking on another one. I'd want to avoid unintended complications down the line. In that vein, I think we'd be safer to add a selectedTabId === null condition, since that's the only time we need this logic, as far as we know. (And it doubles as a isControlled check.)
Does that sound reasonable? Anything I'm missing?
There was a problem hiding this comment.
I was considering this too from a code readability standpoint. I wasn't sure performance and debugging-wise if it would be worse to add another useEffect though. I'm totally fine with this route though if you are!
Alternative to #60573. More context in #52997 (comment)
What?
If there is no selectedTabId, focus would be placed on the tab container which requires an arrow keypress to move focus to the first tab. This behavior isn't as user friendly as focus should be placed on a tab. To prevent focus on the wrapper, if no element is focused and there is no activeId, fallback to the first enabled tab.
Why?
Sometimes you don't want any tab pane selected by default. This was possible before, but the focus was set to the wrapping element, not the first tab. Also, we'd like a tab to always be selected rather than focus placed on the wrapping container.
How?
Testing Instructions
Test the patterns inserter in #60257.
Testing Instructions for Keyboard
Screenshots or screencast