Menu

In its closed state, the menu button has aria-expanded="false" and tabindex="0", while all of the menu items have tabindex="-1".

1<button id="actions-btn"
2    aria-controls="actions-menu"
3    aria-haspopup="menu"
4    aria-expanded="false"
5    tabindex="0">Actions
6</button>
7
8<div id="actions-menu" role="menu" aria-labelledby="actions-btn" hidden>
9    <button role="menuitem" tabindex="-1">
10        Copy
11    </button>
12    <button role="menuitem" tabindex="-1" disabled>
13        Paste
14    </button>
15    <hr />
16    <button role="menuitemcheckbox" tabindex="-1" aria-checked="false">
17        Show preview
18    </button>
19    <hr />
20    <fieldset aria-label="Text size">
21        <button role="menuitemradio" tabindex="-1" aria-checked="true">
22            Small text
23        </button>
24        <button role="menuitemradio" tabindex="-1" aria-checked="false">
25            Large text
26        </button>
27    </fieldset>
28</div>

In its open state, the menu button has aria-expanded="true" and tabindex="-1", while one of the menu item buttons has tabindex="0".

1<button id="actions-btn"
2    aria-controls="actions-menu"
3    aria-haspopup="menu"
4    aria-expanded="true"
5    tabindex="-1">Actions
6</button>
7
8<div id="actions-menu" role="menu" aria-labelledby="actions-btn">
9    <button role="menuitem" tabindex="0">
10        Copy
11    </button>
12    <button role="menuitem" tabindex="-1" disabled>
13        Paste
14    </button>
15    <hr />
16    <button role="menuitemcheckbox" tabindex="-1" aria-checked="false">
17        Show preview
18    </button>
19    <hr />
20    <fieldset aria-label="Text size">
21        <button role="menuitemradio" tabindex="-1" aria-checked="true">
22            Small text
23        </button>
24        <button role="menuitemradio" tabindex="-1" aria-checked="false">
25            Large text
26        </button>
27    </fieldset>
28</div>

Impact: Critical

Using an incorrect or invalid role in a menu or menubar causes assistive technologies to misrepresent the widget’s purpose and keyboard-interaction model to users.

• Set the appropriate role of menu or menubar on the menu container.
• Set the appropriate role of menuitem, menuitemcheckbox or menuitemradio on each action-triggering element in the menu.
• Group menu items as needed with a <fieldset> element or other element with role="group".
• Separate groups of menu items as needed with an <hr> element or other element with role="separator".

ARIA roles should not be arbitrarily applied to semantic HTML elements. Refer to the W3C recommendation ARIA in HTML for the appropriate use of ARIA with semantic HTML elements.

Impact: Serious

Ensure the menu container directly owns, or owns through a group element, at least one valid menu item role. Elements with other roles, such as button or option, do not satisfy this requirement.

Impact: Serious

As composites, elements with role=menu or role=menubar do not have a default label nor can they be provided one with the HTML label element. Provide an accessible name for every menu and menubar with an ARIA attribute:

• Use aria-labelledby to reference the id of a visible label or the triggering button.
• Use aria-label when no visible label is available.

1<!-- Labeled by its trigger button -->
2<ul role="menu" aria-labelledby="file-menu-btn">
3    ...
4</ul>
5
6<!-- Labeled directly -->
7<ul role="menubar" aria-label="Application menu">
8    ...
9</ul>

Impact: Critical

The accessible name for a menu item is most commonly derived from its text content. When a menu item contains only an icon, provide a name via aria-label or by including visually hidden text.

In this example, JavaScript was used to add button functionality to an <li> element.

1<li role="menuitem" aria-label="Delete file">
2    <svg aria-hidden="true" focusable="false">...</svg>
3</li>

Best practice.

Impact: Serious

Menu items within the same menu should have unique accessible names. When two or more items share the same name, users cannot distinguish between them, which creates a confusing and potentially error-prone interaction for screen reader users navigating by item name.

If duplicate item labels are intentional (for example, multiple "Edit" items for different targets), provide additional context using aria-describedby or by incorporating the target’s name into each item’s accessible name, for example, “Edit document” and “Edit template.”

Impact: Critical

Ensure that each menuitemcheckbox and menuitemradio has an aria-checked attribute with a "true" or "false" value consistent with its state.

Impact: Critical

The aria-checked value of a menuitemcheckbox or menuitemradio must change when toggled with the Space key.

Impact: Serious

Impact: Serious

The disabled HTML attribute is a feature of native form controls and interactive elements such as buttons. Applying disabled to a generic element such as a <div> or <li> used as a menu item has no semantic or functional effect. JavaScript must be used to disable custom menu items and use aria-disabled="true" to programmatically communicate the disabled state to assistive technologies.

Impact: Serious

Applying conflicting disabled indicators—for example, inconsistently setting the disabled HTML attribute and aria-disabled="true" or styling an item as visually enabled while aria-disabled="true" is set. Doing so creates an inconsistent experience between what sighted users see and what assistive technologies report. Ensure the visual presentation of a menu item’s disabled state matches its programmatic state exactly.

Best practice.

Elements referenced by the aria-owns attribute on a menu or menubar element should have an allowed child role of menuitem, menuitemcheckbox, menuitemradio, group or separator.

If the owned elements roles are incorrect, screen readers can misinterpret the relationships within the menu, which can confuse users.

Best practice.

