Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Clarify Purpose of Menu Navigation #353

Open
aardrian opened this issue Apr 4, 2017 · 53 comments · May be fixed by #1492
Open

Clarify Purpose of Menu Navigation #353

aardrian opened this issue Apr 4, 2017 · 53 comments · May be fixed by #1492

Comments

@aardrian
Copy link
Contributor

@aardrian aardrian commented Apr 4, 2017

I am seeing more and more cases of authors who believe that web site navigation menus must be marked up with the ARIA menu role and adhere to the ARIA menu pattern.

In challenging developers to identify where that recommendation comes from, they have pointed to this document. This document does not explicitly state that standard web site navigation should or should not follow the pattern. The overall document implies that many (most?) of these patterns are for custom widgets that should behave as their native analogues.

This confusion is also fed by a linked example of a web site menu at the end of the section:

If the example is truly worthy and accurate and represents an exceptional departure from the menu pattern as one for applications, then it should be stated as such.

I feel strongly that regular web site navigation should not be treated as an application menu, nor should it follow the pattern outlined here. At least not without a really good reason.

Supporting this, nowhere does the HTML spec say that ARIA is necessary for site navigation, nor do any instructions for using the <nav> element suggest it.

I feel even more strongly, however, that this document needs to add clarity in the pattern description about when it is appropriate to apply this pattern. Here is the opening paragraph with some suggested language in bold:

A For the scope of this pattern, a menu is a widget that offers a list of choices to the user, such as a set of actions or functions , and which is intended by the author to function identically to a native operating system menu (such as an application menu). A menu is usually opened, or made visible, by activating a menu button, choosing an item in a menu that opens a sub menu, or by invoking a command, such as Shift + F10 in Windows, […]

@ZoeBijl
Copy link
Contributor

@ZoeBijl ZoeBijl commented Apr 5, 2017

Thank you Adrian for bringing this up.

Just so we’re all looking at the latest version of the “Navigation menubar example”.

I agree that using role=menu for site navigation is a weird concept. That said, I can also see the need for more complete keyboard support when it comes to site navigation with sub menus.

@aardrian
Copy link
Contributor Author

@aardrian aardrian commented Apr 5, 2017

That said, I can also see the need for more complete keyboard support when it comes to site navigation with sub menus.

Can you expand on that? As far as I know, using the native <a href> gives complete keyboard support. CSS can hide things and pull them out of the tab-stop flow, JS can do the same, but those are not HTML (which is where ARIA comes into play). So what in HTML does not provide sufficient keyboard support for a list of links? Should the pattern also address JS / CSS practices as well?

@ZoeBijl
Copy link
Contributor

@ZoeBijl ZoeBijl commented Apr 6, 2017

@aardrian what I meant with “more complete keyboard support” is the ability to use the arrow keys to navigate the navigation menu. That doesn’t requires a bunch of ARIA to achieve as that can be done with JS. However, it does raise the question how you communicate that such features exist.

A similar issue arrises when I finally get to breadcrumbs with one tab stop. There’s currently nothing that tells a user that it has only one tab stop and that you should use the arrows to move through it.

Should the pattern also address JS / CSS practices as well?

No. For JS we test with various AT and browsers but do not require “best practices” if that makes sense. For CSS there’s the CSS-a11y TF.

@aardrian
Copy link
Contributor Author

@aardrian aardrian commented Apr 6, 2017

Thanks for clarifying. All of that sounds like it is outside of the scope of my issue. I misunderstood and thought you were making a case for or against my proposed language change.

@mcking65 mcking65 added the question label Jul 15, 2017
@mcking65 mcking65 added this to the 1.1 Rec milestone Jul 15, 2017
@mcking65 mcking65 added the Feedback label Jul 15, 2017
@mcking65 mcking65 self-assigned this Jul 15, 2017
@mcking65
Copy link
Contributor

@mcking65 mcking65 commented Jul 15, 2017

This is related to issues #13 and #287.

@straker
Copy link

@straker straker commented Jul 16, 2017

I'd just like to say that Heydon Pickering's Inclusive Components article of when to use menu navigation vs site navigation was very helpful and clarifying. Would love to see it used as a reference/link in the new aria practices.

@yatil
Copy link

@yatil yatil commented Jul 16, 2017

<w3c-hat type="off" title="Commenting as a private citizen :-)">

I, too think that regular site menus should not use ARIA application semantics and keyboard navigation.

  1. ARIA semantics are not visually indicated to sighted keyboard users. Especially for users that are not used to using the keyboard, it can be disorienting when the tab key does not work as expected. Regardless of the knowledge level, I don’t think we want to expect that users just try which keyboard interaction method works for a particular menu.

  2. For menus in web application that mimic desktop applications, I strongly think that it is reasonable to use the ARIA menu semantics and keyboard interaction.

My basic decision tree is: If the menu items are links to other pages (including AJAX trickery), don’t use aria menu. If every menu item in the menu carries out an action (copy, paste, new document), use aria menu.

The WAI tutorials try to make that distinction similarly in the menus tutorial (some minor updates have been added but not published).

@scottaohara
Copy link
Member

@scottaohara scottaohara commented Jul 18, 2017

I agree with the points @aardrian , @straker, and @yatil are raising.

I would not expect this pattern to ever be used for a primary navigation, where the purpose of the nav was to bring people to different pages / sections of a site/app, and think that the purpose of this role/pattern needs to be called out more explicitly, as @aardrian proposed.

@DavidMacDonald
Copy link

@DavidMacDonald DavidMacDonald commented Feb 13, 2018

I agree with the sentiment here. A list of links is a very understandable construct for simple list of navigation items..

<nav><button aria-expanded="true"  ...>Our services</button>
<ul><li><a href="..." >Hats</a></li>
<li><a href="..." >Shoes</a></li>
<li><a href="..." >Pants</a></li>
...
</ul>
</nav>
@mcking65
Copy link
Contributor

@mcking65 mcking65 commented Feb 14, 2018

@yatil commented:

My basic decision tree is: If the menu items are links to other pages (including AJAX trickery), don’t use aria menu. If every menu item in the menu carries out an action (copy, paste, new document), use aria menu.

That decision tree suggests that authors use ARIA widget roles to describe the purpose of the elements rather than their interaction model.
ARIA widget roles are designed to represent interaction models while accessible labels and content describe purpose.
Basically, a widget role is a promise to the user -- I promise this thing that I gave the menu role will act like a menu.
We cover this in the Read Me First section of the APG.

Of course, you can decide to draw any lines you wish around what types of functions you think belong inside specific widgets. That is a design call that has nothing to do with ARIA. If opening a different page is a function you wish not to put inside of ARIA menus, you don't have to put that function into an ARIA menu.

But, please, regardless of the function of an element, never use the menu role unless the element to which you apply it behaves like a menu as described in the APG menu pattern. And, always use the menu role if the element acts like a menu as described in the menu pattern.

The one certainty I see in this topic is that it is not black or white. A UX design is not necessarily good or bad based only on whether it uses ARIA menus for some of its navigation functions. It could be horrible or excellent or somewhere inbetween. You have to evaluate the total design.

@mcking65
Copy link
Contributor

@mcking65 mcking65 commented Feb 14, 2018

@DavidMacDonald commented:

I agree with the sentiment here. A list of links is a very understandable construct for simple list of navigation items..

<nav><button aria-expanded="true" aria-haspopup="true" ...>Our services</button>
<ul><li><a href="..." >Hats</a></li>
<li><a href="..." >Shoes</a></li>
<li><a href="..." >Pants</a></li>
...
</ul>
</nav>

David, Thanks for using a button there. I have often seen people make a disclosure that operates with a link, which is not what a link does. A link moves your focus to a new location ... not show/hide or perform other functions.

HOWEVER, please do not use aria-haspopup="true" in this construct. That changes the button to a menu button. But, your markup indicates that this is not a menu. This is the HTML that you would use for an element that behaves like a disclosure. Obviously, I am assuming you would not add JavaScript that would insert menu and menuitem roles and add arrow key support.

@patrickhlauke
Copy link
Member

@patrickhlauke patrickhlauke commented Feb 15, 2018

FWIW agree, unless it's a desktop-like application menu, don't use the full-on ARIA menu when a simple disclosure widget plus a series of links will also work just fine and not break some user's expectations that they can just TAB to links etc rather than having to work out they can only use arrow keys.

@patrickhlauke
Copy link
Member

@patrickhlauke patrickhlauke commented Feb 15, 2018

@MichielBijl

@aardrian what I meant with “more complete keyboard support” is the ability to use the arrow keys to navigate the navigation menu. That doesn’t requires a bunch of ARIA to achieve as that can be done with JS. However, it does raise the question how you communicate that such features exist.

one caveat there would be that for AT users, you'd likely be competing with their AT keys (and I hope the answer here won't be to use role="application" ;) ). sure, you can enhance the interaction for non-AT keyboard users, I guess...

@mraccess77
Copy link

@mraccess77 mraccess77 commented Feb 16, 2018

In my opinion navigation structures should not use role menu. Role menu forces AT into a certain mode as does role of application and this can be problematic especially when other elements exist in a navigation structure such as headings. In my experience role menu constructs can also be problematic in some mobile situations as well because they expect certain keystrokes. The ARIA example from the W3C incorrectly uses these roles for navigation despite the good advice from the WAI tutorials project not to use these roles.

@mcking65
Copy link
Contributor

@mcking65 mcking65 commented Feb 21, 2018

@MichielBijl commented:

@aardrian what I meant with “more complete keyboard support” is the ability to use the arrow keys to navigate the navigation menu. That doesn’t requires a bunch of ARIA to achieve as that can be done with JS. However, it does raise the question how you communicate that such features exist.

@patrickhlauke responded:

one caveat there would be that for AT users, you'd likely be competing with their AT keys (and I hope the answer here won't be to use role="application" ;) ). sure, you can enhance the interaction for non-AT keyboard users, I guess...

Definitely not the application role. If you are creating menu behaviors, then you need to use the menu pattern and its associated roles. That is the best way to serve all users, especially AT users.

Again, the purpose of ARIA is to describe the accessibility features you provide. The most important principle here is to use ARIA accurately. If you create something that walks like a duck, be sure to describe it as a duck. Generally, it is also really smart to make it look like a duck too, but there are some situations, e.g., a person that is doing a duck dance, where looks are secondary.

@mcking65
Copy link
Contributor

@mcking65 mcking65 commented Feb 21, 2018

