In a website's editor or an application's dashboard, a toolbar often lines up several actions next to each other: save, print, share, duplicate. These are not links to other pages, and they are not content to read either, they are commands the user can trigger.
HTML has a tag built for exactly this case, <menu>, which behaves like an ordinary list but signals a different intent: here is a set of actions, not a list of information.
Definition
<menu> groups a series of <li> elements representing commands or actions available to the user, rather than pieces of content to read. Originally meant for the browser's right-click context menus, it kept this role as a container for actions even though its practical use on today's web stays fairly rare.
Visually, a browser renders <menu> exactly like an ordinary bullet list: same indent, same bullet in front of each item. The difference never shows on screen, it lives in the source code and in what the tag communicates to the tools that parse it.
Syntax and attributes
The content model of <menu> is identical to a bullet list: only <li> elements, optionally with script-supporting elements. The old type and label attributes, originally meant to describe native context menus, were dropped from both the specification and the browsers that had experimented with them: <menu> no longer carries any attribute of its own, only the global attributes valid on any tag.
A typical toolbar pairs each command with its keyboard shortcut using <kbd>, which produces markup that is both readable and honest about what each line stands for.
<menu>
<li><button type="button">Save</button> <kbd>Ctrl+S</kbd></li>
<li><button type="button">Print</button> <kbd>Ctrl+P</kbd></li>
<li><button type="button">Duplicate</button></li>
</menu>Difference with an ordinary list
The question comes up often: why not simply write a plain bullet list and save a tag? The answer fits in one word, intent. An ordinary list says "here are some items", <menu> says "here are actions you can trigger".
| Aspect | Plain bullet list | <menu> |
|---|---|---|
| Default rendering | Bullets, indent | Identical, bullets and indent |
| Expected content | Information, content items | Commands, triggerable actions |
| Typical use | Table of contents, list of posts | Toolbar, command menu |
Semantics and accessibility
A classic trap is assuming <menu> automatically turns a list into an application menu, complete with arrow-key navigation and the kind of announcement a screen reader would make on a real software menu. That is not what happens: by default, assistive technology treats <menu> as an ordinary list, nothing more.
Adding the <menu> tag is not enough to get accessible-menu behaviour. For a real interactive menu, with keyboard navigation and closing on Escape, you need to add the right ARIA roles, such as role="menu" on the container and role="menuitem" on each command, then handle the keyboard in JavaScript yourself. Without that work, <menu> stays a plain list for assistive technology.
Where it is actually used today
Real-world use of <menu> stays limited. Browsers dropped the native context menus it was once meant to describe, and most sites keep using a plain bullet list for their toolbars. Where it still earns its place is inside reusable components: a custom control built with <template> can expose its internal list of commands as a <menu>, which makes the role of that block explicit for anyone reading the code later, including yourself six months on.
Outside that kind of component, it is perfectly fine to keep using a plain bullet list for a simple toolbar: the semantic gain from <menu> is real but modest, and it never replaces the accessibility work still owed through ARIA roles and keyboard handling.
Best practices
- Reserve
<menu>for triggerable actions such as save, delete or share, never for navigation links to other pages, which belong under a navigation tag paired with a plain list. - Keep the text of each
<li>short and verb-driven, the way a button label reads, rather than descriptive like an article title. - Do not expect free keyboard behaviour: add the ARIA roles and keyboard handling yourself if the menu needs to act like a real application menu.
Frequently asked questions
Is there any real visual difference between <menu> and a bullet list?
None by default: both render with the same bullets and the same indent in every current browser. The difference lives entirely in the meaning the tag carries for the code and for the tools parsing it, not in how the page looks.
Should <menu> be used for the site's navigation menu in the header?
No, that case belongs to a navigation tag paired with a plain list, since it involves links to other pages rather than commands to trigger. <menu> is reserved for actions, like a toolbar or a command menu, which by nature excludes a site's main navigation menus.
Do the old type="context" or type="toolbar" attributes still work?
No, they disappeared from both the HTML specification and the browsers that briefly experimented with them, Firefox among them. A custom context menu today is built with JavaScript and the right ARIA roles, not with these old attributes, which are now inert.