WB-1671: Dropdown: use combobox role in all openers
#2345
Conversation
🦋 Changeset detectedLatest commit: f90f127 The changes in this PR will be included in the next version bump. This PR includes changesets to release 2 packages
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 |
GeraldRequired Reviewers
Don't want to be involved in this pull request? Comment |
|
NOTE: unchecking the |
npm Snapshot: Published🎉 Good news!! We've packaged up the latest commit from this PR (f3a0de3) and published all packages with changesets to npm. You can install the packages in webapp by running: ./services/static/dev/tools/deploy_wonder_blocks.js --tag="PR2345"Packages can also be installed manually by running: yarn add @khanacademy/wonder-blocks-<package-name>@PR2345 |
|
Size Change: +51 B (+0.05%) Total Size: 96.4 kB
ℹ️ View Unchanged
|
A new build was pushed to Chromatic! 🚀https://5e1bf4b385e3fb0020b7073c-eokoapveme.chromatic.com/ Chromatic results:
|
jandrade
changed the title
combobox role in all openerscombobox role in all openers
marcysutton
force-pushed
the
dropdown-combobox
branch
from
c4fb2b1 to
f90f127
Compare
marcysutton
changed the title
combobox role in all openerscombobox role in all openers
|
I rebased this one to bring it up to date and I'm proposing we merge it to deal with a number of screen reader issues for Dropdowns. Essentially, we need the |
🎉| /** | ||
| * The role of the opener. | ||
| */ | ||
| role?: "combobox" | "button"; |
There was a problem hiding this comment.
nit: What do you think about making the role not optional so it has to be explicitly set? "combobox" and "button" roles are quite different so making it mandatory would mean we would have to intentionally set it!
| @@ -569,6 +569,7 @@ const MultiSelect = (props: Props) => { | |||
| disabled={isDisabled} | |||
| id={uniqueOpenerId} | |||
| aria-controls={dropdownId} | |||
| placeholder={noneSelected} | |||
There was a problem hiding this comment.
Should the placeholder be menuText so the aria-label changes when the selected values change? Otherwise, it'll always have an aria-label for no items selected. menuText isn't always a string though since it can be custom jsx! Or maybe the select opener wouldn't need an aria-label since the component should be used with a <label>? 🤔 What do you think!
Here's a screenshot that shows the aria-label with "0 items" while the component shows "3 items":
| @@ -38,6 +38,8 @@ type SelectOpenerProps = AriaProps & { | |||
| * of this component. A placeholder has more faded text colors and styles. | |||
| */ | |||
| isPlaceholder: boolean; | |||
|
|
|||
| placeholder?: string; | |||
There was a problem hiding this comment.
nit: What do you think about renaming the placeholder prop to ariaLabel so it is named after what it's used for? We also have the isPlaceholder prop so I was wondering how they were related (they're not 😅). Or adding prop jsdocs could help with understanding!
| "@khanacademy/wonder-blocks-dropdown": patch | ||
| --- | ||
|
|
||
| Update dropdown openers to use `role="combobox"` instead of `button`. |
There was a problem hiding this comment.
(very) nit: The ActionMenu also uses DropdownOpener and it still uses role="button"!
| Update dropdown openers to use `role="combobox"` instead of `button`. | |
| Update dropdown openers for SingleSelect and MultiSelect to use `role="combobox"` instead of `button`. |
| @@ -173,8 +176,9 @@ export default class SelectOpener extends React.Component< | |||
| aria-haspopup="listbox" | |||
| data-testid={testId} | |||
| id={id} | |||
| role="combobox" | |||
There was a problem hiding this comment.
Side note: Since our selects now use role=combobox, we'll be able to treat SingleSelect/MultiSelect more like fields! I created WB-1807 for applying aria-required on these components since it's only valid on role=combobox and not role=button 😄
| @@ -77,7 +77,7 @@ describe("MultiSelect", () => { | |||
| const {userEvent} = doRender(uncontrolledMultiSelect); | |||
|
|
|||
| // Act | |||
| await userEvent.click(await screen.findByRole("button")); | |||
| await userEvent.click(await screen.findByRole("combobox")); | |||
There was a problem hiding this comment.
When we make internal changes that break existing tests, do we consider it a major breaking change since it could break tests in consuming projects? In this case, I'm thinking it's not since the role isn't part of the external API of the component! I'm curious to hear what others think though!
(I might have asked this before but wanted to double check!)
Summary:
Addreses an issue in WB dropdowns where we were using the
buttonrole in theopener, which was causing issues with screen readers. This change updates the
role to
comboboxthat is more appropriate for the dropdown opener.Issue: https://khanacademy.atlassian.net/browse/WB-1671
Test plan:
Navigate to the dropdowns in the Storybook and verify that the role of the
opener is
combobox.More details TBD