@mraccess77 commented:

In my opinion navigation structures should not use role menu.

To re-emphasize two earlier points:

  1. If you want to draw boxes that exclude some design options from consideration for navigation functions, you can do so. The ARIA spec and APG do not force people to stay inside or outside such boxes.
  2. You should only use the menu role if you are implementing one of the ARIA menu patterns.

Role menu forces AT into a certain mode as does role of application and this can be problematic especially when other elements exist in a navigation structure such as headings.

Agree that you definitely do not want to put headings inside of menuitems!

However, if the purpose of a particular navigation design is to provide features like arrow key navigation, typeahead, efficient hierarchy, etc., then you really want the AT users to automatically get the mode switching. So, design first, then use the ARIA that describes the design. For instance, consider the bookmarks menu in most browsers. If you want to provide that type of experience, then you will need the ARIA menubar pattern.

In my experience role menu constructs can also be problematic in some mobile situations as well because they expect certain keystrokes.

Sounds like an implementation issue as I am pretty sure that the menu pattern roles are reasonably supported for touch interfaces.

The ARIA example from the W3C incorrectly uses these roles for navigation despite the good advice from the WAI tutorials project not to use these roles.

Please elaborate? Which example is incorrect? What aspects are incorrect? They are admitedly complex and there are still improvements being made as you can see from the APG menu project.

@aardrian
Copy link
Contributor Author

@aardrian aardrian commented Feb 21, 2018

@mcking65

But, please, regardless of the function of an element, never use the menu role unless the element to which you apply it behaves like a menu as described in the APG menu pattern. And, always use the menu role if the element acts like a menu as described in the menu pattern.

APG has a pattern that explicitly refers to itself as web site navigation. The APG menu pattern at no point explicitly states that it is for application-level menus. This original report is to address that. The current description is so broad that a developer could take it to mean that it applies to web site navigation, while what I think you are saying is that if it has the behaviors you suggest it should get a menu role.

Definitely not the application role. If you are creating menu behaviors, then you need to use the menu pattern and its associated roles. That is the best way to serve all users, especially AT users.

I think @patrickhlauke was suggesting that something with the menu role should live in a larger container with the application role. Which I think is probably a good idea, as the menu role is for application-style menus.

Again, the purpose of ARIA is to describe the accessibility features you provide.

That is not strictly true. I am avoiding spec quoting since this is its own rabbit hole, but that assertion is a bit simplified. Certainly aria-hidden does not describe an accessibility feature.

For instance, consider the bookmarks menu in most browsers. If you want to provide that type of experience, then you will need the ARIA menubar pattern.

You have described a native application control. Which is fine, as that is what the menu and menubar roles are for.

To re-emphasize two earlier points:

  1. If you want to draw boxes that exclude some design options from consideration for navigation functions, you can do so. The ARIA spec and APG do not force people to stay inside or outside such boxes.
  2. You should only use the menu role if you are implementing one of the ARIA menu patterns.

I am not sure anyone is arguing against those points. Or even raised those objections.

To re-emphasize my original point:

  • This document needs to add clarity in the pattern description about when it is appropriate to apply this pattern. General web site navigation is not it (by default), though cases may exist where it is appropriate. See the suggested language I provided.

Please elaborate? Which example is incorrect? What aspects are incorrect? They are admitedly complex and there are still improvements being made as you can see from the APG menu project.

I think @mraccess77 is talking about the examples in the APG, though I leave it for him to clarify. I can tell you, however, that these do contradict the WAI Tutorial, which he referenced: https://www.w3.org/WAI/tutorials/menus/

Regardless, to bring this back around to the original issue — I provided suggested text to amend the menu pattern description. Is that text acceptable to you? What do I need to do to it to have it accepted?

@patrickhlauke
Copy link
Member

@patrickhlauke patrickhlauke commented Feb 21, 2018

I think @patrickhlauke was suggesting that something with the menu role should live in a larger container with the application role

nah, what patrick was suggesting was in response to @MichielBijl's suggestion of NOT using the menu pattern (so using, say, expand/collapse disclosure widgets which then open up and contain a series of focusable elements like links) but including additional cursor up/cursor down functionality anyway (mimicing the ARIA menu keyboard handling to an extent, while also allowing regular tab/shift+tab). and i pointed out that doing this will work for non-AT keyboard users, but that for AT users those additional keystrokes won't work as they'll compete with AT reading keys. (and then imploring that hopefully the plan then isn't to suppress THOSE via role="application"). a shorter way of saying it would be: don't do it, but if you do, know you're not helping keyboard AT users.

@mraccess77
Copy link

@mraccess77 mraccess77 commented Feb 21, 2018

I have provided below the menubar example from the ARIA 1.1 AP examples. While this menu looks like an application it really feels like it is meant for navigation.
https://www.w3.org/TR/wai-aria-practices-1.1/examples/menubar/menubar-1/menubar-1.html#

@mcking65
Copy link
Contributor

@mcking65 mcking65 commented Feb 23, 2018

@aardrian, It feels like we are talking past each other. I'll restart and try to discover where I am getting off track.

I see three primary points raised in your first comment:

  1. You have encountered some people who believe the APG says they should use the ARIA menu pattern for site navigation.
  2. There are reasons to be concerned about people implementing the menu pattern for site navigation.
  3. You requested a revision to the menu pattern description to emphasize that the interaction patterns of ARIA menus are like those of desktop menus.

