Why is a menuitem in a group special, but only on OS X?

[aleventhal]

A menuitem in a group is weird in one way. Spec says that it is exposed as an AXMenuButton instead of an AXMenuItem.
See https://www.w3.org/TR/core-aam-1.2/#details-id-45

Seems bad to me, because:

• It's confusing that there is nothing ARIA spec that mentions any special meaning or behavior of a menuitem in a group, and yet it's mapped in a special way. What's the use case, and, if it's important, why is it only a thing on OS X?
• I just discovered that Chrome gets this wrong, but no one actually ever filed an issue for it over the years.
• What happens when an author actually means to have a menu with several groups of menuitems. Will it behave differently, but only with VoiceOver? Is this only meant to be special when there is a single menuitem in the group?

I'm wondering if we should be fixing this in Chrome (and if so clarifying the specs), or, should it be removed as a thing from CORE-AAM?

[aleventhal]

@cookiecrook can you help me understand this one?

[aleventhal]

Also, a menu button sounds like it should have a drop down, which this doesn't, or does it support that but is undocumented?

[aleventhal]

Also, if we keep the rule, maybe it should only be a lone menu item in a group?

[cookiecrook]

The only guess I have is that the [contained by group | not contained by group ] distinction is a typo that should be referencing menubar versus menu instead of group versus no group. items in a menubar are typically exposed as menu buttons.

This is only a guess.

[aleventhal]

@cookiecrook, the WebKit code also remaps a role=menuitem inside of a role=group to be a menu button, in remapAriaRoleDueToParent(). Possible bug in implementations and specs?

[aleventhal]

If it helps, here is the WebKit commit where it was added, along with the author and reviewers:

commit 478547cfff0c1c4d0d1def735f9576ac60711d16
Author: alice.liu@apple.com <alice.liu@apple.com@268f45cc-cd09-0410-ab3c-d52691b4dbfc>
Date:   Fri May 23 06:44:23 2008 +0000

    2008-05-22  Alice Liu  <alice.liu@apple.com>

            Reviewed by Adele, Dan Bernstein.

            Fixed <rdar://problem/5943104> Need to implement ARIA role="menu" and related roles
            <rdar://problem/5943132> Need to implement ARIA role="menuitem"
            <rdar://problem/5943173> Need to implement ARIA role="menubar"

            These changes added a handler for determining the ARIA role when the
            attribute changes.  Before we were querying for the attribute over and
            over every time we queried for the role.
            * dom/Element.cpp:
            (WebCore::Element::attributeChanged):
            * page/AXObjectCache.cpp:
            (WebCore::AXObjectCache::handleAriaRoleChanged):
            * page/AXObjectCache.h:

Here's the code that was introduced in that commit that does it:

+    if (equalIgnoringCase(ariaRole,"menuitem")) {
+        if (parentObjectUnignored()->ariaRoleAttribute() == GroupRole)
+            return MenuButtonRole;

[aleventhal]

Here's an HTML example that shows both Chrome and Safari report "menubutton" w/ VoiceOver.

<div role="group">
  <div role="menuitem" tabindex="0">Single menu item in a group</div>
</div>

<div role="group">
  <div role="menuitem" tabindex="0">Menu item #1 in a group</div>
  <div role="menuitem" tabindex="0">Menu item #2 in a group</div>
</div>

[aleventhal]

Also, I don't see any mapping in WebKit or Chrome changing a role=menuitem inside of a role=menubar to a menu button.
Testing the ARIA practices example for menubar shows that the items are read as menuitem, not menu button:
https://w3c.github.io/aria-practices/examples/menubar/menubar-editor.html

[cookiecrook]

In the 2020-08-20 ARIA WG meeting we agreed to remove this advice from core-aam.

I've filed the related WebKit bug as https://webkit.org/b/215739

[carmacleod]

Agree that the whole "menu item owned by or child of group" entry should be removed, and the "menuitem not owned by or child of group" entry should just be for "menuitem". Reminder that some tests will need to be rewritten/removed:
https://www.w3.org/wiki/Core_AAM_1.1_Testable_Statements#menuitem_not_owned_by_or_child_of_group
https://www.w3.org/wiki/Core_AAM_1.1_Testable_Statements#menuitem_owned_by_or_child_of_group

---

I almost wonder if it was originally some kind of typo or misunderstanding in the core-aam spec that was propagated to later versions of the spec and also into Chrome.

The WAI-ARIA 1.0 User Agent Implementation Guide entry for menuitem has slightly different wording, using the word "option" for some reason (maybe copy/pasted from a special case in option role?):

If the option's parent has a group role, then role="menuitem" maps to AXMenuButton
If the option's parent has a menu role, then role="menuitem" maps to AXMenuItem

Someone from Chromium picked up on this "special case" in https://codereview.chromium.org/699083007, in which dmazzoni even said:

I don't understand the reasoning behind the spec here. It seems incomplete.

and then in a later comment:

I'm going to file a bug asking for clarification, because I still don't understand the purpose of the spec.

I don't know where core-aam bugs were reported back in 2014, so I don't know if the request for clarification was ever filed.

Later, "special case" role mappings in the core-aam spec were broken into separate tables, and the word "option" was dropped. The special case was interpreted as belonging to menuitem (which was logical because it was in the entry for menuitem).