Navigation / Menu: Site navigation or application-style menu is missing appropriate roles and/or attributes

Rule

The name, role, value, states, and properties of user interface components MUST be programmatically determinable by assistive technologies.

Background

Every user interface control must have a role along with any applicable states and properties so that screen reader users know how to interact with the control. Native HTML elements - such as <button>, <a>, <input>, <select> - already have a role, and their necessary states and properties - such as the checked/unchecked state of a checkbox - are automatically conveyed so nothing more needs to be done. If you create a custom version of a native HTML element or a custom control or widget that does not have a native HTML equivalent, you must add the relevant role(s) and any applicable states and properties using ARIA as well as expected keyboard interactions.

How to Fix

Fix this issue by doing ONE of the following:

1. If the widget's function is navigation such as in the header of a page:

a. Enclose the navigation controls in a <nav> element. b. Use nested list markup to structure the buttons and links. c. Use <button> elements for any navigation elements that expand/collapse a navigation submenu. d. Use aria-expanded="true" or "false" on the <button> to indicate submenu visibility. e. Ensure that the hidden submenu content is not available to sighted users or to screen reader users until it is exposed by the expander button.

2. If the widget's function is similar to a software application menu, follow the ARIA menu design pattern including expected keyboard interactions at: https://www.w3.org/WAI/ARIA/apg/patterns/menubar/