The third point is purely editorial. It is low hanging fruit. So, as you suggested at the tail end of your last comment, let's start there.

You wrote:

to bring this back around to the original issue — I provided suggested text to amend the menu pattern description. Is that text acceptable to you? What do I need to do to it to have it accepted?

And your proposed revision is:

A For the scope of this pattern, a menu is a widget that offers a list of choices to the user, such as a set of actions or functions , and which is intended by the author to function identically to a native operating system menu (such as an application menu). A menu is usually opened, or made visible, by activating a menu button, choosing an item in a menu that opens a sub menu, or by invoking a command, such as Shift + F10 in Windows, […]

Would the following be sufficient?

A menu is a widget that offers a list of choices to the user, such as a set of actions or functions. Menu widgets behave like native operating system menus, such as the menus that pull down from the menubars commonly found at the top of many desktop application windows. A menu is usually opened, or made visible, by activating a menu button, choosing an item in a menu that opens a sub menu, or by invoking a command, such as Shift + F10 in Windows, […]

Note: keep in mind that the first occurrence of the word "menu" is a link to the ARIA spec for the menu role.

If we can come to consensus on the APG description of the menu pattern, I think it will help with one of the disconnects propagating through this thread and beyond. Specifically, there are several different meanings of the term "menu" being invoked. This problem is exacerbated by the fact that we have multiple WAI resources that use the term "menu" in very different ways. The ARIA spec and APG use "menu" in a narrow sense whereas the WAI tutorial is using it in a very broad and generic way. I agree 100% with the sentiment that it would be helpful to create more harmony among these resources.

With respect to your first point, your original comment acknowledges that the APG does not tell people they should use the menu pattern for navigation. It does say they can, but it does not say or even imply they should. Along these lines, even though we have not yet completed issue #89, "Draft site navigation guidance section that addresses choosing among structures, disclosures, menus, grids, toolbars, trees, etc.," I hope that all the following would disavow the idea that the APG dictates use of the menu pattern for site navigation:

  1. There is a simple nav element containing a list of links at the top of every APG example page.
  2. The landmark region examples demonstrate site nav made with a navigation region containing a simple list of links and aria-current="page" as a current page indicator.
  3. Patterns other than menu, including grid and tree, also include examples of how to group navigation functions.

For that matter, it is important for everyone to understand that the APG is informative, not normative. As an editor, I am pretty maniacal about avoiding language and phrasing that could be mistaken as normative. I have been working on getting rid of even the non-normative uses of the words "should" or "must"; a few do remain. Further, the APG uses present tense language that purposely does not make the author the subject of active phrasing, e.g., "the element has role x" instead of "Authors should use role X on elements that".

Your second point, which has been the focus of most of this thread, is more complex and subtle. Perhaps one approach to making headway is to answer the question, "Why does the APG include examples of navigation widgets that implement the menu, tree, and grid patterns given that there are so many seasoned professionals who have raise legitimate concerns with using ARIA widgets for navigation functions?"

I'd like to address the second aspect of that question first -- why does the APG seem to be silent about many real-world consequences of utilizing ARIA widgets?

While silent about specifics, the APG does acknowledge a couple classes of problems with real-world use of the patterns. The first link on every example page is to the Browser and Assistive Technology Support section of the "Read Me First" section of the guide, which starts with the paragraph:

Testing assistive technology interoperability is essential before using code from this guide in production. Because the purpose of this guide is to illustrate appropriate use of ARIA 1.1 as defined in the ARIA specification, the design patterns, reference examples, and sample code intentionally do not describe and implement coding techniques for working around problems caused by gaps in support for ARIA 1.1 in browsers and assistive technologies. It is thus advisable to test implementations thoroughly with each browser and assistive technology combination that is relevant within a target audience.

The fact is that every browser/assistive technology combination has its own unique set of ARIA support dead spots where it does not yet accurately and effectively render the experience represented by the ARIA. This spotty rendering of ARIA is one of the root causes of the practical problems generating concerns about wrapping up core site functionality in ARIA widgets. The APG is meant to be a canonical resource that can serve as a foundation for improving this situation. That is why the "Read Me First" also says:

Except in cases where the ARIA Working Group and other contributors have overlooked an error, examples in this guide that do not function well in a particular browser or with a specific assistive technology are demonstrating browser or assistive technology bugs. Browser and assistive technology developers can thus utilize code in this guide to help assess the quality of their support for ARIA 1.1.

To be more blunt, my ambition is to aggressively foster remediation of the pervasive brokenness in the web accessibility ecosystem. To that end, the scope of the APG task force also includes a project for assessing the experiences provided by assistive technologies for each pattern, i.e., a "CanIUse" type of resource for the patterns. Acting on the assessments will be part of ARIA working group collaboration with assistive technology and browser developers. I am spinning up that project now and hope to be sharing those plans as part of our presentation at CSUN.

So, the goal is progress toward a time when ARIA is so beautifully rendered that assistive technology users everywhere are clambering for web-based versions of all their native apps. This is realistically feasible. Bringing all the accessibility advantages of native GUIs to web GUIs is exactly what ARIA is designed to do.

