Open aardrian opened 7 years ago
ZoeBijl
commented
7 years ago 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
commented
7 years ago 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
commented
7 years ago @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
commented
7 years ago 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
commented
6 years ago This is related to issues #13 and #287.
straker
commented
6 years ago 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
commented
6 years ago <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.
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.
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
commented
6 years ago 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
commented
6 years ago 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>@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
commented
6 years ago @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
commented
6 years ago 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
commented
6 years ago @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
commented
6 years ago 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
commented
6 years ago @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
commented
6 years ago @mraccess77 commented:
In my opinion navigation structures should not use role menu.
To re-emphasize two earlier points:
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
commented
6 years ago @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:
- 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.
- 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:
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
commented
6 years ago 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
commented
6 years ago 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
commented
6 years ago @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:
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:
nav element containing a list of links at the top of every APG example page.aria-current="page" as a current page indicator.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.
mraccess77
commented
6 years ago @mcking65 Would you entertain changing the items in this example https://www.w3.org/TR/wai-aria-practices-1.1/examples/menubar/menubar-1/menubar-1.html away from a navigation bar to something else like an email application?
aardrian
commented
6 years ago @mcking65 , I have been on the road for the last 6 weeks, so I appreciate your patience with my response time.
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, […]
Yes. That would work for me.
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.
Agreed. However, lack of clarity in the description (which is addressed in our proposed language) and a linked example of site navigation using the menu role (which @mraccess77 has asked you to change) has been read as endorsement of that model. In my experience conducting training, and most recently from a speaker at CSUN, many APG readers do not do any of the deeper digging that your paragraphs (above) offer. They see the APG as a cut-and-paste-ready pattern library (right or wrong).
To be more blunt, my ambition is to aggressively foster remediation of the pervasive brokenness in the web accessibility ecosystem.
I think me opening this issue suggests we are generally aligned
Most of the rest of your comments are beyond the scope of my original issue, but I want to address this:
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.
I feel that this statement makes an assertion that is not backed by data. In other words, I think you may be wrong in many cases / for many users.
I agree that for technically savvy AT users it is true. In my own years of usability testing, most users are not that tech savvy, and your statement does not bear itself out. Navigating a native tab menu, tree grid, menu bar, etc., relies on arcane commands to many. Shift + F10 is handy for power users who already know this from native platforms. As more and more AT users (with restricted finances) move to a mobile-only computing environment, with apps (and desktop applications) that are deployed solely through a web UI, reliance on native platform understanding is less and less valid.
This is, of course, anecdata from my limited research over a decade or so with hundreds of users in different testing environments (a drop in the bucket of users). But it is not a blanket assertion as you are making.
To be more blunt, my ambition is to aggressively foster remediation of the pervasive brokenness in the web accessibility ecosystem… by educating practitioners about how developers and users are actually using the advice we provide.
carmacleod
commented
6 years ago In case it's helpful, I opened https://github.com/w3c/aria-practices/issues/633 to try to address:
I am seeing more and more cases of authors who believe that something must adhere to the APG Something pattern.
The idea is to encourage authors to pause before jumping into a pattern, because maybe there's a perfectly good, accessible, native way to accomplish the task.
Pretty sure @mcking65 would appreciate a pull request for #633, if anyone has the time. Also, please feel free to verify the native-patterns that @MichielBijl and I listed there, and add any that you feel are missing.
aardrian
commented
5 years ago A developer at Twitter has just tried to code a disclosure widget on individual tweets as an ARIA menu. When asked why, the feedback he provided was the exact text I requested be changed when filing this issue.
But according to the desc of a menu it seems much more like that than a disclosure:
https://www.w3.org/TR/wai-aria-practices/#menu
"A menu is a widget that offers a list of choices to the user, such as a set of actions. A menu is usually opened, or made visible, by activating a menu button"
https://twitter.com/CharlieCroom/status/1042798596918132736
Please just make the change I requested. I have been batting down incorrect use of menu roles for the year and a half since I opened this issue. When companies like Twitter encode it in their interface, it not only confuses users, it also justifies further mis-use.
patrickhlauke
commented
5 years ago +1 to what @aardrian said. i know the issue is "controversial", but in line with advice from other corners of W3C https://www.w3.org/WAI/tutorials/menus/ and other experts such as https://www.marcozehe.de/2018/09/22/wai-aria-menus-and-why-you-should-generally-avoid-using-them/ ... it would be good to get ARIA practices to also follow suit.
chigkim
commented
5 years ago I'm a screen reader user, and I run into this practice more often than ever. More developers are just putting menu and menuitem for navigation links. In fact this github also has the problem when you click your name to expand Your profile, repositories, stars, gists... . #user-links > li:nth-child(3) > details > details-menu I know people have a good intention for using aria everywhere, and developers are probably thinking that they're doing extra job to accommodate AT users by putting menu and menuitem roles manually. However, it actually creates an inconvenience by triggering screen reader to go into application mode and disable html navigation keys for screen reader. Maybe menu and menu item should be renamed to more specific (application-menu or desktop-menu,) or have a warning statement in the beginning of description to clarify and discourage this practice.
DavidMacDonald
commented
5 years ago I should probably add a discussion I recently had with a development team. They are creating a main navigation classic mega menu for a major retail chain. They have been pushing very hard on using menubar, menu, menuitem for all of the links on the menu. I am pointing them to this discussion. I think at the current time for a mega menu we should not use these roles. It may be better if we discourage the use of menu roles on main site navigation menus where there are native <ul><li><a> elements. I suggest we amend the navigation menu example to be some other sort of menu.
Either that or we'll really need to put some hard core energy on developing, testing a variety of navigation menus. This pattern library is quickly becoming the defacto standard referenced in legal cases and elsewhere. It is considered a cut and paste library for the majority of users I have encountered. I'm fine with that, but I really would like to ensure there is strong consensus on all patterns presented.
carmacleod
commented
3 years ago See also Terrill Thompson's post about Dropdown Navigation Menus (Feb 2020).
jongund
commented
3 years ago @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
commented
3 years ago @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
commented
3 years ago 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
commented
3 years ago 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
commented
3 years ago @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
commented
3 years ago 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
commented
3 years ago 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
commented
3 years ago @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
commented
3 years ago 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
commented
3 years ago Hi @JAWS-test
Those are the objections. If developers want to use the application menu pattern, they must
JAWS-test
commented
3 years ago 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 https://github.com/w3c/wcag/issues/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
commented
3 years ago @JAWS-test
I think these problems occur with many ARIA patterns.
Potentially relevant: Stronger support / testing / best practices text on every example #1228
carmacleod
commented
3 years ago @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:
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
commented
3 years ago @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
commented
3 years ago What would you say are the advantages of ARIA menu/menubar?
carmacleod
commented
3 years ago 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
commented
3 years ago 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
commented
3 years ago @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
commented
3 years ago 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
commented
3 years ago 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
commented
3 years ago @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
commented
3 years ago @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.
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: