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

Accessibility: Apply aria-haspopup to context menus and submenus #503

Closed
cjcenizal opened this issue Mar 12, 2018 · 1 comment
Closed

Accessibility: Apply aria-haspopup to context menus and submenus #503

cjcenizal opened this issue Mar 12, 2018 · 1 comment

Comments

@cjcenizal
Copy link
Contributor

From elastic/kibana#11551.

Per http://www.ssbbartgroup.com/blog/expanding-the-use-of-the-aria-haspopup-property/:

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).

@myasonik
Copy link
Contributor

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants