Accordion toggles in the Connectors > AI plugin page miss a focus style

[hbhalodia]

Description

• Following up from here - Accordion toggles in the Connectors > AI plugin page don't follow the APG pattern and miss a focus style gutenberg#82986, There is no focus style when user tabs to the accordion on the settings page. (Cc: @mirka @afercia )
• This is due to the package seems not to be updated to the latest version.
• We have some fixes in upstream on the UI package that is dependent by - @wordpress/dataviews in PR CollapsibleCard: Fix missing keyboard focus ring on the header chevron icon when rendered inside wp-admin gutenberg#77468.
• We need to update the @wordpress/dataviews to latest version added here https://www.npmjs.com/package/@wordpress/dataviews - 19.0.0 to fix the issue mentioned.
• Also update @wordpress/data to version 10.55.0 to fix typecheck errors.

Note: We may need to update all the packages to there latest version for at least @wordpress/* in the plugin?

Cc: @dkotter

Step-by-step reproduction instructions

• Go to WP Admin > Connectors.
• Install and activate the AI plugin.
• You will be redirected to the AI plugin settings page wp-admin/options-general.php?page=ai-wp-admin
• Use the tab key to navigate the page.
• Observe that when you land on on one of the accordion toggles (Editor Experiments or Admin Experiments) there is a tab stop but there is no focus style.

Screenshots, screen recording, code snippet

Screen.Recording.2026-09-16.at.2.31.01.PM.mov

Environment info

• WordPress Latest.
• WordPress AI latest.

Please confirm that you have searched existing issues in the repo.

• Yes

Please confirm that you have tested with all plugins deactivated except the AI plugin.

• Yes

Please confirm which theme type you used for testing.

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

[hbhalodia]

Qq: Should we update all the packages as a part of this PR or should create a new issue suggesting to update the packages?

Cc: @dkotter @jeffpaul

[dkotter]

Qq: Should we update all the packages as a part of this PR or should create a new issue suggesting to update the packages?

See #831 where we pinned these versions as the thought here is we should be using the versions of these packages that ship with our minimum supported WordPress version (in this case, WP 7.0). We also have a draft in place that downgrades things that were already bumped beyond that version (see #832).

So the short answer here is we've deliberately not been updating those packages since that PR was merged. This doesn't apply to @wordpress/ui and @wordpress/admin-ui though which we have been updating. And there was discussion on doing the same for @wordpress/dataviews (see comments on #984)

[hbhalodia]

Thanks @dkotter, So should we target this PR only to update @wordpress/dataviews package and nothing else correct? Or what is direction here to fix the above, is that to wait to check the min supported WP version for which this package get's released.

[dkotter]

@hbhalodia In doing a quick test, seems like bumping just @wordpress/dataviews fixes the problem. If that's accurate, I'd say update that PR to just update that package for now unless there's some benefit to also updating @wordpress/data

[hbhalodia]

Thanks @dkotter, The reason beging because of Javascript typecheck was failing. npm run typecheck failed when only updating the dataviews.

@wordpress/dataviews@19 needs @wordpress/data@^10.55.0, but ours was10.44.0. Since those don't match, npm installed a second copy of @wordpress/data (10.55.0) nested under editor, block-editor, etc.

With two copies, select()/dispatch() (from the old copy) no longer match the store types (from the new copy), so they resolve to unknown/never that's yields to typecheck errors.

Bumping @wordpress/data to 10.55.0 collapses it back to a single copy and fixes them. It satisfies every version range in the tree, and it's types/build-only, no runtime change, since WordPress serves one wp.data global.