Closed JeffreyKozik closed 3 months ago
Latest commit: 3aba7a654b142e762a6cb74342e7bfb04536365f
The changes in this PR will be included in the next version bump.
Not sure what this means? Click here to learn what changesets are.
Click here if you're a maintainer who wants to add another changeset to this PR
Path | Size |
---|---|
packages/react/dist/browser.esm.js | 90.87 KB (-0.01% 🔽) |
packages/react/dist/browser.umd.js | 91.16 KB (+0.1% 🔺) |
After further discussion on Slack, accessibility experts @ericwbailey and @patrickhlauke have mentioned that using ul
and li
for Radio groups and Checkbox groups is actually not needed and can be counterproductive.
Per @ericwbailey
Lists are not required for radio groups and can circumstantially create unnecessary and unneeded verbosity. Screen readers have separate controls for traversing and enumerating radio groups, as well
Followup to https://github.com/github/github/pull/329358#discussion_r1647556804 and this discussion in Slack.
Changelog
New
Created the
CheckboxGroup.Choices
andRadioGroup.Choices
subcomponents.Currently, our Radio Group and Checkbox Groups aren't lists
But according to the ARIA Authoring Practices Guide (APG), these groups should be lists:
Additionally, one of GitHub Accessibility's "trusted component libraries" Polaris, by Shopify, follows the APG's guidelines of making their Checkbox Groups lists: https://github.com/Shopify/polaris/blob/902db588f6a317f4d6a5a76f4814bdb1f80395db/polaris-react/src/components/ChoiceList/ChoiceList.tsx#L109-L146.
I thought of three different approaches for Primer
<ul>
and<li>
elements to their code. The positive of this approach is it gives the developer maximal flexibility no matter how they're usingCheckboxGroup
orRadioGroup
. However, the downside is that it means the developer has to manually add these elements nearly every single time, otherwise their code isn't fully accessible. A cursory search of GitHub's codebase shows that is almost never implemented.li
element We could do it in the code here: https://github.com/primer/react/blob/e957fef6785277b1c30684b146a0f591d8c6b3e2/packages/react/src/internal/components/CheckboxOrRadioGroup/CheckboxOrRadioGroup.tsx#L125-L134 This removes the onus from the developer to have to manually add the<ul>
and<li>
elements to their code. The positive of this approach is that the accessibility logic is completely abstracted away into theCheckboxGroup
andRadioGroup
components. However, the downside is that doing this would be a breaking change for some implementations. For example, this code wraps Radio buttons within an ActionList: https://github.com/github/github/blob/b61537935e3cbdfa0e05a45656e854e24ae674d2/ui/packages/issue-viewer/components/RadioActionListItem.tsx#L19-L28 So automatically adding aul
element here would be wrong because an ActionList is already a list: https://github.com/primer/react/blob/e957fef6785277b1c30684b146a0f591d8c6b3e2/packages/react/src/ActionList/List.tsx#L15 https://github.com/primer/react/blob/e957fef6785277b1c30684b146a0f591d8c6b3e2/packages/react/src/ActionList/List.tsx#L62-L70CheckboxGroup.Choices
andRadioGroup.Choices
subcomponents While this approach does still require the developer to explicitly use these subcomponents, it's considerably easier and more consistent than them having to useul
andli
elements and apply custom styling. Following this approach, our Radio Group and Checkbox Groups are now listsChanged
Removed
Rollout strategy
Testing & Reviewing
Merge checklist