Clarify Accessibility Parent-Child Relationships for menu, group, and menuitem #2483
Conversation
✅ Deploy Preview for wai-aria ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
pkra
added
the
clarification
index.html
Outdated
| @@ -6520,7 +6535,7 @@ <h4>Plain HTML or Polyfill DOM Result of the MathML Quadratic Formula</h4> | |||
| <p>A <rref>menuitem</rref> with a checkable state whose possible <span>values</span> are <code>true</code>, <code>false</code>, or <code>mixed</code>.</p> | |||
| <p> | |||
| Authors MUST ensure [=elements=] with <a>role</a> <code>menuitemcheckbox</code> are <a>accessibility children</a> of an element with role <rref>menu</rref>, <rref>menubar</rref>, or an | |||
| element with role <rref>group</rref> that is an <a>accessibility child</a> of an element with role <rref>menu</rref> or <rref>menubar</rref>. | |||
| element with role <rref>group</rref> that is an <a>accessibility child</a> of an element with role <rref>group</rref>, <rref>menu</rref> or <rref>menubar</rref>. | |||
There was a problem hiding this comment.
I think this still allows for group > group > menuItem.
If we resolve #2016, it might be enough to require "accessibility ancestor of menu or menubar".
There was a problem hiding this comment.
I think this still allows for group > group > menuItem.
yes, it looks like people would like to use menu > group > group > menuitem, so I adjusted the PR accordingly
e.g.
<menu>
<div role="group">
<span role="menuitem">Item 1</span>
<div role="group">
<span role="menuitem">Item 2</span>
<span role="menuitem">Item 3</span>
</div>
</div>
</menu>
There was a problem hiding this comment.
Thanks. I meant that this seems to be technically valid
<div role="group">
<div role="group">
<span role="menuitem">Item</span>
</div>
</div>There was a problem hiding this comment.
Right, sorry I didn't get it.
What about adding at the end:
All group elements containing menuitem (TODO for all the menuitem roles - menuitemcheckbox...***) MUST be accessibility descendant of an element with role menu or menubar.
There was a problem hiding this comment.
That's one way. (I think adding a term for accessibility ancestor might make things easier to understand.)
There was a problem hiding this comment.
But menu would not allow navigation as an accessibility child, right?
Exactly, menu would not allow navigation; that's why the "top-level group" wording.
There was a problem hiding this comment.
Exactly, menu would not allow navigation; that's why the "top-level group" wording.
I meant that menu already prevents the example, without the additional wording.
But yes, the wording would work around
<body>
<div role="navigation">
<div role="group">
<div role="group">
<span role="menuitem">Item</span>
</div>
</div>
</div>
</body>being valid.
I still think "menuitem MUST have an accessibility ancestor menu or menubar" would be easier to understand, especially since the opening line of the role basically says so: "An option in a set of choices contained by a menu or menubar."
Another term that could be helpful: "intervening" (as used for generics): menus (of various types) contain items (of various types) but allow intervening groups.
Anyway, we need another reviewer 😉
There was a problem hiding this comment.
I believe my confusion regarding the term "accessibility ancestor" stems from the lack of a clear definition. As I understand it, the term should allow for structures like the following:
<div role="menu">
<div role="navigation">
<div role="group">
<div role="group">
<span role="menuitem">Item</span>
</div>
</div>
</div>
</div>
However, as you pointed out:
"I meant that menu already prevents the example, without the additional wording."
That said, I love your proposal:
"Intervening" (as used for generics): menus (of various types) contain items (of various types) but allow intervening groups.
This clarification ensures that both menu/menubar and menuitem/menuitemcheckbox/... definitions are explicitly clear about the group stuff. By combining the concepts of "accessibility ancestor" and "intervening," I believe we effectively address all concerns.
I'll update my PR by the end of the day with the following changes:
- drafting a definition for "accessibility ancestor"
- replacing the current wording with menuitem MUST have an "accessibility ancestor" of menu or menubar
- adding the "intervening" clarification
There was a problem hiding this comment.
Thanks, Giacomo.
We currently have
The accessibility descendants of a DOM element are all DOM elements which correspond to descendants of the corresponding accessible object in the accessibility tree.
Rough idea for ancestor:
The accessibility ancestors of a DOM element are all DOM elements of which the given DOM element is an accessibility descendant.
There was a problem hiding this comment.
Content updated as per items above.
Co-authored-by: Peter Krautzberger <[email protected]>
Co-authored-by: Peter Krautzberger <[email protected]>
fix typo
|
@np-at to review as well! |
|
actually, taking myself off as a reviewer since we have so many others. |
|
@pkra, I just realized the same issue affects tree/group/treeitem structures. Should we include this change in this PR or create a separate one? |
|
@giacomo-petri sounds good. Hopefully it's simpler since #2094 prevents group as child of tree. |
Closes #2438
The current specifications for menu and menubar contradict those for menuitem, menuitemcheckbox, and menuitemradio.
Specifically, the following structure is allowed under the menu role but not when considering the menuitem role:
This PR clarifies that this structure is indeed allowed.
Additionally, it explicitly clarifies in a note that the following example, where a group contains a button and an input as accessibility children, is not permitted. This prevents ambiguity by making it clear that having at least one menuitem as an accessibility child of the group does not justify including other unrelated elements, which was not clearly stated.
This update refines the specifications for menu, menubar, menuitem, menuitemcheckbox, and menuitemradio roles consistently.
Test, Documentation and Implementation tracking
Once this PR has been reviewed and has consensus from the working group, tests should be written and issues should be opened on browsers. Add N/A and check when not applicable.
Preview | Diff