Add aria-orientation to menu design pattern states and properties section

[StommePoes]

On the page with the menu https://www.w3.org/TR/wai-aria-practices-1.1/#menu both the slider and the listbox are careful to state the default setting of aria-orientation is horizontal, however when I was reading #menu I saw

When items in a menubar are arranged vertically and items in menu containers are arranged horizontally:
Down Arrow performs as Right Arrow is described above, and vice versa.
Up Arrow performs as Left Arrow is described above, and vice versa.

I thought "how does a user know the thing is vertical?" and think the statements repeated in #slider and #listbox should be added to #menu section.

(update feedback from #13 (comment))

[mcking65]

@StommePoes Thank you for catching this! I'll fix it.

[mcking65]

@StommePoes,

A proposed fix can be viewed in a branch on rawgit at:
https://rawgit.com/w3c/aria-practices/menu-issues-215-261/aria-practices.html#menu

It includes the text:

• If a menubar is vertically oriented, it has aria-orientation set to vertical. The default value of aria-orientation for a menubar is horizontal.
• If a menu is horizontally oriented, it has aria-orientation set to horizontal. The default value of aria-orientation for a menu is vertical.

[mcking65]

@annabbott and @jnurthen, please review this fix.

[StommePoes]

The second sentence confuses the heck out of me. "If a menu is horizontally oriented, it has aria-orientation set to horizontal. The default value of aria-orientation for a menu is vertical."

I thought the default, for all menus, was horizontal. And that therefore, as a developer, if I want to visually make it vertical and use the recommended keystrokes for vertical menus, that I must set aria-orientation="vertical" on my menu... otherwise, for my horizontal menus, I don't have to set aria-orientation at all.

I was under the impression that both menus and menubars were both horizontal. Is that where I'm getting it wrong?

[mcking65]

@StommePoes wrote:

I thought the default, for all menus, was horizontal. And that therefore, as a developer, if I want to visually make it vertical and use the recommended keystrokes for vertical menus, that I must set aria-orientation="vertical" on my menu... otherwise, for my horizontal menus, I don't have to set aria-orientation at all.

Nop ... life is simpler than that. Menus, which are most often vertical, have default orientation of vertical. In contrast, menubars, which are most often horizontal, have a default orientation of horizontal. So, it is rare that you need to specify aria-orientation on a menu.

[StommePoes]

Wait... so the File button on my browser, and all the stuff under it, would be considered a single (vertical) menu within a menubar?

[mcking65]

@StommePoes asks:

Wait... so the File button on my browser, and all the stuff under it, would be considered a single (vertical) menu within a menubar?

Not sure about your browser, but consider Firefox.

Firefox has a horizontal menubar containing menuitems labeled file, edit, view, history, bookmarks, tools, and help.

If you were implementing that on the web, because that horizontal menu is visually persistent, you would put them in a div with role menubar, which, by default has orientation of horizontal.

Further, the menuitem labeled file would contain a div with role menu. That div would have the menuitems for open, etc. That menu is vertical, and the default orientation of menu is vertical.

Does that help?

[annabbott]

I'm struggling with Issue 261:
The APG is combining menu role and menubar role and obviously, due to the feedback, is not clear.
The APG also has a section for 'menu button', however no such role exists in the ARIA 1.1 spec.

I've tried to sort through the menu and menubar description and have come up with this in an attempt to clarify:

The menu role is a simple widget that offers a list of common actions or functions which the user can invoke. Elements with the role menu have an implicit aria-orientation value of vertical.

The menubar role is a complex widget used to create a consistent set of frequently used commands, usually remains visible and is usually presented horizontally, similar to those found in Windows, Mac, and Gnome desktop applications. Elements with the role menubar have an implicit aria-orientation value of horizontal.

As far as 'menu button' is concerned, I think we need to remove it from the APG as no such role exists - a widget can have either a role="menu" or a role="button" but not both (only one role may be applied to any element).

[mcking65]

@annabbott,

Here's a couple things to consider WRT your suggestion.

First, the APG design patterns do not have a 1:1 relationship to ARIA roles. For example, ARIA does not include roles for accordion, breadcrumb, or non-modal dialog. Similarly, the tabs pattern incorporates three roles, one of which is tab. And, the grid pattern incorporates 6 roles, only one of which is grid.

Secondly, very importantly, ARIA roles do not have a 1:1 mapping to platform accessibility API roles. All the accessibility APIs have a system role for menubutton. Instead of having a menubutton role, back in the ARIA 1.0 days, the working group decided to map a button that has aria-haspopup to the menubutton role at the system level. This approach was intended to help prevent role proliferation. One could argue that it didn’t achieve that but did create more opportunities for confusion and mistakes. In general, I have not been a proponent of having attributes modify the role mapping.

So, a menubutton is indeed a real widget that is different from a button at the system level.

The practices task force has previously, a long way back, discussed separating menubar from menu. However, a menubar is actually a menu. And, a menu never exists without either a menubuttton or a menubar to expose it. So, we left it how it is.

Finally, the widget desscriptions do not belong in the list of states and properties. Such descriptions are at the beginning of the design pattern. So, if we need more clarification about the nature of the widget, I would want to put it there.

[jnurthen]

I normally like short - but due to the confusion perhaps we need a few more words here. How about.

Most menubars are horizontally oriented so aria-orientation does not need to be set because its default value for a menubar is horizontal. In the rare case that a menubar is vertically oriented then set aria-orientation to vertical.

Most menus are vertically oriented so aria-orientation does not need to be set because its default value for a menu is vertical. In the rare case that a menu is horizontally oriented then set aria-orientation to horizontal.

[StommePoes]

using a browser menubar/menus helps make it clear. Wonder if it makes sense to put in the docs-- in human language, the thing ARIA is calling a "menubar" we call a "menu" and the vertical parts that open are called "submenus" so having an example stating the menu is really a "menubar" and the submenus are considered individual "menus" should clear that up immensely.

[mcking65]

Because of the discussion here, I have opened issue #287.

The goal of this issue is to fix the aria-orientation omission in the menu design pattern, which is done.

I am going to merge the changes and use them as the basis for further improvement when I get to issue #287.

Thank you everyone for the insightful feedback! This thoughtful scrutiny is going to make the APG an immensely useful resource.

[mcking65]

Changes merged. Note that the title of commit cbe304b has a typo; it says it is for issues 215 and 266 but should say it is for issues 215 and 261. Sorry about that.