Navigation Menubar Example: Parent items are siblings of their submenu but pattern says they should be children

[katiehockman]

From the authoring practices:
"If activating a menuitem opens a submenu, the menuitem is known as a parent menuitem. A submenu's menu element is contained in or owned by it's parent menuitem."
https://www.w3.org/TR/wai-aria-practices/#menu

Published example with error: https://www.w3.org/TR/wai-aria-practices/examples/menubar/menubar-1/menubar-1.html#
This example has a "Facts" menuitem with an attribute aria-popup='true'. This indicates it has a submenu. However, the submenu is a sibling of the "Facts" menuitem, rather than a descendant. This contradicts the suggestion in the APG.

[mcking65]

This was discussed in the February 12, 2018 task force meeting. The task force consensus is to keep the guidance, and treat this issue as a bug.

The primary reason for establishing the parent/child relationship between a parent menuitem and the submenu it opens is to provide correct reading order when exploring by touch or with a reading cursor. When the DOM structure does not provide a submenu juxtaposed to its parent in the reading order because of a parent/child relationship, the desired reading order can be provided with aria-owns because it effects the order of elements in the accessibility tree.

[katiehockman]

Sounds good. The guidance from the APG makes sense, so I agree that fixing the menubar example would be preferable.

[mcking65]

@jongund has proposed pull #707. This moves the menuitem role to the <li> elements, e.g.:

<li role="menuitem" aria-haspopup="true"><a href="#">parent menu name</a>
  <ul role="menu">
    <li role="menuitem"><a href="...">submenu item 1</a></li>
    <li role="menuitem"><a href="...">submenu item 2</a></li>
</ul>
</li>

That structure avoids a link containing links if the parent menuitem element is a link.

Pull #707 does this for all menuitems, even if they are not parent menuitems. That means that the <li> elements are focused and the links do not receive focus. One problem I see with that is that it removes the ability to access the link context menu with the keyboard.

So, I wonder, wouldn't a better structure be:

<li role="menuitem" aria-haspopup="true"><span>menu name</span>
  <ul role="menu">
    <li role="presentation"><a role="menuitem" href="...">submenu item 1</a></li>
    <li role="presentation"><a role="menuitem" href="...">submenu item 2</a></li>
</ul>
</li>

Based on discussion during today's practices teleconference, @accdc likely has a perspective on this.

[jongund]

Matt, I will make these changes. Jon

[jongund]

Matt, The only problem with your suggestion is for the links in the menubar, if you want them to act like real links. All of them have popups and therefore could not be links, since links cannot contain other links. I could use the aria-owns on them to reference the popup menus. What do you thnk? Jon

[mcking65]

@jongund, I am thinking we change the pattern just slightly.

One of our concerns is reading order. We want a submenu to follow its parent in the reading order. This is particularly important for mobile but also important for anyone who switches a screen reader to reading mode while in a menu. This is also important on MacOS VoiceOver since it doesn't really even have a separate reading mode.

At the same time, we have the problem posed by issue #159 where the parent menuitem is both a link with a target and a parent menuitem. We cannot have a link that is also a container for a submenu. As much as we want to discourage the practice of menuitems that double as parents and links, we won't get rid of it. We need to find a way of accommodating it.

Perhaps the guidance should be that:

A submenu, e.g., a menu opened by menuitem, is:

• Contained inside the same menu as the menuitem that opens it.
• is the sibling element immediately following the menuitem that opens it.

The only issue I see with this guidance is that menu is not one of the required owned elements for menu. The required owned elements include:

• group
• menuitemradio
• menuitem
• menuitemcheckbox
• menuitemradio

So, if we have a menu descending from a menu, I am not sure that is valid. It might be. However, I am not 100% certain how validators interpret the required owned elements information in the ARIA spec.

[mcking65]

@jongund, btw, probably to hold off making more changes to code till we get consensus on the approach.

[jongund]

Matt, The CSS for showing and hiding submenus is more complicated when the submenu is a sibling of the controlling menuitem. CSS has limited selectors for controlling the styling of sibling elements. Requiring the parent/child relationships meuitems and sub-menu items makes the CSS code much easier to understand and implement. Jon

[mcking65]

<li class="parent_menu_item_container"><a role="menuitem" href="..." MenuItem">parent menu name</a>
  <ul role="menu"
  ...
  </ul>
</li>

That'd give you a parent/child relationship but the menuitem and menu are siblings.

[accdc]

Hi,
Actually this is not a bug, because the ARIA menu pattern only requires that role="menu" and role="menubar" include children of role="menuitem". There is no requirement that role="menuitem" elements must have children of role="menu" or role="menubar".

The only reason that role=menuitem elements support children of role=menuitem at all, is to handle the following use case which is simplistic in the extreme, and hardly ever used in the real world.

<ul role="menu">
<li role="menuitem" tabindex="0" aria-haspopup="true">

Level One Branch

<ul role="menu">
<li role="menuitem" tabindex="-1">
Level Two Leaf
</li>
</ul>

</li>

<li role="menuitem" tabindex="-1">
Level One Leaf
</li>

</ul>

In such a construct, the only valid elements where focus can move is between the role="menuitem" elements that include a tabindex attribute, and no other focusable active elements are allowed within any of these containers of any other type of role.

As a result of these restrictions, and also to deal with historical naming computation bugs with this type of nesting structure, it is far more common to sea a menu structure like the following, which has been much more widely supported by browsers for years.

<ul role="menu">
<li>

<a href="#" role="menuitem" tabindex="0" aria-haspopup="true">
Level One Branch
</a>

<ul role="menu">
<li>
<a role="menuitem" tabindex="-1">
Level Two Leaf
</a>
</li>
</ul>

</li>

<li>
<a role="menuitem" tabindex="-1">
Level One Leaf
</a>
</li>

</ul>

All of the same rules apply here too, where it is invalid to include any other nested active elements of any other type of role, such as links, buttons, form fields, or anything else.

If you were to attempt to force all of the child menus to be children of the links with role="menu" however, the accessibility of the widget would break across all browsers and become impossible to intuitively navigate.

[mcking65]

Per discussion in June 18, 2018 meeting, the task force is changing its initial position on this issue.

The concerns of reading order expressed on February 12 are still valid. However, achieving the reading order with a parent/child relationship creates unnecessary complication in menus containing links. Consequently, to address this issue, the guidance in the pattern needs to be adjusted to suggest the sibling relationships demonstrated in the code.

The problem with menuitems that contain menus

In menus containing links, because the links need to be the focusable elements, the menuitem role needs to be on the link elements. If a parent item needs to contain or own its child menu, then that would mean that a parent item that is a link with an href either becomes a link that contains a list of links or it needs aria-owns. Structuring the menus so that links contains list of links that could also contain lists of links is an unnecessarily complex structure that may not even work. Certainly, it does not match what is already common practice and working in the wild.

Proposed revision to pattern

A submenu, e.g., a menu opened by menuitem, is:

• Contained inside the same menu as the menuitem that opens it.
• is the sibling element immediately following the menuitem that opens it.

This language matches the structure of the example, which functions as expected from the perspective of accessibility tree content.

[mcking65]

This issue is resolved as described in proposal above with commit 5eea421.