Command Palette: Moving away from cmdk

[t-hamano]

What problem does this address?

The command palette depends on cmdk, but we are encountering several accessibility issues.

• https://core.trac.wordpress.org/ticket/64923
• The aria-activedescendant attribute is sometimes missing dip/cmdk#373
• Command Palette: fix incorrectly announced number of results #54634

As far as I know, these issues need to be resolved upstream, but unfortunately, it doesn't seem to be actively maintained.

Furthermore, it has been pointed out here that cmdk has accessibility issues.

#49330 (comment)

What is your proposed solution?

Technically, we should be able to completely decouple from cmdk and build our own fully accessible command palette. Since cmdk's core functionality is contained within a single file, the amount of code required for implementation should not be excessive.

Please let me know if there are any obstacles to moving away from cmdk.

cc @WordPress/gutenberg-core @joedolson

[ramonjd]

Makes sense to me if the blocking issues are upstream.

What are the hard parts to replacing cmdk? Does ComboboxControl component solve any of the aria/aria-activedescendant patterns?

[joedolson]

I'm highly in favor of replacing it. We can fork it, if necessary, but I suspect we can solve a lot of the problems with existing components.

[t-hamano]

Does ComboboxControl component solve any of the aria/aria-activedescendant patterns?

It seems that ComboboxControl does not use the aria-activedescendant pattern in the first place. Instead, we might be able to use a Composite component 🤔

[andrewserong]

Rolling our own makes a lot of sense to me, especially since we're using the command palette everywhere now.

[Mamaduka]

We could replace it and use Base UI components. I think that's what the new UI package is using under the hood, and it also includes a Command Palette example: https://base-ui.com/react/components/autocomplete#command-palette.

[t-hamano]

Thank you all for your feedback!

a Command Palette example: https://base-ui.com/react/components/autocomplete#command-palette.

This is very interesting. This UI appears to be highly accessible.

Perhaps we could also refer to Ariakit's patterns: https://ariakit.com/examples/combobox-group

[jameskoster]

I suspect the ScrollArea and AutoComplete primitives used in the Base UI Command Palette example would be useful in other contexts too.

[youknowriad]

For me it's an implementation detail, I don't really have strong opinions about using it or removing it. Important part is fixing the bugs.

[t-hamano]

We could replace it and use Base UI components. I think that's what the new UI package is using under the hood

If we adopt this approach, will we use @base-ui/react directly in the command palette, or will we need to wait for @wordpress/ui to be exposed?

[mirka]

will we use @base-ui/react directly in the command palette, or will we need to wait for @wordpress/ui to be exposed?

@senadir and I were discussing this recently as well, and the plan is to use the Autocomplete primitives from @wordpress/ui (#74178). These will already have some styling that adheres to the design system, but be flexible enough to use in a command palette like this. And if it's not, we'll probably want to tweak the primitives themselves so they are flexible enough.

Opening up the @wordpress/ui package for general use has been a bit delayed due to some blockers (#76135) and minor priority shifts, but the visual and API design of our Autocomplete primitive is pretty much ready. We definitely want to have them available for the 7.1 development cycle.

[senadir]

As Lena said, the initial plan was to move to Base UI, which was delayed to 7.1
With Autocomplete component built-in now (based on Base UI's one), we would use that instead, part of the styling/UI updates we're doing to the component #75616