Skip to content
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

[core] feat(MenuItem): new prop 'roleStructure' #5377

Merged
merged 27 commits into from
Jul 8, 2022

Conversation

bvandercar-vt
Copy link
Contributor

@bvandercar-vt bvandercar-vt commented Jun 15, 2022

Fixes #0000

Checklist

  • Includes tests
  • Update documentation

Changes proposed in this pull request:

allow for setting MenuItem to have proper role structure for when the MenuItem is an item of a "listbox" or "select" element.

Default role structure for a MenuItem is:

      <li role="none"
         <a role="menuitem"

which is correct when it is a child of a Menu that has role="menu", which is the default role for the Menu element.

However, for situations where we change the Menu role to role="listbox" (such as in Select2, Suggest2, and MultiSelect2), we need a different role structure for its child MenuItems:

  <li role="option"
         <a role=undefined

Copy link
Contributor

@adidahiya adidahiya left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

When would you use an alternative role for the <li>? The child element is already getting role="menuitem".

Also what other attributes would you imagine passing along? Again I must point you to the comment I made on another PR: #5356 (comment) -- if this PR is to be merged, it must add an example usage of the new feature to either docs-app or demo-app.

@bvandercar-vt
Copy link
Contributor Author

bvandercar-vt commented Jun 15, 2022

When would you use an alternative role for the <li>? The child element is already getting role="menuitem".

Also what other attributes would you imagine passing along? Again I must point you to the comment I made on another PR: #5356 (comment) -- if this PR is to be merged, it must add an example usage of the new feature to either docs-app or demo-app.

The usage for an alternative role for the <li> can be seen in the change to the select2.md file in this PR-- for most cases that we use MenuItem , it would be under a Menu that has the default role="menu", in which case we need the <li role="none"><a role="menuitem"> setup, which is also the default. But for other cases where the Menu is assigned a different role than menu, such as in this case with the menu of Select2 where it assigned role="listbox", we need it to have <li role="option"><a> since the parent menu is a listbox.

As you can see in all these examples:
https://www.w3.org/TR/2017/WD-wai-aria-practices-1.1-20170628/examples/listbox/listbox.html
when the ul (the Menu) has role="listbox", the li's should have role="option".

I'm not sure how this would be represented in any of the docs or examples, it's just used to add additional props if the user wants/needs to, but it doesn't affect anything functionally or visually

@bvandercar-vt bvandercar-vt changed the title allow for passing liProps for MenuItem li element allow for setting MenuItem to have proper role structure for when is an item of a "listbox" or "select" element Jun 22, 2022
@bvandercar-vt
Copy link
Contributor Author

@adidahiya I completely revamped this PR, changed the description. Same goal as before. Please re-review and let me know what you think. I think these changes indicate what I'm going for here.

@bvandercar-vt
Copy link
Contributor Author

@adidahiya so basically our a11y improvements to Select2/MultiSelect2 (ie adding role="combobox", aria-controls="listbox", etc.) are still kindof useless until we make this a11y change. Please review and consider this PR

Copy link
Contributor

@adidahiya adidahiya left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

overall this looks good, just some minor code style concerns

*
* @default "menuitem"
*/
roleConfig?: "menuitem" | "listoption";
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

prefer to avoid names like "config" in prop / variable names, as this is all essentially "configuration". instead we use "kind" in other places in Blueprint, and I think it could work well here:

Suggested change
roleConfig?: "menuitem" | "listoption";
roleKind?: "menuitem" | "listoption";

Copy link
Contributor Author

@bvandercar-vt bvandercar-vt Jul 7, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

used roleStructure, thinking that roleKind is a little too close to having the user think that the value should be an aria role, when that's not the case.

Let me know if you'd still rather have it be roleKind, no big deal.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Alright, I don't have a strong opinion between the two options, let's go with what you have now 👍🏽

packages/core/src/components/menu/menuItem.tsx Outdated Show resolved Hide resolved
packages/select/src/components/select/select2.md Outdated Show resolved Hide resolved
@adidahiya adidahiya changed the title allow for setting MenuItem to have proper role structure for when is an item of a "listbox" or "select" element [core] feat(MenuItem): new prop 'roleKind' sets proper roles for different contexts Jul 7, 2022
@adidahiya adidahiya changed the title [core] feat(MenuItem): new prop 'roleKind' sets proper roles for different contexts [core] feat(MenuItem): new prop 'roleStructure' Jul 8, 2022
@adidahiya adidahiya merged commit 519c09a into palantir:develop Jul 8, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants