WAI-ARIA (Web Accessibility Initiative - Accessible Rich Internet Applications) markup can improve accessibility by providing semantic definitions that aren’t native to HTML. Unfortunately, many developers ignore the first rule of ARIA: If you don’t need ARIA, don’t use it.
If you decide to use ARIA, you’re making a commitment to test your work. Misused ARIA can create significant accessibility issues for people who use screen readers and other assistive technologies (AT).
The ARIA menu role (role=”menu") is one of the most commonly misused roles. It’s an appropriate option when the user is presented with a list of choices, similar to how a menu would appear on a desktop application.
Opening the menu will move the keyboard focus to the first item on the menu. Menu widgets usually have a vertical orientation and can be expanded to reveal more menu items. However, ARIA menus are not intended for navigation menus or other elements that can be defined with semantic HTML.
Here’s how to avoid a few common mistakes when using ARIA’s menu role.
Don’t use role=”menu" for basic navigation menus or simple collections of links
Developers often assume that role=”menu" applies to any menu — including simple lists of links in the website’s header. Remember, the menu role is intended for widgets with presentations that resemble desktop applications.
A basic collection of links doesn’t fit that description, so doesn’t need ARIA markup. AT users can navigate lists of hyperlinks with basic keyboard commands, and keyboard focus will move in a predictable way. Plain old semantic HTML (or POSH) is the better tool for the job.
And while the menu role is frequently used for navigation menus, that’s not always ideal for real-life users. Consistent navigation mechanisms are critically important; if the navigation menu doesn’t work, people can’t operate your website.
Unless ARIA is absolutely essential, using it to apply semantics to a navigation menu doesn’t make much sense — if you make a mistake, your website may be completely unusable for AT users.
Related: 4 Mistakes to Avoid When Using ARIA Roles
Don’t use role=”menu" for visually persistent menus
If your widget remains on the user’s screen, the menubar role may be a more appropriate choice. The menubar role is intended for widgets that present choices to the user with a persistently visible, horizontal bar of commands.
Both the menu and the menubar roles require some management of visual focus. Each role may also contain child submenus, and menu items may be defined with various ARIA roles (such as menuitem, menuitemradio, and menuitemcheckbox).
Review the World Wide Web Consortium (W3C)’s guide for using ARIA menus to make sure that you’re using the appropriate roles, states, and properties for your widget.
Make sure your menu is labeled
When a screen reader encounters an ARIA menu, it should announce “Menu Item,” followed by the label for the menu. Needless to say, if your menu doesn’t have an appropriate label, users may not understand its purpose.
- If a visible label is present, use aria-labelledby.
- If there is no visible label, use aria-label.
Accessible names and labels are crucial for screen reader accessibility, so review them carefully when testing your markup.
For additional guidance, read: How Accessible Names Can Help (Or Frustrate) Your Users.
Remember, ARIA is designed for complex, rich, or dynamic content
If you have any concerns about your ARIA markup, be careful. Test your markup with a variety of user agents and assistive technologies. Make sure that the keyboard focus moves in a predictable way, and that each menu item (no matter how nested) can receive focus.
It’s also important to remember that WAI-ARIA support may vary depending on the user’s choice of screen reader and web browser. That’s why HTML is generally a better choice.
With that said, if you’re building a desktop-like interface, WAI-ARIA can provide an improved experience for your users. We strongly recommend working with an accessibility partner when using WAI-ARIA.
Accessibility experts can help you consider the needs, preferences, and expectations of people with disabilities from the first stages of design — and prevent frustrating barriers from becoming a permanent part of your product. For guidance with a specific issue, send us a message to connect with a subject matter expert.
