Menu, and menubar examples do not match descriptions

[andrewnicols]

In the following examples, the behaviour when opening the menu with the mouse is that the button that was used to open the menu retains focus:

• https://www.w3.org/TR/wai-aria-practices/examples/menubar/menubar-editor.html
• https://www.w3.org/TR/wai-aria-practices/examples/menubar/menubar-navigation.html

However, this behaviour is not noted in any of the documentation (https://www.w3.org/TR/wai-aria-practices/#menu), and in fact the description for keyboard navigation suggests that this behaviour is wrong:

When reading the following descriptions, also keep in mind that:

1. Focusable elements, which may have role menuitem, menuitemradio, or menuitemcheckbox, are referred to as items.
2. If a behavior applies to only certain types of items, e.g., menuitem elements, the specific role name is used.
3. Submenus, also known as popup menus, are elements with role menu.
4. Except where noted, menus opened from a menubutton behave the same as menus opened from a menubar.

• When a menu opens, or when a menubar receives focus, keyboard focus is placed on the first item. All items are focusable as described in § 6.6 Keyboard Navigation Inside Components.

This last point in particular suggests that whenver a menu opens, however it is opened, the keyboard focus should be placed on the first item:

• When a menu opens, or when a menubar receives focus, keyboard focus is placed on the first item. All items are focusable as described in § 6.6 Keyboard Navigation Inside Components.

[andrewnicols]

Hi folks,

We're just wondering whether you can confirm whether the examples are incorrect, or whether the spec / design pattern are incorrect so that we can ensure that we make the correct decision for our site.

Best wishes

[JAWS-test]

The description refers to keyboard navigation, whereas the behaviour you describe only occurs with mouse operation. Thus, this does not necessarily seem to be a contradiction. The requirements refer to keyboard navigation because, for example, the WCAG has various SCs that are supposed to enable efficient keyboard operation. For mouse users, focus setting is less relevant because they can use the mouse to quickly navigate to an element and activate it.

[carmacleod]

Hi, @andrewnicols. Thanks for the report!

As @JAWS-test said above, the focus behavior description you noted is in a section with heading Keyboard Interaction. Generally, the APG doesn't describe mouse behavior. (We will be including mouse, touch, html elements, and other more general aspects of accessibility as part of the APG Redesign project). The examples are behaving correctly.

However, I can see that the design pattern wording could be confusing in the case of placing keyboard focus on the first item after opening a menu in a menubar, because it doesn't specifically mention that the mouse behavior is different. I've attempted to clarify by adding a note to PR #2218. Please tell me if that clarifies things (click on the diff to see the new note).

[andrewnicols]

Thanks @carmacleod ,

Those change look good. It would be useful to understand the rationale behind the difference between a menubar and a menubutton.

[carmacleod]

It would be useful to understand the rationale behind the difference between a menubar and a menubutton.

@jnurthen @mcking65 You mentioned that menubutton wouldn't work with screen readers unless focus was placed on the first item when the menu opens. Can you be more specific about why?

For context, please see the note I'm proposing adding in PR #2218.

[corinnaSchultz]

Is there somewhere in the standards where I can learn more about the difference between "keyboard users" and "mouse users"? It's fairly common for people to mix modes of interaction (personally I mix keyboard and mouse pretty frequently), so I'm not entirely clear why there is a distinction being made regarding focus.

[JAWS-test]

@corinnaSchultz

Mouse and keyboard operation need not be different, but there are more requirements for keyboard operation from an accessibility perspective. That's why the menu example has explicit instructions for keyboard operation. It would certainly not be wrong if the focus is also set to the first menu item in the currently opened submenu for mouse operation - but this is not necessary for mouse operation as long as I can also navigate through the submenu with the keyboard after opening it with the mouse. And that is exactly what is possible in the menu example. If not, it would be a violation of WCAG SC 2.5.6

[JAWS-test]

It would be useful to understand the rationale behind the difference between a menubar and a menubutton.

The difference is only in the mouse operation. With keyboard operation, the first entry always receives the focus. With mouse operation it is as follows:

• Menu button: Focus is set to the first menu entry
• Menubar: focus remains on the main menu entry

Is the difference in mouse operation necessary? I do not think so. A different implementation would also be correct.
What could be the reason: The ARIA examples are based on the standard on the web and desktop, so they conform to expectations.