Review editor menubar example (menubar-2.html)

[mcking65]

Provide editorial and functional feedback on the
editor menubar example that demonstrates use of menuitemradio and menuitemcheckbox in submenus of a menubar.

[accdc]

The code and role usage looks good, plus the focus movement.

One note, at present the spec doesn't support the use of aria-expanded on role=menuitem, however this is an important addition that needs to be made in the spec to support touch screen devices. To this end, the following bug has been submitted:
w3c/aria#454

[mcking65]

The menu labels include the icon character for indicating the pull down:
"Style/Color ▼".
The black down pointing triangle should not be part of the label; it should not be visible to screen readers.

The edit field with the sample text needs a label.

[mcking65]

@accdc, you said focus movement is good. I am seeing two issues that are inconsistent with the design pattern. Are you experiencing these?

1. Focus is in the menubar and you press enter. The menu opens but focus does not move to the first item in the submenu that opened.
2. Focus is in a submenu and you press right arrow. Focus moves to the menubar instead of two the first item in the next or previous submenu.

[accdc]

Regarding 1, I did notice that too, however there may be a difference between what a person does when pressing Enter on a top level menubar menu item versus pressing the downarrow on it, assuming that the menubar is horizontal. It may sound non-intuitive, but pressing on a top level menubar item as implemented on the web often navigates to another landing page, whereas pressing down will open the attached submenu, so we need to figure out a way of dealing with these circumstances.

Regarding 2, personally I think it makes more sense when right is pressed and there is no submenu present to move focus to the next top level menu item in the menubar, otherwise it is difficult to know what menu is opening otherwise. I know this deviates from the Windows menubar functionality slightly by doing this, but I don't see any problem with it personally because I think it provides a more intuitive experience. Otherwise, if the user doesn't know what menu they are in, then they have to press Escape to figure out what it is, which is what happens to me on Windows all the time.

[mcking65]

@accdc

Bryan, thank you. So, we are seeing the same behavior.

The purpose of the example is to demonstrate the design pattern. So, it needs to be consistent with the pattern, and these two behaviors are not consistent.

The only examples that should deviate are additional supplementary examples that serve the purpose of demonstrating what to do in circumstances that compel an alternative approach.

For point 1 about the behavior of the enter key in the menubar, please see the last note in the design pattern keyboard section. It addresses the scenario you describe. We may want to have an example of that behavior, but not on this menubar. That would be more appropriate for the page demonstrating the navigation menubar. However, I am not sure we want to even demonstrate that ... it is not something we should promote. If we were to include it, we should first demonstrate more accessible alternative solutions to the same problem.

For point 2 about pressing left/right when focus is in a vertical menu opening from a horizontal menubar, it sounds like you are saying we should reconsider the guidance in the pattern. None of the desktop platforms behave like this menubar. However, Mac OS is similar. The difference is that the submenu associated with the newly focused item in the menubar should be expanded. Visually, I imagine it is a bit weird for it not to be. As you describe, moving focus into the parent menubar has some advantages for screen reader users. I would be fine with changing this aspect of the guidance if we emulate the Mac behavior. In reality, both work fine, and screen readers can handle either. My main point is that the example needs to be consistent with the guidance in the pattern.

[accdc]

Regarding point 1, sounds good to me if we limit this example to support both Enter plus Downarrow to invoke and set focus into the menu. I understand the dislike of the more complex dual functionality design pattern, but we should work on one of those too, simply so that we can get screen readers to properly support it in the future, a large part of this being so that screen readers only enter Forms Mode or Applications Mode when Enter is pressed on a menu while navigating in Virtual Cursor mode so that the menu item is not automatically clicked. Otherwise it is impossible to enable this functionality when needed because the onClick is always invoked on the menu item and causes a new page to load every time. This is what currently happens in both JAWS and NVDA.

Regarding point 2, I personally would prefer changing the design pattern guidance to match the functionality in this demo when Left and Right is pressed, instead of automatically expanding a submenu as it states currently. It would be good to talk about this together with all of the others during the next meating though to weigh pros and cons.

[mcking65]

Bryan, not sure you completely understood what I said on point 2.

The Mac OS menubar interaction model is just like this example except that the submenu is visually expanded while the focus moves like it does in this example. It works like:

1. Open a submenu and put focus in it.
2. Press right arrow on a submenu item that does not have its own submenu.
3. Focus moves to the next parent menu item in the menubar.
4. The submenu that previously contained focus closes.
5. The submenu of the newly focused parent menuitem opens but focus stays on the parent in the menubar.

This interaction model retains all the advantages you describe while behaving in a way that is consistent with a major desktop platform. And, I believe there are some Windows programs that behave in this way even though Windows does not.

The only part of that model that is missing from this example is step 5.

Going with this model would be a rather minor change in the pattern guidance, which itself is not binding. I am comfortable making the change if we get enough people chiming in here. I agree that it has screen reader user advantages.

It is worth noting that ARIA menubars are more friendly than native Windows menubars because we can report the expanded/collapsed state of submenus of a menubar.

With respect to how the enter key behaves in JAWS and NVDA while in reading mode, we have a larger issue related to their notion of composites. They both lack good support for the idea of moving focus to a composite element without activating an element within it. It is silly to rely on tab for that functionality. The obvious simple answer is to change what the enter key does. But, this applies to all kinds of composites from menus to trees to grids and even toolbars, which are not technically composites but usually manage focus. This topic is already on my screen reader support list.

[accdc]

Yes indeed, I understood but didn't write that very clearly. If others are in agreement too, I support changing the guidance to illustrate this updated functionality as well.

If you want to propose to the screen reader venders that Enter should activate Forms/Applications Mode to allow for the correct keyboard functionality afterwards when this is pressed in Virtual Cursor mode, which I agree is applicable to all of the interactive widget roles, I will happily jump on the bandwagon in support since we really need this sooner than later.