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

menubar-navigation example aria-expanded without aria-controls/aria-owns #2888

Open
flavi1 opened this issue Dec 15, 2023 · 3 comments
Open
Assignees
Labels
agenda Include in upcoming Authoring Practices Task Force meeting question Issue asking a question

Comments

@flavi1
Copy link

flavi1 commented Dec 15, 2023

Hello
In the example :
https://www.w3.org/WAI/ARIA/apg/patterns/menubar/examples/menubar-navigation/
aria-expanded attributes are presents on links (role=menuitem). The concerned submenus (ul[role=menu]) are not children of theses links. So the DOM hierarchy is not representing the relationShip. But there is no aria-controls or aria-owns to describe explicily the relationship. Am I wrong? Or Is it a mistake? Or the relationship is implied by their respectives roles (menuitem/menu)? I don't find a definition of what is an implicit relationship. In witch cases are we able to omit aria-controls/aria-owns?
Thank you

@flavi1
Copy link
Author

flavi1 commented Dec 15, 2023

In another examples like this one : https://www.w3.org/WAI/ARIA/apg/patterns/treeview/examples/treeview-1a/
We can see a similar situation (no aria-controls/aria-owns), but the expandable sub elements (role=group) are children of the LI aria-expanded. I assume this is what "DOM hierarchy representing the relationShip" means.

@JAWS-test
Copy link

The ARIA specification says nothing directly about how submenus are nested. Therefore, the example may be correct and it is not necessarily a mistake that it works differently than a tree structure.
Indirectly, however, the ARIA specification does say that the example is not correct, because in "Allowed Accessibility Child Roles" the menu role is not mentioned for either menu or menubar.
This means that either the ARIA specification or the pattern is incorrect.

Related: w3c/aria#1425 (and w3c/aria#1478)

@mcking65 mcking65 added question Issue asking a question agenda Include in upcoming Authoring Practices Task Force meeting labels Jan 9, 2024
@mcking65 mcking65 self-assigned this Jan 9, 2024
@css-meeting-bot
Copy link
Member

The ARIA Authoring Practices (APG) Task Force just discussed menubar-navigation example aria-expanded without aria-controls/aria-owns.

The full IRC log of that discussion <jugglinmike> Subtopic: menubar-navigation example aria-expanded without aria-controls/aria-owns
<jugglinmike> github: https://github.com//issues/2888
<jugglinmike> Matt_King: The reporter is saying that the submenus are not DOM descendants of the parent menu item. That is different from trees, but is it allowed?
<jugglinmike> Bryan_Garaventa: It doesn't have to be a descendant in practice. However, I don't know if the spec actually says that it has to be a child in the same way it says for a tree
<jugglinmike> Matt_King: They're saying it's not a DOM descendant and it doesn't have controls, so there's basically no relation
<jugglinmike> Bryan_Garaventa: When you're getting information like "how many menu items", it does that based on the nesting of those menus. When you use a link, the same thing happens
<jugglinmike> Matt_King: It seems that in our example, there is no relationship between the controlling menu item and the controlled menu item. Is that a problem?
<jugglinmike> Bryan_Garaventa: You can break them out. ARIA doesn't require us to put ARIA controls on there. We don't do it; the question is, should we?
<jugglinmike> s/ ARIA doesn't require us to put ARIA controls on there. We don't do it; the question is, should we?//
<jugglinmike> Matt_King: ARIA doesn't require us to put ARIA controls on there. We don't do it; the question is, should we?
<jugglinmike> Bryan_Garaventa: I would recommend not
<jugglinmike> siri: I learned some time back that as of now, the screen readers don't do anything with ARIA controls.
<jugglinmike> siri: What is the purpose of adding ARIA controls rather than "expanded" and "collapsed"?
<jugglinmike> Matt_King: It seems to me that if there's a focus, it can impact how focus moves across the document
<jugglinmike> Bryan_Garaventa: My understanding is that ARIA controls is useful when it renders content
<jugglinmike> s/content/content [...]/
<jugglinmike> [Bryan_Garaventa's explanation proceeded faster than could be scribed]
<jugglinmike> CurtBellew: I thought that the point of ARIA controls was to allow devs to take something clickable and express that the clickable element controls some content
<jugglinmike> Matt_King: I've marked this as a question, assigned it to me, and added it as an agenda item.
<jugglinmike> Jem: It will be great to have more conversation! I'm always controlled about ARIA controls
<jugglinmike> Zakim, end the meeting

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
agenda Include in upcoming Authoring Practices Task Force meeting question Issue asking a question
Projects
None yet
Development

No branches or pull requests

4 participants