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

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

Remove the menubar, menuitem, and menu roles.
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:

Navigate to https://codepen.io/jimmynotjim/full/VBNGbY/
Turn on voice over (cmd + f5)
Click into the main content to avoid the Codepen chrome
Turn on start reading feature (ctrl + opt + A)
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):

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

About this issue

Original URL
State: closed
Created 6 years ago
Comments: 19 (5 by maintainers)

Most upvoted comments

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.

philwolstenholme on Dec 10, 2020

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.

mcking65 on Jul 19, 2019

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:

Like menubar, it can include support for arrow keys among links.
Like menubar, escape will close dropdowns.
Unlike menubar, it is not a single tab stop; instead every element, when visible, is Tab focusable.
Unlike menubar, it does not support first-letter navigation, e.g., type “c” to move focus to “Campus Tours” in the “About” dropdown.
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.

mcking65 on Jul 19, 2019