The nascent accessibility advantages of web GUIs that have fabulous keyboard support and work really well with assistive technologies are the reason the APG includes examples like the navigation menubar. These advantages are well proven by GUI widgets that support navigation in native apps. Native apps have long been very effectively employing widgets, such as menubars, trees, toolbars, and grids, for navigating everything from libraries of books and file systems to email folders and screen reader help. Apps that do so are strongly preferred by assistive technology and keyboard users over apps that force the user to tab through every single element or memorize arcane keyboard shortcut schemes.

Admittedly, there is a lot of work to do to get to the point where we can transform any web GUI into something that is as enjoyable and efficient for people who rely on keyboards or assistive technologies as it is for the typical mouse user. Not all of that work is specific to ARIA. For instance, another gaping hole is the common lack of visual design features that reveal keyboard affordances. Even though that is not an ARIA-specific issue, since it impedes adoption and value realization, it could someday become something that the APG task force helps address.

It is worth emphasizing again that the APG is not suggesting that navigation should or should not be designed in some specific manner. However, if you choose to use an ARIA widget, such as a menu, it is providing best practice for implementing that widget. Whether or not the menu pattern is a good choice for a particular navigation feature on a particular site depends on many factors, some of which are beyond the scope of the APG. We will attempt to address the in-scope factors when completing issue #89.

You wrote:

The APG menu pattern at no point explicitly states that it is for application-level menus. This original report is to address that. The current description is so broad that a developer could take it to mean that it applies to web site navigation, while what I think you are saying is that if it has the behaviors you suggest it should get a menu role.

It is true that the APG does not attempt to limit the uses of the menu pattern to functions other than navigation. That is intentional.

The APG is also saying that if a widget "has the behaviors you suggest it should get a menu role."

As an aside, because of the following remark, I would like to highlight changes we made to role application in ARIA 1.1 that have not received much attention.

I think @patrickhlauke was suggesting that something with the menu role should live in a larger container with the application role. Which I think is probably a good idea, as the menu role is for application-style menus.

That idea is inline with the original concept behind the application role, but that type of use created more problems than it solved. Consequently, after considerable deliberation, we made significant changes to the definition and description of the application role in ARIA 1.1. The new definition is:

A structure containing one or more focusable elements requiring user input, such as keyboard or gesture events, that do not follow a standard interaction pattern supported by a widget role.

The description also says:

When there is a need to create an element with an interaction model that is not supported by any of the WAI-ARIA widget roles, authors MAY give that element role application.

In other words, people should not wrap ordinary ARIA widgets in an application. Just use it to make interactive experiences that can't be made with existing ARIA widget roles.

@carmacleod
Copy link
Contributor

@carmacleod carmacleod commented Jul 22, 2020

See also Terrill Thompson's post about Dropdown Navigation Menus (Feb 2020).

@jongund
Copy link
Contributor

@jongund jongund commented Jul 22, 2020

@carmacleod
@mcking65
I think we need to have guidance section on collections of links used for navigation of pages in a website, with examples using menubar, menu buttons, disclosure and simple tab navigation. The section would describe the accessibility features and issues of using these different techniques. This section could also address issues of mega menus. Hopefully can get this topic on an agenda some time.

@aardrian
Copy link
Contributor Author

@aardrian aardrian commented Jul 22, 2020

@jongund While I like that idea overall, I am not sure how much bandwidth this team has to manage a full pattern library (even if navigation only) when this issue alone has been open for 3¼ years.

My understanding is that this Note started as a way to show how ARIA can re-create native-like controls (or replicate some HTML capabilities) but as its scope continues to grow (see sections 4 through 9, which are not patterns) I feel that trying to become a full-blown pattern library with the necessary ongoing testing is outside the scope and release timing of this Note.

@mraccess77
Copy link

@mraccess77 mraccess77 commented Jul 23, 2020

The current navigation structure implemented as a menu has caused great confusion and wasted many hours of development for many organizations. Most users and accessibility experts find that it's more difficult to use as a menu (screen reader forms mode type issues) and implementation is more complex and almost always incorrect. Our recommendation is almost always to rip out what was implemented incorrectly and use the simpler, more easy to implement and better for end user pattern of disclosure for navigation. This causes a lack of trust in ARIA examples and makes it look like experts in our field can't agree causing advice to be questioned.

@jsl303
Copy link

@jsl303 jsl303 commented Jul 23, 2020

I'm a screen reader user, and I've also encountered many cases with aria menu implementation where it asks users to choose an action.
For example, on this github page, "add your reaction" and "show options" for a comment appears as menu to screen readers.
Is this a valid use of menu?

@aardrian
Copy link
Contributor Author

@aardrian aardrian commented Jul 23, 2020

@jsl303 those two pieces of text live in a native <summary> element (within a <details>) element, but the site author has added aria-haspopup="menu" and role="button". Those are not analogous to web site navigation since those affect content within the current page. As such, I feel those are outside the scope of this issue.

I am also not going to comment on whether I think that mark-up is appropriate (because it is outside the scope of this issue), other than to say Github has made curious decisions before about how to use <details> and <summary>, so I am unwilling to use them as an example of good (or not) practices.

@jasonwebb
Copy link

@jasonwebb jasonwebb commented Jul 26, 2020

