You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The WAI-ARIA 1.0 Specification adopted by the W3C currently limits use of the aria-haspopup attribute to context menus and sub-level menus. It also states that “a popup is generally presented visually as a group of items that appear to be on top of the main page content”.
We should apply aria-haspopup="true" to all context menus and submenus that "pop over" the main content. We can also use aria-expanded to indicate expanded state (see elastic/kibana#11514).
Note: Form fields with similar behavior should have role="combobox" instead (combobox role docs).
The text was updated successfully, but these errors were encountered:
Closing this issue because this is a very foot-gun-y approach. (Someone can reopen as a discuss issue if they want to.)
aria-haspopup="true" is really the same as aria-haspopup="menu" and if you say you have a menu popup you need to have menu semantics and menu semantics aren't your colloquial "oh, this looks like a menu" type of menu but are super finicky and particular structures. Our context menus are definitely not "menus" by the ARIA definition.
From elastic/kibana#11551.
Per http://www.ssbbartgroup.com/blog/expanding-the-use-of-the-aria-haspopup-property/:
We should apply
aria-haspopup="true"
to all context menus and submenus that "pop over" the main content. We can also usearia-expanded
to indicate expanded state (see elastic/kibana#11514).Note: Form fields with similar behavior should have
role="combobox"
instead (combobox role docs).The text was updated successfully, but these errors were encountered: