-
Notifications
You must be signed in to change notification settings - Fork 370
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
Comments
In another examples like this one : https://www.w3.org/WAI/ARIA/apg/patterns/treeview/examples/treeview-1a/ |
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. Related: w3c/aria#1425 (and w3c/aria#1478) |
The ARIA Authoring Practices (APG) Task Force just discussed 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 |
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
The text was updated successfully, but these errors were encountered: