Foundation-sites: [Dropdown Menu] Incorrect use of aria menu roles

[jimmynotjim]

The aria menu roles are intended for application menus, not navigation menus, and are problematic with Apple's Voice Over features. WebAim provides this guidance:

"If the navigation links at the top of a webpage have incorrectly been assigned an ARIA role='menu' (which is appropriate for application menus, not for navigation menus), this triggers forms mode, and the screen reader user cannot read with the arrow keys. The same thing can occur with other ARIA roles such as tab, dialog, grid, and toolbar."

_Source_ - https://webaim.org/blog/three-things-voiceover/ (__ARIA, screen reader modes, and VoiceOver__)

Overall, menu roles should be avoided for most websites, due to the nature of standards based web navigation.

Expected Behavior

When navigating the dropdown menu using Voice Over's Start reading feature the navigation items should only be read aloud once.

Current Behavior

When navigating the dropdown menu using Voice Over's Start reading feature the navigation items are read twice due to the use of role=menuitem.

Possible Solution

1. Remove the menubar, menuitem, and menu roles.
2. Update the documentation to show navigation menus should always be wrapped in a nav element.

Test Case and/or Steps to Reproduce (for bugs)

How to reproduce:

1. Navigate to https://codepen.io/jimmynotjim/full/VBNGbY/
2. Turn on voice over (cmd + f5)
3. Click into the main content to avoid the Codepen chrome
4. Turn on start reading feature (ctrl + opt + A)
5. Voice Over reads the text content of each link twice, once as the menu item, and again as a link
   
   

Context

I discovered the aria menu roles while working on GoFundMe's navigation which relies on Foundation's dropdown menu.

Your Environment

• Foundation version(s) used: Foundation 6
• Browser(s) name and version(s): Any browser on Mac
• Operating System and version (desktop or mobile): macOS 10 (High Sierra) but I have observed this issue on every recent version of OSX and macOS.
• Link to your project: http://www.gofundme.com

Checklist (all required):

• [x] I have read and follow the CONTRIBUTING document.
• [x] This is a bug report or a feature request.
• [x] There are no other issues similar to this one.
• [x] The issue title is descriptive.
• [x] The template is fully and correctly filled.

[ncoden]

Related to the discussions in https://github.com/zurb/foundation-sites/pull/11440

[jimmynotjim]

This might be a good reference for both this issue and #11440

http://adrianroselli.com/2017/10/dont-use-aria-menu-roles-for-site-nav.html

Aria roles should be limited to fixing markup mistakes rather than being used by default. Since Foundation seems to keep to semantic markup, I don't really see a valid reason for relying on them in most situations.

[ncoden]

@jimmynotjim

I read this article and I confirm you this is a good reference. You can notice I referenced it in #11440.

IMHO most aria roles provide additional intormations to assistive tools like related elements and proposed keyboard interactions. @mcking65 words are quite helpful:

When choosing the pattern to use, one of the most important considerations is the keyboard interaction model. If you are not implementing a menu-like or tree-like keyboard interaction model, then do not use those roles and their associated patterns as described in the ARIA Authoring Practices. If you are implementing one of those keyboard interaction models, then please use the appropriate pattern so that screen reader users will be aware of the interactions that are supported. Also, please provide visual design that helps sighted users be aware of the keyboard interactions that are available.

I'll try to resolve #11440 first then will take a look at this issue after. Depending on what will be decided, we may have (or not) to rework on all the Foundation menu components.

[jimmynotjim]

@ncoden Yep, if your default markup creates a good keyboard experience, then aria roles aren't really necessary, but if there are issues that are impossible to work around, for whatever reason, that's when they start to come into importance very quickly.

Take this example, it uses the Foundation grid for the layout but a custom menu I built to work through some of the issues we're seeing at GoFundMe using regular standard markup for as much as possible (it's only built for large screens at the moment).

https://codepen.io/jimmynotjim/full/qyGaWL/

You'll notice that I changed the trigger interaction to click rather than hover. In my experience determining the user's intent is most important and hover can be very ambiguous, plus it can be difficult for users who have dexterity issues and can't easily keep a mouse over the target. If you test with Voice Over you'll find it relies on the regular enter + tab interactions rather than the custom arrow up/down + escape interactions provided by role=menu.

If you're looking for help, I may be able to contribute in some off hours.

[jimmynotjim]

I read this some time ago, but just re-read it to fill in some gaps, it's got a lot of helpful info to understand the correct use of aria menus as well as options for navigation menus https://inclusive-components.design/menus-menu-buttons/

[ncoden]

@jimmynotjim I read it too, and referenced it in #11440. It was also published on Smashing Maganize there: https://www.smashingmagazine.com/2017/11/building-accessible-menu-systems.

Take a look at the "The menu and menuitem roles" section:

<ul role="menu">
  <li role="presentation">
    <a href="/" role="menuitem">Home</a>
  </li>
</ul>

What we’re left with is a kind of hybrid component, which isn’t quite a true menu but at least tells users whether the list of links is open, thanks to the aria-expanded state. This is a perfectly satisfactory pattern for navigation menus.

The following menu example from the W3C uses the same pattern (except for the presentation role). Take a look: https://www.w3.org/TR/wai-aria-practices-1.1/examples/menubar/menubar-1/menubar-1.html.

However, I feels like repeating myself there. I will not reply on any further messages on this issue until #11440 is resolved. You are welcome to join the conversation. 😄

[mcking65]

Hope I'm not sounding like a broken record ... just a note of caution ... The opening statement in this issue is not accurate:

The aria menu roles are intended for application menus, not navigation menus, and are problematic with Apple's Voice Over features.

W3C resources, that define ARIA and its use illustrate that 1) there is no such limitation on the use of ARIA menus, and 2) they are well supported by VoiceOver on both Mac and iOS.

Simple things first ... test the navigation menu button example in the ARIA authoring practices with VoiceOver.

Expected Behavior

When navigating the dropdown menu using Voice Over's Start reading feature the navigation items should only be read aloud once.

Current Behavior

When navigating the dropdown menu using Voice Over's Start reading feature the navigation items are read twice due to the use of role=menuitem.

The current behavior in both Safari and Chrome is that there is no double reading.

BTW, while you can test with ctrl-opt-a, that does not mirror what a typical VoiceOver user is most likely to do. After opening the menu with enter, space, or ctrl-opt-space, the typical VoiceOver user is more likely to use ctrl-opt-rightArrow or down arrow to navigate the menu.

Statements like the following from inclusive components do not accurately represent the intent of ARIA:

ARIA menus are not designated for navigation but for application behavior.

The ARIA menu specification specifies a type of behavior, using application menus as a illustrative model, but it does NOT tell you what types of choices or functions that a menuitem can offer to users. When you make an element that pops up a list of choices by activating it with enter, and the user can move through that list of choices with arrow or letter keys and then press enter to activate one and make the popup disappear, then you have made a menu and you SHOULD implement the ARIA menu markup. That means, use the menu pattern even if the choices in that menu open a different web page. ARIA widget roles describe interaction models, not content.

That statement also implies that native application menus do not include navigation functions. I can't think of very many native applications that do not include navigation functions in their menus. Consider the Apple menu that takes you to system information, system preferences, etc. What about a browser menu that allows you to go to the favorites window, the history window, or a help window? Those are all navigation functions. One of the primary purposes of native application menus has always been navigation.

What if you make a list of choices that flies out but then the user has to tab through the choices? Do not use the ARIA menu pattern. The ARIA disclosure pattern is likely more suitable.

It is fine to debate whether ARIA menus, ARIA disclosures, or any number of other ARIA patterns are best for navigation. But, there is nothing about ARIA that prevents you from using menus for navigation functions.

For years, ARIA has been poorly supported by screen readers, and as a result, it has also ben widely misunderstood, even across much of the accessibility community. That is all starting to change. More and more of ARIA is usable. The APG task force is working hard to accelerate improvement, and more projects to help with that are in the works. But, as cautioned in the Read Me First section of the APG, you do need to test, test, test.

One other point ... Please do not use this statement as a guiding principle; it will lead to incorrect decisions:

Aria roles should be limited to fixing markup mistakes rather than being used by default.

You need ARIA by default except when both the following are true:

1. Every interactive element on a web page is made with native HTML form elements, e.g., input, button.
2. The accessibility semantics needed to describe all JavaScript enhancements can be provided by HTML attributes.

While you should never use more ARIA than is appropriate, you should not use less than is needed to make good quality accessibility. The purpose of ARIA is to enable people to make rich internet applications accessible by filling the semantic gaps between native host languages and the rich GUI experiences native host languages are not designed to provide. For example, HTML is not designed to provide the accessibility semantics needed to make an interactive tree or grid accessible.

[ncoden]

ARIA widget roles describe interaction models, not content.

👍

[jimmynotjim]

@mcking65 Thanks for the explanations, there's so much contradicting info out there, it's good to hear from a W3C author. Two questions:

ctrl+opt+a

Have you found users don't use ctrl+opt+a to auto-read the available page content or only that they don't use it for reading the content within an expanded menu? I was under the impression that ctrl+opt+a is an often used command and users will stop auto-reading to interact with tab items as Voice Over comes across them.

The issue I was finding is that all the top level li elems that are exposed to the user by default with the Foundation dropdown menu have menuitem roles and are read twice without any further interaction from the user. Related, should menuitem only be used on the items within a navbar that themselves have children? In the CodePen example the last two items are links without any sub-menu, but the W3C navbar example does not account for a mix of standard links and sub-menu parents at the top level, only within the hidden sub-menus.

The necessity of aria roles

I agree with your final paragraph, and I shouldn't have stated any markup that requires aria attributes are mistakes, but it does seem the recommended example from the Inclusive Components post using true button elems with aria-expanded attributes removes the need for menu roles. Have you found that there are issues with using this pattern? I've tested it with Voice Over (but unfortunately not JAWS due to lack of PC) and it seems to be easy to navigate using typical tab plus enter inputs and found no issues with ctrl+opt+a. Here's a demo on CodePen.

[JeremyEnglert]

@mcking65 is spot on. The menus work fine as is.

_But_ in the case of Foundation, I think role="navigation" makes much more sense.

"The navigation landmark role is used to identify major groups of links used for navigating through a website or page content." - https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Roles/Navigation_Role

Also, the dropdown menus most likely need aria-expanded attributes added.

[mcking65]

The ARIA Authoring Practices Guide now includes an Example Disclosure for Navigation Menus.

This is an alternative pattern for site navigation bars. Comparing it to the menubar pattern:

1. Like menubar, it can include support for arrow keys among links.
2. Like menubar, escape will close dropdowns.
3. Unlike menubar, it is not a single tab stop; instead every element, when visible, is Tab focusable.
4. Unlike menubar, it does not support first-letter navigation, e.g., type "c" to move focus to "Campus Tours" in the "About" dropdown.
5. Unlike menubar, Because it uses really basic semantics that have been supported in browsers by screen readers for a long time, the disclosure pattern works correctly with any screen reader.

The reason it is not a single Tab stop and does not support first-letter navigation is because the dropdown is a list of links, not a widget designed to intercept keyboard input from users of screen readers that have an interaction mode, e.g., JAWS forms mode.

[JeremyEnglert]

Matt,

First off - thank you for all of your help (and for everything else you do)! I'm learning a ton from your posts.

In the "Example Disclosure for Navigation Menu" you posted, it appears a <button> is used for the top-level dropdown - is that a requirement?

If so, how would you treat top level items that _do not_ have a dropdown?

[mcking65]

Matt,

First off - thank you for all of your help (and for everything else you do)! I'm learning a ton from your posts.

Thank you, and you're welcome!!

In the "Example Disclosure for Navigation Menu" you posted, it appears a <button> is used for the top-level dropdown - is that a requirement?

Yes, a button with aria-expanded set to reflect the state of the dropdown is the core feature of the pattern. You could use a link, div, or span with role button if that is necessary.

If so, how would you treat top level items that _do not_ have a dropdown?

They would be ordinary links with no additional ARIA.

[charmarkk]

So glad to have run into you over here @mcking65 - I was _literally just_ emailing with our designer about this being a problem and how to fix it (or file a bug).

[DanielRuf]

Hi @mcking65,

Do you want to provide a PR so we can fix this?

[mcking65]

Hi @mcking65,

Do you want to provide a PR so we can fix this?

Sorry, hands over full over at aria-practices.

[JeremyEnglert]

I think the current menu is _technically_ correct. But lets keep all of this in mind when reworking the menus for V7.

[charmarkk]

I'm a little concerned and disappointed at this being closed, as it seems like the fix should be just moving a couple things around in the JS (but then I'm not a super skilled programmer). I'm not sure I'd call it technically correct, as I have a specific use case where the ARIA (as is) is actively interfering with a keyboard's and/or screen reader's ability to use the menu appropriately.

Or, when is V7 due out? If nothing else, I'd like to update my designer and devs. :)

Edit: well perhaps this specific issue is closable, and what I have is something closely related but separate. Nonetheless, would like to know about V7. Probably time for sleep. ;)

[philwolstenholme]

A client's site of ours has been audited under WCAG 2.1 and the auditors pointed out this issue.

The roles "menubar" and "menuitem" should be reserved for navigation components in widgets. Remove these, and the "role="none" attributes from list items, so that navigation elements are links in an unordered list. The controls are not announced as links by screen reader software. Experienced and confident users will assume from context that they are links - but may not think they are “working” because they aren’t announced as links. Inexperienced or unconfident users may be a bit more confused.