HTML Guides for menuitem

The WAI-ARIA specification defines strict ownership requirements for certain roles. The menuitem role represents an option in a set of choices and is only meaningful when it exists within the context of a menu. When a menuitem appears outside of a menu or menubar, screen readers and other assistive technologies have no way to determine that it belongs to a menu widget. They cannot announce the total number of items, provide keyboard navigation between items, or convey the menu's hierarchical structure to the user.

This requirement follows the concept of required owned elements and required context roles in ARIA. Just as a <li> element belongs inside a <ul> or <ol>, a menuitem belongs inside a menu or menubar. The relationship can be established in two ways:

1. DOM nesting — the menuitem element is a DOM descendant of the menu or menubar element.
2. The aria-owns attribute — the menu or menubar element uses aria-owns to reference the menuitem by its id, establishing ownership even when the elements aren't nested in the DOM.

It's important to note that ARIA menu roles are intended for application-style menus — the kind you'd find in a desktop application (e.g., File, Edit, View menus). They are not meant for standard website navigation. For typical site navigation, use semantic HTML elements like <nav> with <ul>, <li>, and <a> elements instead.

How to fix it

1. Identify every element with role="menuitem" in your markup.
2. Ensure each one is contained within an element that has role="menu" or role="menubar", either through DOM nesting or via aria-owns.
3. Choose the correct parent role:
   • Use role="menubar" for a persistent, typically horizontal menu bar (like a desktop application's top-level menu).
   • Use role="menu" for a popup or dropdown menu that contains a group of menu items.
4. If you're using menus for site navigation, consider removing the ARIA menu roles entirely and using semantic HTML (<nav>, <ul>, <li>, <a>) instead.

Examples

Incorrect — menuitem without a menu context

This triggers the validator error because the menuitem elements have no parent menu or menubar:

<div>

<div role="menuitem">Cut</div>

<div role="menuitem">Copy</div>

<div role="menuitem">Paste</div>

</div>

Correct — menuitem inside a menu

Wrapping the items in an element with role="menu" resolves the issue:

<div role="menu">

<div role="menuitem" tabindex="0">Cut</div>

<div role="menuitem" tabindex="-1">Copy</div>

<div role="menuitem" tabindex="-1">Paste</div>

</div>

Correct — menuitem inside a menubar

For a persistent horizontal menu bar with application-style actions:

<div role="menubar">

<div role="menuitem" tabindex="0">File</div>

<div role="menuitem" tabindex="-1">Edit</div>

<div role="menuitem" tabindex="-1">View</div>

</div>

Correct — nested menus with dropdown submenus

A menubar with a dropdown menu containing additional menuitem elements:

<div role="menubar">

<div role="menuitem" tabindex="0" aria-haspopup="true" aria-expanded="false">

File

<div role="menu">

<div role="menuitem" tabindex="-1">New</div>

<div role="menuitem" tabindex="-1">Open</div>

<div role="menuitem" tabindex="-1">Save</div>

</div>

</div>

<div role="menuitem" tabindex="-1" aria-haspopup="true" aria-expanded="false">

Edit

<div role="menu">

<div role="menuitem" tabindex="-1">Cut</div>

<div role="menuitem" tabindex="-1">Copy</div>

<div role="menuitem" tabindex="-1">Paste</div>

</div>

</div>

</div>

Correct — using aria-owns for ownership without DOM nesting

When the menuitem elements cannot be nested inside the menu in the DOM (e.g., due to layout constraints), use aria-owns to establish the relationship:

<div role="menu" aria-owns="item-cut item-copy item-paste"></div>

<div role="menuitem" id="item-cut" tabindex="0">Cut</div>

<div role="menuitem" id="item-copy" tabindex="-1">Copy</div>

<div role="menuitem" id="item-paste" tabindex="-1">Paste</div>

Better alternative — use semantic HTML for site navigation

If you're building standard website navigation (not an application-style menu), avoid ARIA menu roles altogether:

<nav aria-label="Main navigation">

<ul>

<li><a href="/">Home</a></li>

<li><a href="/about">About</a></li>

<li><a href="/contact">Contact</a></li>

</ul>

</nav>

This approach is simpler, more accessible by default, and doesn't trigger the validator warning. Reserve role="menu", role="menubar", and role="menuitem" for true application-style menus that implement full keyboard interaction patterns as described in the ARIA Authoring Practices Guide.

An element with role="menuitem" cannot be a descendant of an <a> element because the <a> element already has an implicit interactive role, and nesting interactive or widget roles inside it creates conflicting semantics for assistive technologies.

The <a> element has an implicit ARIA role of link. When a role="menuitem" element is placed inside an <a>, screen readers receive contradictory signals: the outer element says "this is a link" while the inner element says "this is a menu item." The WAI-ARIA specification restricts which roles can appear as descendants of interactive elements to prevent this kind of ambiguity.

The fix depends on what you're trying to build. If you want a navigation menu where each item is a link, apply role="menuitem" directly on the <a> element itself, rather than on a child inside it. The <a> element can accept the menuitem role, which overrides its default link role.

HTML examples

Invalid: role="menuitem" nested inside an anchor

<ul role="menu">

<li role="none">

<a href="/home">

<span role="menuitem">Home</span>

</a>

</li>

<li role="none">

<a href="/about">

<span role="menuitem">About</span>

</a>

</li>

</ul>

Valid: role="menuitem" applied directly to the anchor

<ul role="menu">

<li role="none">

<a href="/home" role="menuitem">Home</a>

</li>

<li role="none">

<a href="/about" role="menuitem">About</a>

</li>

</ul>

Setting role="menuitem" on the <a> element itself gives assistive technologies a single, clear role. The role="none" on each <li> removes the default listitem semantics, which is expected when using the menu pattern since the menu role manages its own item structure.

An element with an interactive ARIA role, such as menuitem or button, is nested inside another element whose role already describes a single control, like a menu item inside a menu item.

ARIA in HTML treats an element with one of these outer roles like a native <button>: it can hold phrasing content, but no interactive descendants. Most of them also have presentational children in WAI-ARIA, so browsers don't expose their descendants to assistive technologies as separate elements. A screen reader announces the outer menu item and reads anything nested inside it as plain text. The arrow-key navigation of a menu can't reach a nested item either.

The validator checks descendants at any depth inside elements with role set to button, checkbox, img, link, math, menuitem, menuitemcheckbox, menuitemradio, option, progressbar, radio, separator, slider, switch or tab. It flags descendants whose role is button, checkbox, combobox, grid, gridcell, listbox, menu, menubar, menuitem, menuitemcheckbox, menuitemradio, option, radio, scrollbar, searchbox, slider, spinbutton, switch, tab, textbox or treeitem.

Nested submenus are the most common cause. A site menu gives each <li> role="menuitem" and puts the submenu, a <ul role="menu"> with its own menu items, inside that <li>. Each submenu then gets one warning for the role="menu" list and one for every item in it. If the <li> elements also hold links, those links get their own warnings, starting with "The element "a" should not appear as a descendant of an element with the attribute "role=menuitem"." The same fix clears all of them.

In the WAI-ARIA menu pattern, a submenu sits next to the item that opens it, not inside it. Give each <li> role="none", put role="menuitem" on the link or button inside it, and place the submenu <ul role="menu"> after that element in the same <li>. Add aria-haspopup="true" and aria-expanded to the parent item so screen readers know it opens a submenu.

If the list is ordinary site navigation, remove role="menubar", role="menu" and role="menuitem" altogether. The menu roles are meant for application menus like the ones in desktop software, and they need scripts that move focus with the arrow keys. A <nav> with nested lists of links and a <button aria-expanded> for each submenu needs no ARIA roles.

Other role combinations have the same fix: keep one interactive role per control. Move the role onto the element that performs the action, or move the inner control out of the outer one.

Invalid example

<ul role="menubar" aria-label="Main">

<li role="menuitem" aria-haspopup="true" aria-expanded="false">

Services

<ul role="menu" aria-label="Services">

<li role="menuitem">Consulting</li>

<li role="menuitem">Training</li>

</ul>

</li>

</ul>

Valid example

<ul role="menubar" aria-label="Main">

<li role="none">

<button type="button" role="menuitem" aria-haspopup="true" aria-expanded="false">Services</button>

<ul role="menu" aria-label="Services">

<li role="menuitem">Consulting</li>

<li role="menuitem">Training</li>

</ul>

</li>

</ul>

Valid example for site navigation

<nav aria-label="Main">

<ul>

<li>

<button type="button" aria-expanded="false" aria-controls="services-menu">Services</button>

<ul id="services-menu" hidden>

<li><a href="/consulting">Consulting</a></li>

<li><a href="/training">Training</a></li>

</ul>

</li>

</ul>

</nav>

An <a> element is nested inside an element with role="menuitem", which ARIA in HTML doesn't allow.

A menu item is a single control. Screen readers announce it as one item in the menu, and the menu keyboard pattern moves focus from item to item with the arrow keys. ARIA in HTML lets an element with role="menuitem" contain phrasing content only, with no interactive elements inside it. A link inside the menu item is a second control, and the menu pattern has no place for it.

When the <a> has an href, the validator reports a second warning for the same element, "The element "a" with the attribute "href" should not appear as a descendant of an element with the attribute "role=menuitem"." Both go away with the same fix. Validator builds from mid 2026 reported this check as an error, with "must not appear" in place of "should not appear".

The usual cause is a list where the <li> has role="menuitem" and the link sits inside it. Move role="menuitem" onto the <a> itself, and give the <li> role="none" to remove its list item semantics. Each menu item is then a single interactive element.

If the list is ordinary site navigation, drop role="menu" and role="menuitem" altogether. The menu roles are meant for application menus like the ones in desktop software, and they expect JavaScript that moves focus with the arrow keys. A <nav> element with a plain list of links needs no ARIA roles.

Invalid example

<ul role="menu" aria-label="Account">

<li role="menuitem"><a href="/profile">Profile</a></li>

<li role="menuitem"><a href="/settings">Settings</a></li>

</ul>

Valid example

<ul role="menu" aria-label="Account">

<li role="none"><a role="menuitem" href="/profile">Profile</a></li>

<li role="none"><a role="menuitem" href="/settings">Settings</a></li>

</ul>

Valid example for site navigation

<nav aria-label="Account">

<ul>

<li><a href="/profile">Profile</a></li>

<li><a href="/settings">Settings</a></li>

</ul>

</nav>