CheckboxControl, RadioControl, ToggleControl: Support accessible, flexible layouts

[mirka]

What problem does this address?

CheckboxControl, RadioControl, and ToggleControl do not properly support our layout needs, and developers are forced to roll their own solutions or override the component in fragile ways, which can result in slower iteration speeds and accessibility issues.

Examples of the problems we're encountering

CheckboxControl

• Make sure interactive controls are always labeled #51740 (comment)
• Try: Reduce checkbox size in data views #60475 (comment)

RadioControl

• The RadioControl component renders invalid and not accessible markup #52890
• Post Editor: Update publish flow #60456 (comment)

ToggleControl

• Refactor the hooked blocks plugins UI to not use flex-direction row-reverse #63094

What is your proposed solution?

This can potentially be addressed in multiple ways, so we need to assess what is the best way forward. Possible approaches include:

• Improve the documentation (e.g. Storybook examples) so that they show how to accessibly implement common custom layouts.
• Moving to a more modular API based on subcomponents, taking inspiration from (or directly use) Ariakit components.
• Keeping the current APIs, but also exporting more modular subcomponents like we do with BaseControl.VisualLabel. This must be coupled with clear usage guidance for accessibility.

[ntsekouras]

I'd avoid suggestion 1 and between the remaining two, I have a preference for suggestion 2. We've started doing it for more components and it's nice to have some a11y problems already solved by Ariakit.

[mirka]

I'd avoid suggestion 1

At least for CheckboxControl, the accessibility mishaps I've seen are mostly due to lack of awareness rather than deficiencies in component API, so we'd probably need to tackle the issue from the documentation angle as well, regardless of any improvements we can make to the actual API. I haven't looked too deeply into the RadioControl situation though.