Composite: make items tabbable if active element gets removed

[ciampo]

What?

May fix #65283

This PR tweaks the behavior of the Composite component so that the composite widget can continue to receive keyboard focus even when its active ID doesn't correspond to an element rendered in the DOM.

Why?

The fact that Composite can end up in a situation where the whole widget is not focusable is bad for assistive technology, and we should try to fix it.

How?

Following a suggestion from the Ariakit maintainers, this PR makes all composite items tabbable if the element associated with the active ID is not connected to the store.

In this case, when the focus is moved back to the composite widget, the items will be able to receive focus. As soon as one item receives focus, all composite items will stop being tabbable and revert back to the standard behavior of a composite widget.

Review suggestions

Review commit-by-commit. The actual fix is applied in the first commit. The rest of the commits are accessories to the main fix.

Testing Instructions

In Storybook:

• Load the "Remove active item" example
• Focus the composite widget, and with the arrow keys move focus on the third item
• Tab to the "Toggle third item button" and click it
• Tab back to the composite widget: the second item should receive focus and become active
• Moving arrow keys should work as expected in the composite widget

Edit: it looks like the UI has changed and it's impossible to reproduce the bug in the editor as of now

In the editor:

• Follow the testing instructions indicated in Options in the CircularOptionPicker may be not operable with the keyboard #65283
• When clicking the "randomize colors" button, tab back to the color palette.
• The last item in the palette should receive keyboard focus
• Moving arrow keys should work as expected in the composite widget

Screenshots or screencast

Before (trunk)	After (this PR)
Kapture.2024-09-30.at.14.18.39.mp4	Kapture.2024-09-30.at.14.22.18.mp4

[github-actions]

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 props-bot label.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Co-authored-by: ciampo <[email protected]>
Co-authored-by: diegohaz <[email protected]>
Co-authored-by: tyxla <[email protected]>
Co-authored-by: mirka <[email protected]>
Co-authored-by: afercia <[email protected]>

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

[github-actions]

Flaky tests detected in 7de8ae6.
Some tests passed with failed attempts. The failures may not be related to this commit but are still reported for visibility. See the documentation for more information.

🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/11160667834
📝 Reported issues:

• [Flaky Test] should move focus to the block #38832 in /test/e2e/specs/widgets/customizing-widgets.spec.js

[tyxla]

Looks good, works well 👍

Thanks for adding tests and a special storybook story to manually test it in 🙇‍♂️

Not approving just yet since we'll need to clean up after merging #65823 and #65821.

[ciampo]

Rebased to include changes from #65823 and #65821 (which were merged in the meantime), and addressed other pending feedback

@tyxla this is ready for another round of review

[tyxla]

LGTM 🚀

[ciampo]

I'll enable backporting once #65853 gets merged

[github-actions]

I just cherry-picked this PR to the wp/6.7 branch to get it included in the next release: 54ee0ee

[diegohaz]

@ciampo Thanks for trying this. Is there anything noteworthy about this change that we should know before implementing it on Ariakit? Have you encountered any issues?

[ciampo]

I haven't encountered issues myself, not have received any reports — @afercia , do you have any feedback?

[afercia]

@ciampo @diegohaz I haven't tested the progress on this fix since I reported it iin #65283

Do I get it correctly that the fix is:

• When there's no element referenced by the activeId, all the items become focusable.
• As soon as one of the items receives focus, the original behavior is restored with only one item tabbable (tabindex=0) and the other ones not tabbable (tabindex=-1). Arrows navigation will work as expected.

If that's correct, it seems to me it's a reasonable and effective fix.