Review navigation menubar example revisions made through June 2017

[mcking65]

The navigation menubar example has been significantly revised to correct errors and rephrase for editorial consistency. It is ready for additional review.

Open issues

• Issue #408: Make mouse behaviors and parent menu item appearance change triggers more consistent with desktop conventions
• Issue #447: Add note addressing validation errors resulting from aria-expanded on menuitem elements to Menu and Menubar patterns and examples

Reviews requested as of June 20, 2017

• [x] Review by @a11ydoer
• [x] Review by @shirsha
• [x] Review by @jnurthen

[sideshowbarker]

This example is in violation of the current ARIA spec, because the ARIA spec doesn’t actually allow the aria-expanded state with role=menuitem. https://github.com/w3c/aria/issues/454 is a related ARIA spec issue. And note that this discrepancy is causing some confusion among web developers/authors, as evidenced by the following recent questions at StackOverflow:

• https://stackoverflow.com/questions/43015485/attribute-aria-expanded-not-allowed-on-element-li-at-this-point/43019557#43019557
• https://stackoverflow.com/questions/44990967/about-use-aria-expanded-on-role-menuitem/44991285#44991285

The questioners there wonder why the W3C HTML Checker reports an error for aria-expanded with role=menuitem when this guide and other W3C materials show examples that use it.

And the answer to that is, as long as the spec prohibits it and the checker claims to conform to the spec, I don’t really have any choice other than to have the HTML Checker report an error for it.

---

(Incidentally, this makes me wonder whether anybody is taking responsibility for auditing the examples in the WAI-ARIA Authoring Practices guide to ensure they actually conform to the requirements in the ARIA spec and ARIA in HTML spec. It’s obviously not a good thing when we’re confusing authors and web developers by providing examples to the community that aren’t actually conforming with spec requirements and that cause the W3C HTML Checker to report errors.)

[ZoeBijl]

For what it’s worth, APG has a code conformance section on GitHub that states All HTML should validate in the NU HTML Validator. Exceptions to this rule are warnings and errors related to future ARIA features we need to implement.

Perhaps we should add a note to that effect on the example page.

[LaurenceRLewis]

So if we want to expose the expanded status for AT users we need to use aria-expanded with role=menuitem even though this is currently invalid according to the spec.
Error: Attribute aria-expanded not allowed on element a at this point. "Exceptions to this rule are warnings and errors related to future ARIA features we need to implement." Meaning we can ignore the validation as this may be allowed sometime in the future when an ARIA feature is implemented. Makes the validation process redundant if this is the case. The fun of trying to follow the rules :-)

[DavidMacDonald]

Example 1 has a dropdown with an additional sub flyout menu. This requires a right arrow or enter key to activate. Should this not be provided in instructions? On Voice over they are not provided.

[mcking65]

@DavidMacDonald commented:

Example 1 has a dropdown with an additional sub flyout menu. This requires a right arrow or enter key to activate. Should this not be provided in instructions? On Voice over they are not provided.

That is a VoiceOver design issue/decision. Currently in native menus, VO does not give instructions for parent menuitems. However, VO does announce the presence of the submenu, which it does not yet do for ARIA parent menuitems. That is a VoiceOver bug.

[devarshipant]

• aria-expanded on Facts and Campus Tours menu items fails to update the states (from false to true) on opening the fly outs.

• Upon receiving focus, note the tabindex = -1 on the two menu items.

[OlivierNourry]

Below, marked as code, is the value of the aria-label attribute for the UL just after "Facts", as seen with the Node Inspector in Safari for Mac (but same result with other browsers and inspectors):

aria-label  
              <li role="none">
                <a role="menuitem" href="mb-about.html#overview" tabindex="-1">Overview</a>
              </li>
              <li role="none">
                <a role="menuitem" href="mb-about.html#admin" tabindex="-1">Administration</a>
              </li>
              <li role="none">
                <a id="menubar113" role="menuitem" href="#" aria-haspopup="true" aria-expanded="false" tabindex="-1">Facts</a>
                <ul role="menu" tabindex="-1">
                  <li role="none">
                    <a role="menuitem" href="mb-about.html#facts">History</a>
                  </li>
                  <li role="none">
                    <a role="menuitem" href="mb-about.html#facts">Current Statistics</a>
                  </li>
                  <li role="none">
                    <a role="menuitem" href="mb-about.html#facts">Awards</a>
                </li></ul>
              </li>
              <li>
                <a role="menuitem" href="#" aria-haspopup="true" aria-expanded="false">Campus
                  Tours</a>
                <ul role="menu">
                  <li role="none">
                    <a role="menuitem" href="mb-about.html#tours">For prospective students</a>
                  </li>
                  <li role="none">
                    <a role="menuitem" href="mb-about.html#tours">For alumni</a>
                  </li>
                  <li role="none">
                    <a role="menuitem" href="mb-about.html#tours">For visitors</a>
                </li></ul>
              </li>

Obviously there are some closing tags missing somewhere. Same goes for "Campus Tours".

Also (related?): keyboard navigation is broken when VO is on. Test steps:

• Place cursor on menu bar
• circulate in menu with down key (or CTRL+OPTION+down key)

Result: once the cursor is on "Facts", it jumps back to "About". Similar behavior with right key, except it opens the submenu under "Facts", but then jumps back to "About" too.

[WillsB3]

Hi,

I've been looking at this example and trying to understand how a user with assistive technology would interact with it. I'm using VoiceOver on MacOS 10.12.6 for my testing.

When I interact with a menu item (e.g. "Admissions") by pressing "Control Option Space" as instructed by VoiceOver the menu item does not expand and focus does not move. Shouldn't the menu item expand and then allow me to navigate the child items within?

I'm a developer and not that experienced with using Assistive Tech but have a basic knowledge of how to use VoiceOver.

[mcking65]

@OlivierNourry commented:

Obviously there are some closing tags missing somewhere. Same goes for "Campus Tours".

Hmm, not so obvious to me. When I inspect with screen readers, on both MacOS and Win, the label is getting calculated correctly. When I validate the document, there are not any missing closing tags.

@jnurthen or @jongund, can you "see" this. The way that JAWS and VO read the DOM tree to me in the dev tools, I don't notice the issue.

Also (related?): keyboard navigation is broken when VO is on. Test steps:

• Place cursor on menu bar
• circulate in menu with down key (or CTRL+OPTION+down key)

Result: once the cursor is on "Facts", it jumps back to "About". Similar behavior with right key, except it opens the submenu under "Facts", but then jumps back to "About" too.

First, it is important to understand that:

1. If quicknav is on, left/right work like ctrl-opt-left/right. They are not captured by the JS in that case.
2. Similarly, ctrl-opt-up/down are VO commands. They move the VO reading cursor; they are not captured by the JS.
3. ctrl-opt-ArrowKey commands and optionally have the capability to move focus, depending on the state of cursor tracking (shift-ctrl-opt-f3).
4. In Chrome, the VO commands for ctrl-opt-up/down do not work. I think this is VO's less robust support for Chrome (not sure about that).

So, do not expect similar behaviors for ctrl-opt-up/down and up/down; they are quite different.

When using up/down and quicknav is off, which is the best way in Chrome, there is wrapping from first to last and last to first items in these menus. That is optional behavior. And, when using left/right, the menus work exactly the same way your system menubar does on the Mac.

VO provides much richer support for ARIA menus in Safari. It actually provides the same kind of support it does for system menus. So, for example, when you activate a menu, it gives you the cool popup sound. And ctrl-opt-up/down work inside the menus. Keep in mind, though, since those are VO commands, that navigation stops at the edge of the container.

When using VO, ctrl-opt-space simulates a mouse click, not a key press. To open a menu, you can use enter or the appropriate arrow key, and that works. In Safari, ctrl-opt-space works in the menubar, but mysteriously does not work on the "Facts" submenu. In Chrome, ctrl-opt-space does not work.

I do see that using the mouse with VO sometimes doesn't quite work right for the submenus. This is a clue to the issue with ctrl-opt-space on the "Facts" menu. If you:

1. Use quicknav to move the reading cursor to "Overview"
2. Use ctrl-opt-cmd-F5 to place the mouse there. (the menu opens)
3. Use quick nav to move to "Facts"
4. Use ctrl-opt-cmd-F5 to move the mouse to "Facts", double check with ctrl-opt-F5.
5. Use ctrl-opt-shift-F5 to click "Facts" and what happens at this point seems unpredictable. Sometimes, focus jumps to "overview".

I expect step 5 5to open the Facts submenu just like I assume it does if you are capable of using a real mouse. The fact that it does not indicates a possible Safari or VO bug.

Oh, I am using MacOS 10.12.6.

HTH.

[mcking65]

@WillsB3 commented:

I've been looking at this example and trying to understand how a user with assistive technology would interact with it. I'm using VoiceOver on MacOS 10.12.6 for my testing.

When I interact with a menu item (e.g. "Admissions") by pressing "Control Option Space" as instructed by VoiceOver the menu item does not expand and focus does not move. Shouldn't the menu item expand and then allow me to navigate the child items within?

I'm a developer and not that experienced with using Assistive Tech but have a basic knowledge of how to use VoiceOver.

It should, yes. And, it does in Safari, in the main menubar. But does not seem to do so for secondary submenus, e.g., "Facts". Oddly, it does not work that way in Chrome. I believe that is a VoiceOver bug.

However, all the VO commands that start with ctrl-opt-SomeKey are more like using a mouse than using the keyboard. They do, generally, also move the focus, so it is sort of an odd blend. Once you have focus inside of an ARIA widget, it is usually best to have quicknav off (press left and right arrows at the same time to toggle). Then, when quicknav is off, the letter and arrow keys will be available to the web application instead of being slurped up by VoiceOver.

We will someday add an appendix about screnen reader reading modes. And, after we do, it might be a good idea to add a link to it from all the example pages.

[OlivierNourry]

@mcking65 Thanks for the detailed answer, Matt. Forgot to mention that I'm on MacOX 10.12.6 as well, and that my initial testing was with Safari.

You wrote:

Hmm, not so obvious to me. When I inspect with screen readers, on both MacOS and Win, the label is getting calculated correctly. When I validate the document, there are not any missing closing tags.

