Fix a menuitem labeling omission in the menu pattern

[mcking65]

NOTE: This was later pointed out to be incorrect and reversed in issue #395.

If a menuitem element contains or owns a child menu and its menuitems, then the menuitem needs either aria-label or aria-labelledby similar to what is described for treeitems. This is not covered in the roles, states, and properties section of the menu design pattern.

The editor menubar example demonstrates this situation.

[mcking65]

Proposed fix for this issue can be seen in a branch in rawgit at:

Changes include:

• Added statement: "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."
• Added statement: "A parent menuitem has either aria-label or aria-labelledby set to specify a label. Warning: parent menuitems missing a label are labeled by all child elements, causing screen readers to announce every child menuitem and often making a menu so verbose that it is unusable."
• Simplified statement to use parent menuitem terminology: "A parent menuitem has aria-haspopup set to true."

[mcking65]

@annabbott, @jnurthen,

Please review the proposed fix for this issue, which can be seen in a branch in rawgit at:
https://rawgit.com/w3c/aria-practices/menu-issues-215-261/aria-practices.html#menu

Changes include:

• Added statement: "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."
• Added statement: "A parent menuitem has either aria-label or aria-labelledby set to specify a label. Warning: parent menuitems missing a label are labeled by all child elements, causing screen readers to announce every child menuitem and often making a menu so verbose that it is unusable."
• Simplified statement to use parent menuitem terminology: "A parent menuitem has aria-haspopup set to true."

[annabbott]

See my comment in #261.

Under Keyboard interaction > Down arrow > as last bullet:
When focus is in a menubar, does nothing.

Under Keyboard interaction > Escape
Escape: Close the menu that contains focus and return focus to the element or context, e.g., menu button or parent menuitem, from which the menu was opened.
Suggest removing reference to 'menu button' and replace with 'menu'.

[mcking65]

Ann, for this fix I didn't change the keyboard subsection. I changed only the above mentioned bullets in the states and properties.

Nonetheless, to address your specific concern ...

@annabbott wrote:

Under Keyboard interaction > Down arrow > as last bullet:
When focus is in a menubar, does nothing.
Under Keyboard interaction > Escape
Escape: Close the menu that contains focus and return focus to the element or context, e.g., menu button or parent menuitem, from which the menu was opened.
Suggest removing reference to 'menu button' and replace with 'menu'.

We don't want to say to return focus to a menu. A menu does not receive focus. If it ever receives DOM focus, then it needs to be using aria-activedescendant to place AX focus on a menuitem.

There are two ways of opening an ARIA menu:

1. Open it by activating a menuitem.
2. open it by activating a menubutton.

Note that a menuitem must be in either a menubar or a parent menu.

[annabbott]

ok

[jnurthen]

Modify the 2nd change to the following:
If a parent menu has descendent items in the DOM then set a label on the parent using aria-label or aria-labelledby. Parent menuitems with descendent menuitems missing a label are labeled by all child elements, causing screen readers to announce every child menuitem and often making a menu so verbose that it is unusable. If using aria-owns this is not necessary.

[mcking65]

@jnurthen, good catch about aria-owns. I didn't realize the name calculation treated owned elements differently from contained elements when naming from content. You're 100% sure on this? I wonder if the browser tests for name calculation test for this.

[jnurthen]

I have always thought this was the way it was but we should probably do a little test case to check. I won't be able to do it this weekend though. aria-owns is not mentioned at all in the accessible name calculation. All the definitions of nodes in the accessible name calculation are DOM nodes, so my assumption is that child nodes means child DOM nodes - but it could do with being clarified.

…

On Sat, 4 Feb 2017 at 07:24 Matt King ***@***.***> wrote: @jnurthen <https://github.com/jnurthen>, good catch about aria-owns. I didn't realize the name calculation treated owned elements differently from contained elements when naming from content. You're 100% sure on this? I wonder if the browser tests for name calculation test for this. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#215 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABpQP4Up2R-BvB3Cj47QtMcFIlUhOVqCks5rZJgYgaJpZM4LLDSA> .

[mcking65]

This issue depends on issue #277.

[mcking65]

I am going to merge these changes and close this issue. If the outcome of issue #277 calls for more changes, thenI will make them at that time.

[mcking65]

Changes merged. Note that I made an error in the title of commit cbe304b. It says it is for issues 2155 and 266. It should say it is for issues 215 and 261. Sorry about that.