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

[bvandercar-vt]

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

[adidahiya]

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]

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]

@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]

@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

[adidahiya]

overall this looks good, just some minor code style concerns

[adidahiya]

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";

[bvandercar-vt]

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.

[adidahiya]

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