Navigation Menu Button: menuitem role automatically hides semantics?

[michaelwayneharris87]

There seems to be some inconsistency in the introduction to the Navigation Menu Button Example page.

The introduction states:

Another reason the menuitem role is not on the li element is that the semantics of descendants of ARIA menuitem elements are not exposed in the accessibility tree. That is, an item in a menu can only be a menuitem because accessibility APIs do not enable assistive technologies to render elements contained inside of an item in a menu. For a more detailed description of this constraint, see Roles That Automatically Hide Semantics by Making Their Descendants Presentational.

I think that is telling me that I should expected to find menuitem in the list that is linked to. However, menuitem is not in that list. (menuitemcheckbox and menuitemradio are on the list, however).

So, something isn't adding up for me. Can we add menuitem to the list of roles that make their children presentational, or change the language in the intro to the navigation menu button pattern to be less confusing?

Thanks!

[sh0ji]

Hi, @michaelwayneharris87, thanks for pointing this out at CSUN!

I agree with your assessment—menuitem should be listed in Roles That Automatically Hide Semantics by Making Their Descendants Presentational.

[jnurthen]

I disagree - menuitem can contain a child menu. This is valid, allowed and supported.

[jnurthen]

I think the prose needs to be changed rather than adding menuitem to the list of Roles that hide semantics. Similar prose could be used for treeitem which has the same issue as menuitem

[michaelwayneharris87]

Can you link to the part of the spec that says menuitem can have children? I haven't been able to find it, and the menubar examples in the ARIA authoring practices all seem to present associated menus as siblings rather than children.

Thanks so much for the help — I've had a terrible time remediating a widget based on the inconsistent docs.

[jnurthen]

Can you link to the part of the spec that says menuitem can have children? I haven't been able to find it, and the menubar examples in the ARIA authoring practices all seem to present associated menus as siblings rather than children.

Thanks so much for the help — I've had a terrible time remediating a widget based on the inconsistent docs.

Things that can't have children have children Presentational set to true. I don't think we have the inverse.

[michaelwayneharris87]

OK — I guess I wish I could better follow how it is we know that, given the discrepancy between the Navigation Menu Button example and the relevant section of the Authoring Practices, we know which one is correct. But so long as the discrepancy can be resolved, that would be really helpful.

[jnurthen]

I agree that text is confusing. It needs fixing. The below is not elegant text and needs wordsmithing but something like the following is what I believe it needs to say.

Another reason the menuitem role is not on the li element is that the semantics of descendants of ARIA menuitem elements are not exposed in the accessibility tree, except for when the menuitem contains a child menu. That is, an item in a menu can only be a menuitem because accessibility APIs do not enable assistive technologies to render elements contained inside of an item in a menu. This is similar to Roles That Automatically Hide Semantics by Making Their Descendants Presentational, except for the fact that menuItems can own sub menus.

[LaurenceRLewis]

“Another reason the menuitem role is not on the li element is that the semantics of descendants of ARIA menuitem elements are not exposed in the accessibility tree, except for when the menuitem contains a child menu. That is, an item in a menu can only be a menuitem because accessibility APIs do not enable assistive technologies to render elements contained inside of an item in a menu. This is similar to Roles That Automatically Hide Semantics by Making Their Descendants Presentational, except for the fact that menuItems can own sub menus.”

Why can't it just read 'This role must not include any embedded active elements besides those with role=menu, role=menubar, role=menuitem, role=menuitemcheckbox, or role=menuitemradio.'

[carmacleod]

@jnurthen Do you have an example somewhere that has menus as children of menuitems? I've only tested screen readers on the menuitem+menu sibling structure, but maybe they work both ways?

The spec does refer to "child menus", but maybe that just means "the associated submenu"?

The APG Menu or Menubar section says:

If activating a menuitem opens a submenu, the menuitem is known as a parent menuitem. A submenu's menu element is:

• Contained inside the same menu element as its parent menuitem.
• Is the sibling element immediately following its parent menuitem.

[jnurthen]

No I can't - but the current advice to add a sibling element leads to incorrect information being exposed in the accessibility APIs today. See the screenshot below. The submenu is open and the top menu shows a child count of 6 items rather than the correct count of 5. Now in practice this generally isn't an issue as focus is in the submenu at the time so the fact that the number of items in the parent menu is off by 1 is not normally a real problem for users. I'd love to see an example which does this properly (like platform APIs expect) and adds the menu as a child of the menuitem.

[carmacleod]

I guess the screen readers are only counting the menuitem children - I just tried our (sibling markup) menubar (has several submenus) with JAWS/NVDA in both FF/Chrome and the spoken counts are correct.

[carmacleod]

The ARIA in HTML entry for menuitem notes the following in the "Descendant Restrictions" column:

Flow content, but with no interactive content descendants.

Looks like this was discussed before, in APG issue https://github.com/w3c/aria-practices/issues/592.