-
Notifications
You must be signed in to change notification settings - Fork 4.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
DataViews: set proper semantics for dropdown items #56676
Conversation
Size Change: +49 B (0%) Total Size: 1.72 MB
ℹ️ View Unchanged
|
Thanks for the PR! I know @ciampo has a PR for replacing the dropdown, but maybe it's better to use the new one and make improvement there if needed? |
No reason not to land this simple fix while the new dropdown is being worked on (I don't know the timeline for that, we may find issues while doing it, etc.). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you for working on this!
Rather than using DropdownMenuItem
and manually adding role
and aria-checked
attributes, we should use the dedicated menu radio item components.
- If we're using the
DropdownMenuV2
(the radix-based one, that will soon be deleted), we should use thevalue
/onValueChanged
props instead of theonSelect
prop (example) - If we were to use the new version of the component (based on
ariakit
), we should use thechecked
andonChange
props on each menu items (you can see how I approach a similar refactor in Refactor experimental dropdown menu usages to latest version #55625)
Hope this makes sense!
fe17240
to
42b7917
Compare
@ciampo Thanks for the advice, that's great. There are some subtle differences between the new components and the old ones (focus, for example), so I'd rather update them all together. I've tried using the specific components in other PRs (radio, checkbox) and ran into issues (couldn't uncheck, etc.) — perhaps it was my own fault, I'm not sure, I'll revisit. Anyway, this PR also makes the e2e test more robust (searching string using exact, delete template in |
Sounds good
That is possible, and it would be because radio items are not supposed to be unchecked (see related comment). For posterity, I'm also linking to a related conversation that we've been having about the right semantics / widgets that should be probably used for these components. |
role="menuitemradio" | ||
aria-checked={ false } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is a weird one, but I'd probably argue that these should have a role of menuitem
. They are not values in and of themselves; instead, they are all actions that create a new filter with a particular value.
role="menuitemradio" | |
aria-checked={ false } | |
role="menuitem" |
Ideally we'd put this in front of actual users, but given the submenu isn't available once the filter has been created, it kind of ceases to matter what their selected state is, or whether they are mutually exclusive.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(Looks like I was 30 seconds late with feedback 😩 Not a blocker, just something to think about.)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Part of #55083
What?
Set the proper semantics for the existing menu items.
Why?
In some cases, the item was declared as behaving as a checkbox while their behavior was actually like a radio item.
How?
Set the proper
role
for everyDropdownMenuItem
.