While aria-owns can define a parent-child relationship between elements that are not nested in the DOM, it is often poorly supported by assistive technologies and can produce an unpredictable reading order. For menus, it is best practice to use standard DOM nesting: place menuitem elements as direct descendants of the menu or menubar container, or nest them within a group element that is itself a child of the container.

Impact: Serious

Focus behavior within the menu must be predictable and follow the expected arrow-key navigation pattern. If focus moves to unexpected elements, skips items, or behaves inconsistently when a user navigates with arrow keys, the menu is not reliably operable by keyboard. Ensure that focus follows a consistent, sequential path through all enabled menu items and that no item is bypassed unexpectedly.

Impact: Moderate

Menu items should not contain nested focusable elements (such as buttons or links) that are independently reachable via Tab or arrow keys. Focusable children inside a menuitem are redundant and disruptive: they interfere with the menu’s managed focus pattern, may trap keyboard users, and are likely to be ignored or misread by screen readers.

If a menu item requires a secondary action, consider placing it outside the menu or implementing it as a separate menuitem.

Impact: Critical

The menu component itself, or one or more of its items, is not reachable through keyboard interaction. A menu that keyboard users cannot reach or navigate is entirely inaccessible to those users. Ensure that the menu trigger is in the page’s Tab sequence and that all enabled menu items are reachable via arrow keys once the menu is open.

The tester was unable to evaluate reverse (Shift+Tab) keyboard navigation for this menu. This may occur when another focus sequence or keyboard operation test have failed. Manually verify that:

• Pressing Escape closes the menu and returns focus specifically to the element that opened it.
• Pressing Tab closes the menu and moves focus to the next focusable element in the page’s tab sequence (not necessarily the trigger).
• Pressing Shift+Tab closes the menu and moves focus to the previous focusable element in the page’s tab sequence.
• In no case is focus lost or sent to the document body.

The tester attempted to navigate the menu using arrow keys but was unable to do so. This may indicate that arrow key event handlers are missing or not functioning correctly, or that the menu items are not receiving focus. Verify that keydown event listeners are registered on the menu container and that they correctly move focus between menuitem elements in response to ArrowUp and ArrowDown (or ArrowLeft and ArrowRight for a horizontal menubar).

Impact: Minor

Ensure that items with aria-disabled="true" are still reachable via arrow key navigation and are announced by screen readers as disabled.

Impact: Critical

After navigating within a menu or activating a menu item, focus must move to a predictable location. Unexpected focus shifts—such as focus jumping to an unrelated part of the page, returning to the top of the document, or disappearing entirely—disorient keyboard and screen reader users. Ensure that:

• When a menu item is activated, focus moves to the expected location (typically the trigger, or the newly revealed content).
• When a menu is closed without making a selection, focus returns to the control that opened it.
• Focus is never lost (sent to <body> or dropped entirely).

The tester was unable to complete an evaluation of arrow key navigation for this menu. This typically occurs when the menu is not open during testing, the menu items are not receiving keyboard events, or focus management prevents the test runner from simulating arrow key interaction. Manually verify that all menu items are reachable via ArrowUp and ArrowDown keys (or ArrowLeft and ArrowRight for a menubar).

The aria-orientation attribute accepts only "horizontal" or "vertical" as valid values. An invalid value (for example, a misspelling or a custom string) is ignored by assistive technologies, which may then fall back to an incorrect default and communicate wrong key behavior to users. If aria-orientation is used, verify that its value is exactly "horizontal" or "vertical".

Impact: Serious

The aria-orientation value does not match the menu’s visual or functional orientation. For example, a menu that lays out its items horizontally but has aria-orientation="vertical" will cause screen readers to instruct users to use the wrong arrow keys to navigate. Ensure the aria-orientation attribute accurately reflects the rendered layout:

• role="menu" has an implicit aria-orientation of "vertical". Only set aria-orientation="horizontal" when the menu is rendered horizontally.
• role="menubar" has an implicit aria-orientation of "horizontal". Only set aria-orientation="vertical" when the menubar is rendered vertically.
• Omit the attribute entirely when it matches the implicit default for the role.

A menuitem that should have opened a submenu failed to do so. Such a menuitem should function as a menu button and satisfy the tests for Menu Control Sanity in the Menu Button entry.

In addition to the possible issues listed there, this test could fail if the submenu fails to open on a Arrow Right or, if the parent menu’s orientation is horizontal, Arrow Down key action on the parent menu’s triggering menuitem.

Impact: Minor

Interactive elements such as buttons, links, or form controls with in a menu or menubar container that do not have the role of menuitem, menuitemcheckbox or menuitemradio are unexpected and can break the menu’s focus management and reading order.

Screen readers may expose these elements in ways that are inconsistent with the menu’s interaction model, confusing users about the available actions. Ensure that all interactive content within a menu is wrapped in an element with an appropriate menu item role (menuitem, menuitemcheckbox, or menuitemradio).

The keypress event is deprecated and its behavior is inconsistent across browsers, particularly with non-Latin input methods (IME). For menu keyboard handling, use keydown events instead. The keydown event fires for all keys, including arrow keys, Escape, Enter, and Space, and is consistently supported across browsers and assistive technology combinations.

1menuContainer.addEventListener("keydown", (event) => {
2    switch (event.key) {
3        case "ArrowDown":
4            focusNextItem();
5            event.preventDefault();
6            break;
7        case "ArrowUp":
8            focusPreviousItem();
9            event.preventDefault();
10            break;
11        case "Escape":
12            closeMenu();
13            triggerButton.focus();
14            break;
15    }
16});