Just chipping in another +1 and my perspective as an industry consultant working with clients to make their websites accessible (often large retail clients). I can definitely confirm what @DavidMacDonald and others in this thread have said about how this code sample has led a lot of teams astray. Its a common issue that my company's audit team calls out fairly regularly. Regularly enough, actually, that we have an internal article explaining to clients why this code sample shouldn't be used with a link to this very thread 😆 I'll also echo @mraccess77's great point about how the confidence and trust that real-world dev teams have in WAI-ARIA (and even the W3C) can be shaken when they are told to disregard an APG example. A topic for another time and place, but I just wanted to +1 that experience!

I totally understand that changes to the APG need to be discussed thoroughly to get consensus. I see that this issue has been open for about 3 years and has (by far?) the most number of upvotes at 35, with the next highest being just 5. It is also the second-most commented open issue, if I'm sorting things correctly. It seems like there has been pretty solid consensus here, and unusually high demand.

Is the disclaimer/note that @aardrian proposed originally already on its way to being integrated and deployed (via PR #1232)? If so, I'm curious as a newbie what the next steps are and whether there is anything I can do to help. 😄

@sinabahram
Copy link

@sinabahram sinabahram commented Jul 26, 2020

Huge +1 to the sentiments expressed here. We've gone down the menu-based pattern for site navigation with a few clients, and we did make it work well, but it took a ridiculous amount of effort, testing, time, and energy. It is simply not worth it, full stop, for site-based navigation. Between disclosures and some additional semantics around the lists that are subsequently disclosed, you can have a fully accessible menu in 10% of the time/effort/money.

@sinabahram
Copy link

@sinabahram sinabahram commented Jul 26, 2020

@jsl303 to answer your question (fellow screen reader user here) I think the menu implementations on GitHub are getting a ton better. They are now way more accessible than where they were before, but full disclosure, my company worked with them on them. The work is not done, however, so that is important to note. The focus-based traversal of emoji and such is very similar to approaches taken by Slack and other interfaces. If you have specific accessibility issues with it, please do not hesitate to reach out to me so we can discuss and make sure we are not inadvertently making something harder to use. I don't want to take up this thread with that conversation, though.

@JAWS-test
Copy link

@JAWS-test JAWS-test commented Jul 27, 2020

Even though I agree that a navigation does not need to be marked as a menu and simple menu structures should not be marked as a menu, I do not understand the principle objections against menus as a means of navigation. For complex navigation structures I consider menus to be suitable and have seen many working implementations in my WCAG test practice that were not to be criticized.

@StommePoes
Copy link

@StommePoes StommePoes commented Jul 27, 2020

Hi @JAWS-test

  1. Developers are led to believe they need or should use application menus for navigation menus
  2. application menus being much more complex than navigation menus, developers easily screw them up. Developers with accessibility widget experience can build them correctly, but the web is mostly built by people who think HTML == <div>
  3. Sighted keyboarders (like me) have no way of knowing how a menu works, but have been taught for over 20 years that you Tab through them. I recently audited a large company using application menus inside a mega-menu and even though I know the keystrokes for an application menu, due to the visual styling I could not predict how to reach any particular link in the submenu (all submenus were "open" or visible). They also wanted to have headings above lists of links, however headings are not allowed, so they of course built a frankenthing using menuitems styled like headings. What visually appeared to be a 2-level application menu was actually 3 levels deep to get the fake-heading thing to work. (Luckily, while testing they had already implemented a simpler list-of-links style navigation on a staging server, where I could confidently predict how to reach any link, yay).

Those are the objections. If developers want to use the application menu pattern, they must

  1. realise this is a choice they are making freely, and is not "required for accessibility"
  2. build it absolutely correctly
  3. style it visually to look like menus on applications do so users have a chance in hell to figure out how it works. Or, dare I say, name them as such above the menu, like "warning keyboard-users! the following is an application menu. use your arrow keys". But at the very least, force a "menu" to be a single column and each submenu must open out on user-command like application menus do. Styling them to all be onscreen at once is pure evil.
@JAWS-test
Copy link

@JAWS-test JAWS-test commented Jul 27, 2020

Hi @StommePoes

I agree with most of what you write, but I think these problems occur with many ARIA patterns. I have been testing websites according to WCAG for many years, and menus are not the main problem with ARIA. Much more often I find problems with e.g. grids, treegrids and comboboxes.

However, there is one point I cannot completely agree with:

style it visually to look like menus on applications do so users have a chance in hell to figure out how it works

That you cannot visually see how something is operated by keyboard is true for many elements. This applies, for example, to grids versus tables, toolbars versus buttons in a row (which get the focus with Tab) etc.
So far, the WCAG only requires that something be keyboard operable. It does not have to be obvious how something is operable. I think that's a flaw (see w3c/wcag#872). But honestly: With a menu, it is simply enough: If it doesn't work with Tab, I try the arrow keys. I think this is all clear to keyboard users.

I don't see that for navigation menus the first ARIA rule should apply more than for other ARIA patterns.

My suggestion would be to add the concerns about menus, which are shared by most people here (though not by me personally), to the section "Important Note About Use of This Example"

@aardrian
Copy link
Contributor Author

@aardrian aardrian commented Jul 27, 2020

@JAWS-test

I think these problems occur with many ARIA patterns.

Potentially relevant: Stronger support / testing / best practices text on every example #1228

@carmacleod
Copy link
Contributor

@carmacleod carmacleod commented Jul 27, 2020

@jasonwebb

Is the disclaimer/note that @aardrian proposed originally already on its way to being integrated and deployed (via PR #1232)?

Yes, a modified version of the proposed wording is in the first paragraph of the current Menu/Menubar Pattern (2nd sentence).

In addition, please note that the standard disclaimer from #1228 that @aardrian and @JAWS-test mentioned has been added to the top of each example, right after the h1 (green disclosure with summary "Important Note About Use of This Example").

As far as this issue is concerned though, it's a start, but we need to do more...

... I'm curious as a newbie what the next steps are and whether there is anything I can do to help. 😄

Personally, I really like @jongund's idea for the APG to create a new guidance section for site navigation.
It would be great to have help with the words. :)

We could point to the various site navigation examples that already exist in the APG, and discuss pros and cons of each method:

  • Navigation Menubar (the one this issue has issues with)
    • marked up as a full-blown application menubar with ARIA menubar/menu/menuitem roles and supporting attributes
    • single tab stop
    • arrow keys move through menuitems and open (sub)menus
    • enter and space keys also open (sub)menus, and follow links
    • might not be a good choice for novice users, as they may expect to navigate through links using tab key and not arrow keys
    • might not be a good choice if there are navigation links in the menubar (because it's unclear whether enter key opens menu or follows link)
  • Disclosure Navigation "Menu" (does not use the menubar pattern)
    • marked up using Disclosure pattern (i.e. a button with aria-expanded and aria-controls)
    • leverages aria-current="page"
    • enter/space open list of links; tab key navigates through links
    • example can optionally allow arrow key navigation in addition to tab key
    • more typical pattern for site navigation "menus", so may more closely match user expectations
  • Navigation Menu Button
    • marked up as an ARIA menu button (i.e. button with aria-haspopup="true" and aria-controls pointing to ARIA menu with menuitems)
    • single tab stop
    • arrow keys move through menuitems and open (sub)menus
    • enter and space keys also open (sub)menus, and follow links
    • similar issues as with Menubar Navigation example

All 3 patterns support Esc to close menu, and some support Home/End, PageUp/PageDown.
The Menubar and Menu button examples support first-letter navigation (possible because screen readers won't eat letter keys in focus/application mode).

Of course, all of the APG site navigation examples would need another note (or as @JAWS-test suggested, augment the current note) that directs the the reader to the new Site Navigation section to help them decide which pattern would work best for their users.

The new section could talk about testing with real users, and ensuring that the visual presentation suggests which keystrokes are supported (@StommePoes, do the 3 APG site nav patterns above meet your expectations for visual affordance? If not, please say what needs to be changed to make it clearer). The new section will also need to mention that it will be more work, and require more testing, to choose a full-blown menubar pattern, because the markup and keyboard handling need to be "Just So" in order to work properly with screen readers.

@sinabahram

We've gone down the menu-based pattern for site navigation with a few clients, and we did make it work well...

If you don't mind me asking, were the client and their users completely satisfied with the result? The menubars were single tab stop, correct? What, in particular, worked well? I'm just trying to articulate some pros for choosing menubar, so that we can make a note of them in the new APG section.

@JAWS-test

For complex navigation structures I consider menus to be suitable and have seen many working implementations in my WCAG test practice that were not to be criticized.

May I ask the same questions as I asked Sina, just above? What would you say are the advantages of ARIA menu/menubar?

@aardrian
Copy link
Contributor Author

@aardrian aardrian commented Jul 27, 2020

@sinabahram @carmacleod

If you don't mind me asking, was the client completely satisfied with the result?

Also, what about the client's users? I understand the client may be happy because users are happy, but too often I work with clients whose only consideration is the dev experience, caring little for how their users feel.

@JAWS-test
Copy link

@JAWS-test JAWS-test commented Jul 27, 2020

What would you say are the advantages of ARIA menu/menubar?

  • Simple compliance with WCAG SC 2.4.1 and 1.4.13
  • Simple operation that meets user expectations (maybe not all users, but many are familiar with menus)
  • Easy to implement for developers, as menus/submenus that are operated with Tab and Enter are often optimized for mouse users, but cannot be operated with the keyboard or are difficult to operate. This starts with the fact that a menu item that opens a submenu cannot itself serve as a link to a new page, although this is often required. Another problem would be that submenus are often not closed automatically when you leave them with the Tab key. I observe fewer problems with complex ARIA menus than when no ARIA is used for complex menus.
@carmacleod
Copy link
Contributor

@carmacleod carmacleod commented Jul 27, 2020

what about the client's users? I understand the client may be happy because users are happy...

Yep, that's what I meant. Have edited my original question to more closely reflect that.

@patrickhlauke
Copy link
Member

@patrickhlauke patrickhlauke commented Jul 27, 2020

randomly, i'll also add that the danger I see with navigation as menus is that as soon as an author then wants to, for whatever reason add something that doesn't fit the very strict structure of menuitem, menuitemcheckbox, menuitemradio or another submenu ... they need to completely switch pattern. anecdotally, this is the reason why we abandoned the menu pattern in Bootstrap, as authors were using it and then adding in things like search boxes and all sorts of extra fancy stuff, which browsers simply didn't know how to then convey/AT didn't know what to do with, as the resulting a11y tree often ended up being nonsensical.

@sinabahram
Copy link

@sinabahram sinabahram commented Jul 28, 2020

@aardrian and @carmacleod to answer both of your queries, the client was happy and learned a lot, but I want to focus on the user here. This should have never happened, and I don't allow it to happen since then, ever. The appropriate solution is an aria-expanded on the button proceeding the menu. This gives us click targets, keyboardability, screen reader usage, everything, and it is so very and truly less complex than menu semantics. It also directly 100% translates to a fully accessible mobile solution, which nobody has mentioned I don't believe, but is another terrible aspect of menus for navigation. If we've got a web app, let's talk menus, but other than that, I really can't more strongly state how much I have come around on this issue and firmly understand and believe that aria menus for site navigation are a terrible idea.

@StommePoes
Copy link

@StommePoes StommePoes commented Jul 28, 2020

Extra yes to what Pat said. In my case (and in Gutenberg's!), developers want to add subheadings. Aria menus don't allow headings, and if it's a menuitem with an always-visible submenu, then it's a control that does nothing.
Honestly, I'm not sure why the application menu pattern, which allows divisions (hr), does not allow something to name groups, like optgroup labels.

@StommePoes, do the 3 APG site nav patterns above meet your expectations for visual affordance? If not, please say what needs to be changed to make it clearer

I have to say, the first 2 are pretty easy to figure out. Especially on the first one, once you've managed to get one of the submenus open, moving around sideways exposes the other submenus, making things more discoverable. Yes, despite it being the problematic navigation menu.

The "v" is a visually ambiguous mark especially in these days of developers building their own <select> elements, so I try down or alt+ downArrows on those because of the "v" and it doesn't work on #2 because these are disclosures, but they otherwise work as buttons should.

The last example is very difficult for me to use. Even though I "know the rules", if I use spacebar to toggle, I forget focus is forced elsewhere and hit spacebar to close it but instead the page scrolls and now I can't see the button anymore and I can't scroll the page back up either because now I'm in the menu and my Arrows are taken. I couldn't see when I was focussed on it, so was Tabbing back and forth several times before I figured out where I was and when I was on the widget (but that's just this example missing CSS focus, not intrinsic to the pattern).

I keep expecting to be able to shift-tab back to the triggering button instead of back to the previous Tab stop on the page-- these are all because I'm guessing button behaviour is more ingrained in my fingers than aria menu stuff. That doesn't mean it's a wrong pattern, but as someone who resorts to the mouse when I can't see focus or it takes 1000 Tabs to get somewhere, my fingers and brain had the most issue with #3. It would be nice to have broad sighted-keyboard user testing on each of these patterns. The aria-menu version (#1) was easier for me to grok with my fingers than the navigation button (#3). This might also be because instead of the navigation button version, on websites I find more regular-button (with aria-expanded but usually no haspopup) + listbox.

@patrickhlauke
Copy link
Member

@patrickhlauke patrickhlauke commented Jul 28, 2020

I'm not sure why the application menu pattern, which allows divisions (hr), does not allow something to name groups, like optgroup labels.

because these patterns are based on Windows 95 era UIs (grin)

@aardrian
Copy link
Contributor Author

@aardrian aardrian commented Jul 28, 2020

@JAWS-test

What would you say are the advantages of ARIA menu/menubar?

Easy to implement for developers […]

I have a few years of client audits that tell me not only is that not the case, but devs often find them as hard as or harder to understand and correctly implement than other navigation patterns.

I have never seen a correct ARIA menu navigation pattern in any of my audits.

(adding this comment since we are at the anecdata part of this discussion)

@sinabahram
Copy link

@sinabahram sinabahram commented Jul 28, 2020

@aardrian reports: "I have never seen a correct ARIA menu navigation pattern in any of my audits."

An infinite number of +1s to that. Not once have I encountered a correct initial or even second-attempt at one.

@JAWS-test
Copy link

@JAWS-test JAWS-test commented Jul 28, 2020

If menus are considered problematic for navigation (I can share some of the concerns), the question is whether the problems do not all apply to application menus (https://w3c.github.io/aria-practices/examples/menubar/menubar-editor.html)? If not: what is the difference?

@carmacleod
Copy link
Contributor

@carmacleod carmacleod commented Jul 28, 2020

@JAWS-test I think (?) the difference is mostly in user expectations.

Users expect to tab through navigation links, which is why ARIA menubar (single tab stop, arrow through navigation links) may not be the best choice.

However, users expect to use arrow keys in an application menubar because that's what they use in desktop menubars (and google docs. ;) The menuitems are not links. They don't behave like links. They behave like menuitems. So arrow keys to move through them are not unexpected as long as it's clear that it's an application menubar by placement and visual styling.

@patrickhlauke
Copy link
Member

@patrickhlauke patrickhlauke commented Jul 28, 2020

also, design-wise, application-like menus are indeed fairly standardised in what they contain, as they still mostly mimic native app menus. there's less variety/desire for cramming additional functionality into them, whereas "navigation" is a much looser idea (particularly once you start factoring in things like mega-menus etc, which don't exist as such in native applications)

@mcking65 mcking65 linked a pull request that will close this issue Aug 10, 2020
@carmacleod carmacleod linked a pull request that will close this issue Aug 10, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Linked pull requests

Successfully merging a pull request may close this issue.

You can’t perform that action at this time.