[giacomo-petri]

🚀 Netlify Preview:
🔄 this PR updates the following specs:

• ARIA preview — ARIA diff

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:

<div role="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>
</div>

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.

<div role="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>
		<button>Test</button>
		<input type="text aria-label="Test">
	</div>
</div>

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.

• "author MUST" tests:
• "user agent MUST" tests:
• Browser implementations (link to issue or commit):
  • WebKit:
  • Gecko:
  • Blink:
• Does this need AT implementations?
• Related APG Issue/PR:
• MDN Issue/PR:

---

Preview | Diff

[netlify]

✅ Deploy Preview for wai-aria ready!

Name	Link
🔨 Latest commit	7e2e53b
🔍 Latest deploy log	https://app.netlify.com/projects/wai-aria/deploys/6acf5ba12690bd34497a1632
😎 Deploy Preview	https://deploy-preview-2483--wai-aria.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.
🤖 Make changes	Run an agent on this branch

---

To edit notification comments on pull requests, go to your Netlify project configuration.

suggestions applied

[spectranaut]

@np-at to review as well!

[scottaohara]

actually, taking myself off as a reviewer since we have so many others.

[giacomo-petri]

@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?

[pkra]

@giacomo-petri sounds good. Hopefully it's simpler since #2094 prevents group as child of tree.

[giacomo-petri]

I've picked this PR up again and tried to make it easier to understand, while also addressing the concerns about the wording raised in some of the previous comments (@pkra, I hope this version is a step forward). Summary of the latest commits:

• Intervening role: We originally agreed to define "intervening" later on, but without a definition group as intervening role remained ambiguous, so I've introduced it in this PR:

  • allowed accessibility child roles: a role listed as an intervening role is allowed as an accessibility child, and its own accessibility children are also checked against the same list, at every level of nesting. Unlike generic and none, an element with an intervening role remains an accessibility child in the accessibility tree
  • required accessibility parent role: an element can be an accessibility child of an element with an intervening role, provided that the outermost one is an accessibility child of a non-intervening role from the list
  • UA rule in required accessibility parent role is updated accordingly, so that UA behavior does not change (e.g. a menuitem inside a group outside of any menu is still ignored
  • added a valid example with nested groups to the existing examples in allowed accessibility child roles.

  Note: I placed the definition in "Allowed Accessibility Child Roles" because it only affects role constraints, not the accessibility tree. Happy to move it to "Relationships in the Accessibility Tree" if preferred.

• menu / menubar

  • allowed children now list group as intervening role
  • rewrote the notes and added an example showing that a group containing menuitems still does not allow unrelated children, such as a button.

• menuitem / menuitemcheckbox / menuitemradio

  • required parent roles now list group as intervening role, replacing the initial verbose group rows, that were creating donut scoping issues. This closes the gap where group > group > menuitem was valid outside of a menu.

• group

  • following @pkra's feedback, the menu/menubar guidance is now a non-normative note, and the listbox sentence is restored as it is in main.

• other editorial fixes

[css-meeting-bot]

The ARIA Working Group just discussed Needs Review - Clarify Accessibility Parent-Child Relationships for menu, group, and menuitem.

The full IRC log of that discussion

<Zakim> agendum 4 -- -> Needs Review - Clarify Accessibility Parent-Child Relationships for menu, group, and menuitem https://github.com//pull/2483 -- taken up [from agendabot]
<pkra> jamesn: this is a reminder to review. If you have volunteered, please review. If you're interested, please add yourself.
<Daniel> s/I think there will be more info next week./A draft schedule for breakout sessions will be available early next week/
<pkra> giacomo-petri: I've added an intervening role. We had agreed to add it later but it seemed better this way. I've adjusted the definitions. I've updated the role with this.
<pkra> ... this makes it some things easier.
<Daniel> s/the draft schedule should be ready./When the draft schedule is announced, it would be good for people to take a look and communicate to me any conflicts they see for us to try to address them early enough./
<pkra> jamesn: sounds more substantial. Please take another look.
<pkra> ... or let us know if you're unable to.
<pkra> spectranaut_: we may need additional ones.
<pkra> zakim, next item
<Zakim> agendum 5 -- -> Needs Review - Presentational Roles Conflict Resolution - global WAI-ARIA states or properties on inherited presentational roles
<Zakim> ... https://github.com//pull/2237 -- taken up [from agendabot]
<pkra> jamesn: another PR needing review.
<pkra> giacomo-petri: the main point is that I've tried to make the point clearer that UAs must not make them available.
<pkra> q+
<pkra> ... and some other changes.
<giacomo-petri> q+
<jamesn> Ack pkra
<jamesn> Ack giacomo-petri
<pkra> pkra: I just wanted to point out that we had discussed removing presentational inheritance. That might impact this. But it's not even drafted yet.
<pkra> giacomo-petri: some changes are informed by that thinking, too.
<pkra> zakim, next item

[spectranaut]

A few small things. Overall I approve, the language is a bit difficult to read but I don't think we can avoid that -- i think it's accurate and the examples make it clear!

[spectranaut]

I wonder if these needs to be a note, or if can just be another paragraph.

[pkra]

Re-reviewing this from scratch, I'm still concerned about this change.

I find the new terminology difficult and potentially confusing. It only seems to be introduced to clarify something for role group so I'm wondering why we don't clarify it there instead. Given other issues around groupings, I suspect there may be deeper problems (also in implementations) which this new terminology won't address.

Perhaps we need more group-derivatives (like rowgroup). Perhaps it just boils down to the content model discussion. But I think this needs more discussion.

[pkra]

I find this sentence difficult to follow.

[giacomo-petri]

I'm finding it difficult to come up with wording that is both precise and clear without making it overly complex.

I’ve split the original sentence into multiple sentences to make the logic easier to follow and reduce the complexity of the wording. I’ve also added examples to illustrate the reasoning.

Hope this helps

[pkra]

Why is the second sentence added here?

[pkra]

This messy paragraph is what this PR is really trying to clean up, no?

[giacomo-petri]

I made a few changes and reordered the content to improve the flow and make the description easier to follow. The intended structure is:

• what a group is (existing content)
• why and when authors should use a group (existing content, but as you said it's hard to follow, so I've re-ordered it)
• when group elements can be nested (new)
• how group contrasts with region (existing content)
• a note clarifying which restrictions apply when group acts as an intervening role (new)

[pkra]

I don't think data-lt should include "intervening" since that term is used differently in the spec already.

[pkra]

I find this sentence difficult to follow.

[giacomo-petri]

I see your point. I've reworded the text into three separate sentences to make the reasoning easier to follow:

• sentence 1 - allowed role: an element with an intervening role is allowed as an acc child
• sentence 2 - checking its acc children: its acc children are checked against the same list as the children of the element that allows the intervening role
• sentence 3 - nesting: the rule also applies when multiple intervening roles are nested

[pkra]

This is a good example why I think "intervening role" is possibly confusing. Here, "intervening" is used in the same way it is already used in the spec.

This change also explicitly lists other roles which are permitted as intervening; that's easily confusing and hints at a bigger problem.

Changing from "parent" to "ancestor" here also suggests that the spec's terminology is lacking.

[giacomo-petri]

@pkra, I see your point about the terminology.
My intention was to make the rules explicit about which roles can occur between a required parent role and the current role, while ensuring that nested groups do not bypass the required parent role constraints.
Regarding the distinction between "parent" and "ancestor", the intent is to account for cases where the required role is not the direct accessibility parent, but an ancestor reached through one or more nested groups.
I agree that these concerns may point to a broader issue with how the spec expresses these relationships. If we are not happy with it, I believe we need to discuss alternative approaches before making further changes to the terminology or structure

[pkra]

Ditto.

[pkra]

Ditto.

[pkra]

This should move below "accessibility parent" and re-use "accessibility descendant".

[giacomo-petri]

I wasn't sure which ordering to follow originally, since the definitions were ordered both alphabetically and logically. I've now moved it below accessibility parent so the logical ordering is preserved.

I'm not sure I understand the suggestion to "re-use accessibility descendant" though, since the current definition already uses that term. Could you clarify what you had in mind?

[giacomo-petri]

@pkra, thanks for taking another look.

I find the new terminology difficult and potentially confusing.

I agree that if the new terminology makes the rules harder to understand, I need to reconsider how to explain them. However, I'd also like to put this in context, since the current specification is currently inconsistent, with the allowed-child and required-parent rules effectively contradicting each other in the case of nested groups. Is the proposed approach actually worse than the current situation, where the specification effectively says two opposite things?

It only seems to be introduced to clarify something for role group so I'm wondering why we don't clarify it there instead.

The problem is that the current rules for allowed accessibility child roles and required accessibility parent roles are inconsistent for nested groups. Before making further changes, though, I'd like to clarify the problem this PR is trying to address:

• allow nested groups in menus: structures such as menu > group > group > menuitem should be valid
• preserve the required parent role constraints: a menuitem should not become valid outside an appropriate menu or menubar context simply because it is nested within one or more group elements
• keep the allowed-child and required-parent rules consistent: the intended relationships need to be reflected in both sets of normative rules, rather than explained only in the group role description

Clarifying group in isolation would explain the intended use of the role, but would not resolve that inconsistency in the normative rules (menu, menubar, menuitem, menuitemcheckbox, menuitemradio) that authors and implementers rely on.

Perhaps we need more group-derivatives (like rowgroup). Perhaps it just boils down to the content model discussion. But I think this needs more discussion.

I agree that this deserves further discussion, particularly to determine whether the proposed mechanism is the right way to express these relationships or whether a different approach would be more appropriate. I've re-added the agenda label so we can discuss this before making further structural changes.