I do confirm my observation. Checked with the Accessibility Inspector in XCode, not on the UL element itself because it can't be targeted directly, but through one of the child items. The value in the Parent parameter is akin to what I pasted in my initial post. Actually VO with Safari doesn't tell me anything that is in the aria-label (I changed its value in the source code to be sure, and it had no perceivable effect). Oddly when it first reads the menu, it announces 3 elements, but after going through it and back again, from that point forward it says there are 4 elements in both submenus, whereas there are only 3. But I can't tell if it's a VO glitch or a consequence of the code. Just to be sure I tested with Chrome (it didn't occur to me as I presumed that Chrome and VO were not a good match). And there VO indeed says what the Accessibility Inspector tells me there is.

Regarding the keyboard interaction -- ah well, I had quick nav activated, wasn't aware of it. With quick nav off, it works as intended, with the slight difference that the submenus are open on focus, not upon activation with the Right Arrow key. No biggie, though. What is more disturbing is that one should not follow VO's help instructions, when on an expandable menu item. Shift+ VO key + Down doesn't allow interaction with the element, but sets focus on the little arrow, placed next to the link text to indicate the expandable nature of the item. Which is really odd since it's displayed through the use of the ::after pseudo-selector. Go figure. Once you have done this, you are in a cul-de-sac, your only option is to exit the element, and use the arrow keys with no modifier. I hope this is clear enough for you or anyone interested. This example feels very messy, and certainly deserves a little love...

[mcking65]

@OlivierNourry commented:

Checked with the Accessibility Inspector in XCode, not on the UL element itself because it can't be targeted directly, but through one of the child items. The value in the Parent parameter is akin to what I pasted in my initial post.

I am not familiar with Mac inspection tools, but this hints at a possible bug in the tools because VO is picking up the correct label.

Actually VO with Safari doesn't tell me anything that is in the aria-label (I changed its value in the source code to be sure, and it had no perceivable effect).

Yes, it does. Put focus on "History" in the "Facts" submenu. Then, disable cursor tracking with ctrl-opt-shift-F3 and use ctrl-opt-left. You will hear VO tell you the name of the menu and the number of items in it. It doesn't announce this info dynamically while reading. That is a VO design decision, not a problem with the menu.

Oddly when it first reads the menu, it announces 3 elements, but after going through it and back again, from that point forward it says there are 4 elements in both submenus, whereas there are only 3. But I can't tell if it's a VO glitch or a consequence of the code.

I would dnot be surprised if Safari is behind that problem. Posinset and setsize attribs are calculated dynamically by the browser.

Regarding the keyboard interaction -- ah well, I had quick nav activated, wasn't aware of it. With quick nav off, it works as intended, with the slight difference that the submenus are open on focus, not upon activation with the Right Arrow key.

Displayed, not activated on focus. That is by design; it is to be like desktop menus.

What is more disturbing is that one should not follow VO's help instructions, when on an expandable menu item. Shift+ VO key + Down doesn't allow interaction with the element, but sets focus on the little arrow, placed next to the link text to indicate the expandable nature of the item. Which is really odd since it's displayed through the use of the  ::after  pseudo-selector. Go figure. Once you have done this, you are in a cul-de-sac, your only option is to exit the element, and use the arrow keys with no modifier.

Yes, VO is buggy here. The support for web-based menus in VO is not yet nearly as robust as for the desktop. And, that is part of the point of examples like this. Our goal is to help the browser and screen reader devs work all this stuff out so we can have fabulous experiences for AT users when they are using web-based GUIs.

That does mean, though, that the example itself really does have to be correct. Unless I am missing something, so far, none of this seems to point to a problem with the example code.

This example feels very messy, and certainly deserves a little love...

As a VO user, I generally feel like it works quite well, especially in Safari. Although, you have pointed out that there is a lot of room for improvement in VO behavior, and possibly in Safari as well.

We do have several outstanding issues related to the menu examples, most notably related to mouse behavior. You can see everything open related to the menu examples in the menu and menubar project.

[OlivierNourry]

@mcking65 thanks again for the thorough answer, I certainly learned a few things in the process! That said, I wonder if we are talking about the same page. On https://www.w3.org/TR/wai-aria-practices-1.1/examples/menubar/menubar-1/menubar-1.html I did as you instructed, with VO in Safari, and it does indeed say:

menu li role="none" a role="menuitem" href="mb-about.html#overview" tabindex="-1"...

I spare you the whole content, it's actually the inner HTML content of the UL that is the container of the sub menu. Which is absolutely consistent with what it says with Chrome, and what is found out by the code inspectors in the 3 major browsers, plus the accessibility inspector in XCode. They can't all be wrong, can they? I identified where this happens, although I couldn't fix it: in the PopupMenuItemLinks.js file, there's the PopupMenu.prototype.init method that assigns its aria-label to the popup menus. It's done by fetching the innerHTML of the link that serves as the opener of the submenu. Works well for the first level menus (About, Admissions, Academics), but somehow, for the second level submenus (under "Facts" and "Campus tours"), it takes the inner HTML of the UL below, instead of the A element. Couldn't pinpoint exactly why, but that is made obvious by outputting the value of this.controller.domNode.innerHTML that is affected to label into the console. Possibly @jnurthen or @jongund could find out why? As a final note, know that I do appreciate the efforts of the W3C to provide useful resources to the community, and your own for trying to sort this out with me. I hope this helps!

[mcking65]

@OlivierNourry commented:

I wonder if we are talking about the same page. On https://www.w3.org/TR/wai-aria-practices-1.1/examples/menubar/menubar-1/menubar-1.html

Well, that could be part of the problem. There are quite a few updates since we last published to w3.org.

I have been refering to the editor's draft on github.io: http://w3c.github.io/aria-practices/examples/menubar/menubar-1/menubar-1.html

Have a look at that and see if it helps.

[OlivierNourry]

@mcking65 all right, mystery solved! Note that I came to this issue starting from the pages at w3.org, following the link provided in the example page. So I could only assume this is what we were talking about all along. From an external point of view it's hard to understand why that example page, with known (and fixed) bugs, is still referenced from the public TR. I'm not familiar with W3C's publication constraints, but there's certainly room for improvement here. Although I enjoyed our conversation, you and I would have probably preferred spending less time on this...

[shirsha]

I have tested this with keyboard only in FF and IE. In FF, it is acting differently based on how I interact with the menu items. Step#1:

When you are on the last item(Academics) in the menubar , navigate to the submenus using down arrow. Now using "right arrow" go to the previous menu item in the menu bar. Now it automatically opens the child submenus when user navigates(left and right arrows) between the menuitems in the menu bar (Which didn't happen initially). The submenus are not closed even when the user tabs to next focusable item in the page.

Same thing is happening in IE browser.

[mcking65]

@shirsha commented:

I have tested this with keyboard only in FF and IE. In FF, it is acting differently based on how I interact with the menu items.

When you are on the last item(Academics) in the menubar , navigate to the submenus using down arrow. Now using "right arrow" go to the previous menu item in the menu bar. Now it automatically opens the child submenus when user navigates(left and right arrows) between the menuitems in the menu bar (Which didn't happen initially). The submenus are not closed even when the user tabs to next focusable item in the page.

Siri, thank you for finding this!

This was another form of issue #346 that @jongund has now fixed with commit 2549421.

[michaelwayneharris87]

I'm a little confused that the top level menu items are tags with an href.

With a mouse click, it seems the link is being followed (it's a named anchor to the top of the page, but replacing the href attribute to an external link also seems to work).

But, it doesn't seem possible to follow that link directly with wither VoiceOver or with Keyboard Only. This seems bad — if the top level page has important information that can't be accessed by a keyboard user or VoiceOver, those users are left unable to navigate to those pages.

I haven't seen this mentioned in the preceding conversation (though I could have just missed it), and my developers / designers have been disagreeing about its merits. I find myself recommending against navigation menu widgets altogether because I can't provide a good answer to whether the top menu item should also operate differently on mouse click than on pressing Enter. Any thoughts would be appreciated.

@michaelwayneharris87 commented:

I'm a little confused that the top level menu items are tags with an href.

The "About", "Admissions", and "Academics" menu items have href="#". There only purpose is to provide access to the drop downs. Given your question, I think this example would be better if those were button elements.

@michaelwayneharris87 commented:

With a mouse click, it seems the link is being followed (it's a named anchor to the top of the page, but replacing the href attribute to an external link also seems to work).

Having a link in a menu that both has a target URI and provides access to a submenu is a common pattern. But, it is not one that we recommend. There are a significant number of people that argue that it is not possible to consider that pattern accessible regardless of how you code it. This guide does not go that far. At least for now, we still have a plan to provide an example like that (issue #159).

@michaelwayneharris87 commented:

But, it doesn't seem possible to follow that link directly with wither VoiceOver or with Keyboard Only. This seems bad — if the top level page has important information that can't be accessed by a keyboard user or VoiceOver, those users are left unable to navigate to those pages.

Note 4 in the keyboard subsection of the menubar design pattern reads:

4. Although it is recommended that authors avoid doing so, some implementations of navigation menubars may have menuitem elements that both perform a function and open a submenu. In such implementations, enter and Space perform a navigation function, e.g., load new content, while Down Arrow, in a horizontal menubar, opens the submenu associated with that same menuitem.

So, one way to make parent items that also have an href work is for space and enter to follow the URI in the href and for down arrow to provide access to the items in the dropdown. The main challenge is communicating that to users. This is somethig we still need to work on resolving.

@michaelwayneharris87 commented:

my developers / designers have been disagreeing about its merits. I find myself recommending against navigation menu widgets altogether because I can't provide a good answer to whether the top menu item should also operate differently on mouse click than on pressing Enter.

For now, I would recommend not overloading parent menu items with both link and parent menu item behaviors. I hope your designers could learn to live with that. That constraint can increase clarity for all users, not just those who do not use a mouse.

For example, on a clothing site, if you had a page about all pants, and sub pages for jeans, dress, etc. You could have a parent menu item for pants and the first item in the submenu could be "All Pants" or something like that. It is one extra click for some people, but more clarity for all people.

Hope this helps.

[michaelwayneharris87]

Wow. Thanks!

[a11ydoer]

@mcking65 It took me a while to go through all the comments. In particular, I loved to see the note about the validation error within the example. I have read through the example page and checked keyboard navigation info as well as coding structure. All looked correct for me. I cannot wait to see this example to be part of the spec soon since we have been working on this example for a while.

[scottaohara]

Hey there,

I'm wondering what consideration is being made to the issue that Adrian Roselli filed pertaining to this pattern.

The reason I ask is that I had an instance recently where someone I was working with specifically pointed to this pattern as to the reason why they wanted menu and menuitems included on the elements of a website's primary navigation.

My response to them was that by overwriting the semantics of their <nav> element (they had proposed <nav role="menu">), and their links with menuitem, they would negate the landmark and link semantics from being picked up by ATs. So if a user were to review the landmarks or links of the site in question, there would be no navigation to be found, nor would the links to the primary pages of the site listed. Additionally, the normal expectation of being able to tab through the navigation's links would not be met.

My response was politely considered a differing opinion due to it being in contrast to the "official ARIA practices" example.

I can completely understand the need for a pattern like this, in recreating application-like menus, but as I also noted in Adrian's issue, I worry about promoting the use of menu as a "navigation pattern."

Thank you

[mcking65]

scottaohara commented:

I'm wondering what consideration is being made to the issue that Adrian Roselli filed pertaining to this pattern.

We are planning to address that issue fully in release 2 of the guide. Release 1, that will be published before the end of the year does not directly resolve it.

The reason I ask is that I had an instance recently where someone I was working with specifically pointed to this pattern as to the reason why they wanted menu and menuitems included on the elements of a website's primary navigation.

That could be good if they follow the pattern accurately and bad if they only cherry pick things like the roles.

My response to them was that by overwriting the semantics of their <nav> element (they had proposed <nav role="menu">),

That is most definitely bad. Makes me think that we should wrap a <nav> around our navigation menubar, which would be appropriate.

and their links with menuitem, they would negate the landmark and link semantics from being picked up by ATs.

Yes, that is correct. The landmark part is the bad part of that. The link part is not necessarily a problem, depending on the design of the site and the context of the navigation.

So if a user were to review the landmarks or links of the site in question, there would be no navigation to be found, nor would the links to the primary pages of the site listed.

Right. And, if the design of the site does not provide ways of discovering the navigation easily, this could present a major usability challenge for some people, especially some screen reader users.

Additionally, the normal expectation of being able to tab through the navigation's links would not be met.

It is normal to tab to links, but it is not normal to tab through menus in a GUI. So, if a site has a flat list of links that is not terribly long, then tabbing is reasonable, if not ideal. if there is a hierarchical nav system that works like a GUI, it would be bad to force people to tab through all that. One of the beautiful things about bringing accessible GUIs to the web is that you can make keyboard navigation much, much more user friendly.

I can completely understand the need for a pattern like this, in recreating application-like menus, but as I also noted in Adrian's issue, I worry about promoting the use of menu as a "navigation pattern."

A menubar can be an excellent navigation pattern when done well. I think one of the problems is that the keyboard user who is sighted is a second class citizen in today's designs. No, I take that back; they have been second class citizens ever since the dawn of GUIs that are optimized for direct manipulation.

Mouse users get all kinds of fancy, built-in clues to available affordances. For instance, the mouse pointer changes shape to indicate possible operations. Keyboard users, on the other hand, are lucky to get a focus indicator they can see. Visual design that makes keyboard affordances perceivable are extremely rare. Windows underlines accelerator keys, which is a mild help. But, is there any system support for indicating that you should navigate with arrow keys in the menubar of your browser? People who try to operate without a mouse for the first time feel like they have to go to school just to learn how to use their computer. We need to change this.

It's worse on the web. Many people have become accustom to being forced to navigate to every element with just one key -- Tab. This degrades the keyboard UI to the point of unusability, forcing people to press the tab key thousands of times compared to a rapid click here and there for a mouse user. GUIs on the web that actually work and are fully accessible are the first step toward making web software practical for people who cannot use a mouse.

But, in my opinion, we need to make the web better than native GUIs because, as I said, native GUIs are horrifically difficult to learn to use without a mouse. Some software is super easy and enjoyable with the keyboard, but only if you are in the know; you took time to RTFM.

ARIA solves this problem for screen reader users. But, for sighted keyboard users, we need more work to make visual designs that help people understand what to do. You can see one small attempt at this in the example of a grid that presents a simple list of links.

[aardrian]

@mcking65, I understand this is getting outside the scope of the original issue, but you make some assertions above that I feel must be addressed.

Mouse users get all kinds of fancy, built-in clues to available affordances. For instance, the mouse pointer changes shape to indicate possible operations. Keyboard users, on the other hand, are lucky to get a focus indicator they can see. Visual design that makes keyboard affordances perceivable are extremely rare. Windows underlines accelerator keys, which is a mild help. But, is there any system support for indicating that you should navigate with arrow keys in the menubar of your browser? People who try to operate without a mouse for the first time feel like they have to go to school just to learn how to use their computer. We need to change this.

All of this is well outside the scope of the menu pattern. If you feel this is not, then the menu pattern must also include thorough and cross-referenced statements about focus styles, contrast, and so on. This should include clear instructions and should not suffer from the issues itself (see the red arrows on the black background in the linked example). You cannot identify benefits and problems in a pattern you want to mimic and then fail to include them in your own pattern.

For example, you identify accelerator keys in Windows (which are now only indicated when the user presses the Alt key) as a "mild help". Should the menu pattern also include those? Should the pattern include accesskey?

It's worse on the web. Many people have become accustom to being forced to navigate to every element with just one key -- Tab. This degrades the keyboard UI to the point of unusability, forcing people to press the tab key thousands of times compared to a rapid click here and there for a mouse user. GUIs on the web that actually work and are fully accessible are the first step toward making web software practical for people who cannot use a mouse.

The menu pattern does not change (nor improve) that overall experience. A keyboard user still must tab many times to get to the menu pattern, and once there, must switch keys but press it no fewer times to navigate within the menu itself.

To address the problem you identify, browsers should expose landmarks. That is not in the scope of the menu pattern.

But, in my opinion, we need to make the web better than native GUIs because, as I said, native GUIs are horrifically difficult to learn to use without a mouse. Some software is super easy and enjoyable with the keyboard, but only if you are in the know; you took time to RTFM.

I do not disagree that native UIs are difficult for mouse users to use without a mouse. However, my and your opinion do not matter here. Proper user research can support or refute our opinions. I can shower you with results from my own studies, but more importantly I think this needs to keep to the scope of identifying how to make the pattern. Not trying to re-write how the web is used by using ARIA as a cudgel.

ARIA solves this problem for screen reader users. But, for sighted keyboard users, we need more work to make visual designs that help people understand what to do. You can see one small attempt at this in the example of a grid that presents a simple list of links.

ARIA cannot solve this problem for non-SR keyboard users. It is not exposed in other AT. I agree that we need more work to make visual designs that help people understand what to do, as you say. To that end, this pattern will need to include instructions to keyboard users on how to use it. Otherwise, it is not a very effective pattern. The "simple" list of links that you link uses a technique that you should include in the menu pattern.

Perhaps then we will have a full pattern we can test with non-SR keyboard users instead of just asserting that it is better.

Coming out of your feedback, I have pulled 4 items you identified that it seems need to be included in the menu pattern before it can be wrapped up:

• Link to related WCAG techniques for contrast, focus styles, etc.
• Support for accesskey and a way to expose it.
• Promotion of native landmark support in browsers.
• Full visible, accessible user-facing instructions for how to use the menu pattern.

All that being said, the menu pattern does not belong on web site navigation.

[annabbott]

+1 for adding nav region and text about it under Accessibility Features!

No issues noted.

[mcking65]

@aardrian commented:

@mcking65, I understand this is getting outside the scope of the original issue, but you make some assertions above that I feel must be addressed.

Mouse users get all kinds of fancy, built-in clues to available affordances. For instance, the mouse pointer changes shape to indicate possible operations. Keyboard users, on the other hand, are lucky to get a focus indicator they can see. Visual design that makes keyboard affordances perceivable are extremely rare. Windows underlines accelerator keys, which is a mild help. But, is there any system support for indicating that you should navigate with arrow keys in the menubar of your browser? People who try to operate without a mouse for the first time feel like they have to go to school just to learn how to use their computer. We need to change this.

All of this is well outside the scope of the menu pattern. If you feel this is not, then the menu pattern must also include thorough and cross-referenced statements about focus styles, contrast, and so on. This should include clear instructions and should not suffer from the issues itself (see the red arrows on the black background in the linked example). You cannot identify benefits and problems in a pattern you want to mimic and then fail to include them in your own pattern.

Well, in my midnight mood, I did get a bit punchy and go off topic. Yes, this is outside the scope of the current work on the design pattern. However, I do one day want to get the community more focused on evolving visual design of GUIs on the web to better serve a wider variety of people.

For example, you identify accelerator keys in Windows (which are now only indicated when the user presses the Alt key) as a "mild help". Should the menu pattern also include those? Should the pattern include accesskey?

I m not sure what would be the most practical approach here. The design supports first letter nav but not the equivalent of accelerators. I am definitely not a fan of accesskey ... it does not work well.

It's worse on the web. Many people have become accustom to being forced to navigate to every element with just one key -- Tab. This degrades the keyboard UI to the point of unusability, forcing people to press the tab key thousands of times compared to a rapid click here and there for a mouse user. GUIs on the web that actually work and are fully accessible are the first step toward making web software practical for people who cannot use a mouse.

The menu pattern does not change (nor improve) that overall experience. A keyboard user still must tab many times to get to the menu pattern, and once there, must switch keys but press it no fewer times to navigate within the menu itself.

Menubars can definitely improve this.

1. The entire menubar is a single tab stop, dramatically reducing the length of the page tab sequence.
2. Directional navigation through a hierarchy is more efficient than tabbing to every element, especially for screen reader users who explore with focus.
3. The menubar and submenus support first letter nav just like on MacOS and Windows, so you can rapidly go to where you want by typing letters.
4. We don't address it in this pattern, but a global shortcut key that focuses a menubar that is present on all pages can provide a simple way to provide predictable and repeatable navigation to common destinations.

So, it is possible to make a simple, efficient nav system with a menubar that provides real advantages over some other alternatives if you are ready to make the required investment in design and engineering.

To address the problem you identify, browsers should expose landmarks. That is not in the scope of the menu pattern.

Correct that is out of scope for this pattern. And, yes, browsers could expose landmarks. But, authors can do it too. The APG does not yet address this topic. However, we are experimenting with this at Facebook. Go to www.facebook.com and tab into the page or press alt+/ from inside the page. The first menu labeled "Sections of this page" reveals the landmark regions on the page. Keep in mind that this feature is still in its early days.

ARIA cannot solve this problem for non-SR keyboard users. It is not exposed in other AT. I agree that we need more work to make visual designs that help people understand what to do, as you say. To that end, this pattern will need to include instructions to keyboard users on how to use it. Otherwise, it is not a very effective pattern. The "simple" list of links that you link uses a technique that you should include in the menu pattern.

Possibly. We do not yet have enough feedback on that instructional popup or "NUX" and associated visual design to spread it more widely across the ARIA Practices examples. It is just an "idea" that I had put in to the grid example to see if it helps solve a problem that the naked ARIA does not address.

Coming out of your feedback, I have pulled 4 items you identified that it seems need to be included in the menu pattern before it can be wrapped up:

• Link to related WCAG techniques for contrast, focus styles, etc.
• Support for accesskey and a way to expose it.
• Promotion of native landmark support in browsers.
• Full visible, accessible user-facing instructions for how to use the menu pattern.

I agree that in some form or other, these general concerns need to be addressed someplace in the ARIA practices. I would leave out accesskey due to its deficiencies and just say shortcut keys. The ARIA practices does have a keyboard interface development section that will evolve to treat that topic. These are concerns related to, but not directly a part of, the menu pattern given the way the ARIA practices is structured.

All that being said, the menu pattern does not belong on web site navigation.

I agree that most of the time it is not the best fit. But, whether it is a good fit depends on many factors, including the existing the design. If people make GUIs that behave like menubars and use them for web site navigation, which they sometimes do, then the menubar pattern belongs there. Without it, those GUIs will not offer users of assistive technologies the same benefits that the visual designs offer others. They won't really be accessible.

We will treat the topic of choosing an approach for making site navigation accessible when we start work on the relevant issues in the "Do Later" column of the menu and menubar project: https://github.com/w3c/aria-practices/projects/5

One of those issues, like the one you raised, is the best place to continue this conversation. I probably should have been writing there rather than here.

[yatil]

@MichielBijl @mcking65 wai-eo-editors mailing list just received a possible bug report on this component: https://lists.w3.org/Archives/Public/wai-eo-editors/2018Nov/0011.html

[carmacleod]

Thanks, @yatil. I think that's covered in #906.

[jnurthen]

Correct – but we have already fixed this as part of #930. I hadn’t noticed the duplicate so have closed #906

[Flujible]

I've noticed a number of issues with this drop down; I'm happy to add more details i.e. steps to reproduce if these issues haven't been raised already:

• Hovering over the separator li causes the height of said li to change, so you can get it to rapidly switch which element is being focused on if you hold your cursor in the right place
• There's a gap that you cant see (due to background colours) between the root menu item and list it creates which causes the sub menu to disappear if you put your mouse there for more than ~0.5 seconds
• The whole sub menu changes its heights when you move your mouse into it
• The amount of time it takes for the menu to disappear changes depending on where your mouse exits the area, so this is inconsistent behaviour

[dnlml]

In the role="menubar" element, all the anchor elements should be span/button because they redirect to nowhere. If an element is an anchor (it means it redirect somewhere), we should be able to press enter on it and being redirected, while if we hover it, it should open his related role="menu" element.

On touch devices, we should have the link <a> with a <button> on the side to be able to unfold the menu or to go to the link.

Right now, If I click with the mouse on the menuitem into the menubar I go to the link, but If I press enter It open the menu. So for users with controlling with keyboards, it is impossible to visit that page

EDIT: improving description