Initial ARIA fix-up of menus

[patrickhlauke]

Add aria-haspopup to trigger element and missing role/tabindex for menu items.
Additionally, change old role="presentation" for dividers to role="separator".
Fixes #15829
Note that there are still outstanding issues with the current ARIA-fication of menus (particularly with their JS-based behavior). This fix only introduces the correct (required, in the case of role="menuitem and role="presentation" on the <li> elements) role assignments.
/cc @mdo @cvrebert

[mdo]

Dang, that's a lot of role.

[patrickhlauke]

Unfortunately, them's the breaks when using role="menu". By having that initial role, you're signaling to AT that what follows is an ARIA menu - after that, any content needs to also follow the expected structure of an ARIA menu, which requires child elements of role="menuitem", role="menuitemcheckbox" or role="menuitemradio". Note that some parts of our documentation already used this full pattern, and this just brings the rest in line with it.
Not for v3, but certainly for v4 I'd say there's scope here to look at our scripts (e.g. for dropdown) to automagically inject the appropriate set of roles to the author's markup when the components are initialised.

[patrickhlauke]

just to be clear: we either need to add all these roles (to properly implement the expected set of roles for an ARIA menu), or we need to remove the incomplete role="menu" that's currently present in our dropdowns. either way, current situation is broken (and will have weird results in AT)

[mdo]

What's the downside of removing role="menu"?

[patrickhlauke]

the downside is that application-like menus will not be announced by assistive technologies in the same way as real native application menus (think for instance File, Edit, etc menus in a Windows native app). (though to work correctly, all other roles also need to be in place and the pattern cannot be deviated from with any mixed content). Removing the role="menu", but keeping all other related role and aria-* attributes for the trigger elements etc will make the menus be announced as generic "popup" style content. in my personal view, that's better than having a broken menu (or something that gets announced as a menu but then, due to developers adding their own stuff that deviates from the pattern, doesn't behave like one). will double-check with some colleagues (but can already sense this will be a divisive issue for some)

[mdo]

in my personal view, that's better than having a broken menu (or something that gets announced as a menu but then, due to developers adding their own stuff that deviates from the pattern, doesn't behave like one). will double-check with some colleagues (but can already sense this will be a divisive issue for some)

Sounds reasonable to me. Holler when you hear more.

[patrickhlauke]

parking this non-scientific poll here for now, but my gut feeling is to remove some of the role="menu" assignments (and perhaps replace them with a boxout about "if you're actually doing a proper menu, consider reading up on additional ARIA that can be used"). ditto for the "not quite a tab panel pattern" case of #14295 (comment)

[patrickhlauke]

In an attempt to make this mega-PR a bit more digestible, while I plan moving away from actual role="menu", I've split out the non-controversial change to <li class="divider"></li> here #16561

[patrickhlauke]

Closing this, as #16571 takes care of the rest...