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

Nested menus vs. required owned elements #1425

Open
smhigley opened this issue Mar 10, 2021 · 4 comments
Open

Nested menus vs. required owned elements #1425

smhigley opened this issue Mar 10, 2021 · 4 comments
Assignees
Milestone

Comments

@smhigley
Copy link
Contributor

This is related to #1033 in that it may or may not be an issue, depending on the interpretation of "required owned elements" :D.

I'd just like to suggest a clarification on the menu role, specifically around nested dropdown menus. Right now, the structure of required owned elements / required context role suggests the following structure:

menu / menubar > group (optional) > menuitem / -checkbox / -radio

The problem is that often nested dropdown menus end up creating a role structure where menu is a child of a parent menu or menubar (or sometimes even placed under menuitem). Even if this is technically allowed under a permissive reading of "required owned elements", I think it'd be useful to clarify where the nested menu should go.

A practical example of this is in the APG menu examples, where the dropdown menu is a child of menubar: https://w3c.github.io/aria-practices/examples/menubar/menubar-editor.html

@patrickhlauke
Copy link
Member

coming in late, but as this just bubbled up in a discussion: yes, it would be good to clarify (even if it's just in prose) what the story with nested menus is. an initial skim over the spec seems to suggest that a role="menu" can't be a direct child of another role="menu"...

@DeepOceanWaters
Copy link

DeepOceanWaters commented Aug 10, 2023

Yes, I was discussing with Patrick and Adrian on the a11y slack channel about this issue. To me it seems that the wording of the 5.2.6 Allowed Accessibility Child Roles does not allow a role=menu to be nested inside another role=menu given the wording

A list of roles which are allowed on an accessibility child (simplified as "child") of the element with this role. Authors MUST only add child element with allowed roles.

and that the role=menu's characteristics table's allowed accessibility child roles row only contains the roles menuitem, menuitemcheckbox, and menuitemradio (and groups containing those roles).

@flavi1
Copy link

flavi1 commented Dec 18, 2023

Does this means that nested menus have to be achieved with the group role to declare submenus? Is it sementically ok to use group role instead of menu role for submenus?

@JAWS-test
Copy link
Contributor

JAWS-test commented Dec 18, 2023

Is it sementically ok to use group role instead of menu role for submenus?

No. If I understand it correctly, submenus are implemented with role=menu (nested in the parent menu). role=group is not for submenu, but for a grouping within a menu (see https://www.w3.org/WAI/ARIA/apg/patterns/menubar/examples/menubar-editor/ - submenu "Size" uses role=group for menuitemradios "X-Small" to "X-Large")

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

No branches or pull requests

7 participants