Be Careful Using ‘Menu’

TL;DR: Be careful when using the word menu. Be certain you have chosen the term that accurately describes the control you want.

If this post looks familiar to you, that is because it is essentially a redress of my 2020 post Stop Using ‘Drop-down’. It is not as divergent as my 2021 post Stop Using ‘Pop-up’. The word menu also maps to an existing role and element (see below), so this post is not titled as strongly as those posts.

As you embark on a design, build, or specification, it is important that you, the stakeholders, and the team understand what you are producing and why. When you say menu, which one of the following terms or concepts do you mean? What about your client? Your designer? Your developer? The user (who calls the help line)? The screen reader? The voice control software?

This post is not for end users. Using these terms with this detail will likely be meaningless to them, especially when visual designs and novel implementations conflate multiple patterns.

1. ARIA Menu

If you are trying to recreate a native operating system menu, as you would get when you right-click with your mouse, then the ARIA menu role is your choice. If you want a native menu similar to what you find in a Windows or Mac application then the menubar role is your pick.

You can get away with referring to either option as an ARIA menu.

When discussing this option, it must be clear that an ARIA menu is for replicating native OS features, not for web site navigation or other general web content purposes. If you need help making your case, I have written in detail at Don’t Use ARIA Menu Roles for Site Nav. Since ARIA menus can only hold menu parts, their utility is very limited.

There are always (probably limited) exceptions. Particularly when you find it performs better with your set of users when compared to other patterns.

2. <menu> and <menuitem>

Even in the Year of Flying Spaghetti Monster 18 (2023 CE), <menu> and <menuitem> still come up in random GitHub repos, StackOverflow answers, and JIRA issues. While originally conceived of as a native context menu, it was not implemented (well, Firefox tried it but dropped support years ago). The <menu> element maps to <ul>, and <menuitem> is deprecated. Do not use them.

If referring to these elements, note they are deprecated.

3. <select>

If your intent is to use a native HTML <select>, then call it a select.

It most accurately describes the technical implementation — which also describes the customization challenges. Though the design challenges may not be as challenging as some think.

If describing the control to a screen reader user, it may be helpful to know that VoiceOver on macOS & iOS and TalkBack on Android will refer to a <select> as pop-up button. JAWS and NVDA refer to it as combobox.

Remember that <select> is a form control, not a navigation tool and not an application menu.

4. <selectmenu>

In an effort to address styling limitations with <select>, a (Google-led) collective known as Open UI proposed the <selectmenu> element. It is not reflected in the WHATWG HTML specification at this time (though, since WHATWG HTML is versionless, it can appear whenever and credibly claim to have always been there).

Google’s Chrome browser (a theme emerges) has added support for the element already, though it is behind flags for now. You can read the Open UI <selectmenu> explainer for details on how it supposed to work and be exposed to assistive technologies.

<selectmenu> is also a form control, not a navigation tool and not an application menu.

To avoid confusing it with the native HTML <select>, call it a select menu and be prepared to say “No, the other one”.

5. ARIA Listbox

ARIA defines roles for composite user interface widgets, which are generally containers for the necessary parts of a complete widget. The listbox role corresponds to the native <select> element. The listbox‘s required children have the option role, corresponding to the native <option>.

An ARIA listbox is also a form control, not a navigation tool and not an application menu.

If you are referring to this construct, call it an ARIA listbox.

The term sets expectations for the implementation and implies a design not constrained by browser defaults the way <select> is.

6. <datalist>

Despite screen readers on Windows referring to a <select> as combobox, the word combobox has a very specific meaning especially to old-school Windows forms developers. In web technology terms, it is analogous to a <select> with a text field.

For years, HTML had no equivalent to a native combobox, but the <datalist>/<option> roughly addresses that. A <datalist> always pairs with an <input type="text">. Screen readers seem to enjoy announcing it differently depending on, well, reasons.

A <datalist> is a form control, not a navigation tool and not an application menu.

To refer to this pattern, call it a datalist.

This will also signal to developers and designers that you are leaning on browser defaults, and therefore manage expectations for visual representation.

7. ARIA Combobox

If you are looking for a combobox, it would be a good idea to identify whether you want it developed with ARIA or with native HTML (see <datalist>). How much custom design is required will probably influence your choice.

In unsupporting browsers, the ARIA combobox role can fill that gap when paired with the required textbox role and the listbox role.

An ARIA combobox is also a form control, not a navigation tool and not an application menu.

To refer to this pattern, call it an ARIA combobox.

The term sets expectations for the implementation and implies a design not constrained by browser defaults the way <datalist> is. If implemented correctly it will also have far better support than <datalist>.

8. Autocomplete

If the control is meant to provide users with suggestions that may not be available in the DOM already, then you will need to clarify further.

If the request is for a control with the autocomplete attribute (perhaps to satisfy WCAG SC 1.3.5: Identify Input Purpose), then that is not a distinct control. That is a feature that the browser can support on existing <input>, <select>, or <textarea> fields.

Otherwise, presuming the previous options are not a fit and the requirements call for an XMLHttpRequest to populate options as you type, then you have a different kind of control. Alternatively, if the control supports matching values the user does not type (such as typing a word in one language and seeing a result in a different language, as in this autocomplete example), then you also have a different kind of control.

For this scenario, knowing you may still need to gather requirements, call it an autocomplete.

9. <details>/<summary>

The <details> and <summary> elements are a handy native method for hiding and showing content. Ideally you use them for content that lives within the page.

Effectively <details>/<summary> are a native disclosure widget. That’s about it. <details>/<summary> are not a lot of other things (I thought them not being a modal was obvious, but people gotta experiment).

You can refer to these generally as details / summary, or details & summary.

A competent web person will know you are talking about an interactive widget, not a form control.

10. Disclosure Widget

Think of this as the ARIA version of <details> and <summary>, but in this case you are not using ARIA roles to enhance generic controls. You need a <button> with aria-expanded (and optionally aria-controls) and an associated content container whose visibility is toggled.

I provide an overview of disclosure widgets, including code samples, uses, and assistive technology notes. The pattern is robust and can even be used for navigation.

Use the term disclosure widget to refer to this pattern.

11. Accordion

Similar to the disclosure widget pattern, there is no accordion role defined in ARIA. Unlike the disclosure widget, there is no corresponding native HTML element. The ARIA tab pattern, even the vertical one, is not a fit because tab panels do not collapse to reclaim space. That being said, ensure your need does not map to the ARIA tab pattern.

Essentially this is no more than a group of disclosure widgets given a group label. Typically only one is expanded at a time and often their overall height is restricted — but these are not requirements. I provide a sample accordion in my disclosure widgets post.

When discussing this pattern, call it an accordion.

12. Fly-out Navigation

Web site navigation has been referred to as drop-down menus for years. For evidence of how common it is, and its age, the Suckerfish drop-down menus were released in 2003 and leaned on an already common term.

If you are looking for navigation where tabbing or mousing through the top-level options reveals nested options, then we need a more meaningful term. The WAI provides tutorials for assorted patterns, and the Fly-out Menus fits. It is not a new term, existing since before Suckerfish.

If you have navigation that generally fits this pattern, refer to it is fly-out or fly-out navigation.

13. ARIA Trees

ARIA has a compound widget called a tree. It’s essentially a nested list that allows collapsing and expanding. It borrows heavily from native operating system folder and file management interfaces.

It has more in common with an ARIA menu than other patterns here. It exists as a single tab-stop, relying on arrow key navigation. It has a restricted set of roles it can contain. It does not immediately make sense to many (most?) users. It should not be used for site navigation, despite APG creating a tree-based site navigation demo anyway (that works poorly for touch and AT users, when supported, during human testing).

Refer to this as an ARIA tree.

Do not confuse this with treegrid, which is definitely not a menu in any way.

14. popover

Yes, there is now such thing as popover (no hyphen). Almost. In January 2021, a team lead by Microsoft proposed a new element — <popup>. Then it went through the Open UI folks and became the popover attribute, recently added to WHATWG HTML and supported only by Chrome behind a flag.

Regardless, popover does not bring any semantics along with it, nor does it provide interactions. Instead, an element with popover will appear above other elements (z-index) without concern for the bounds of its container. It also will dismiss if another node with popover opens or the user hits Esc. It is not a menu.

Refer to this as popover. Or pop-over. I still use a hyphen because I am weird and I don’t want people to pronounce it as popo-ver.

15. Custom Display Selector

This is sort of a catch-all. I have seen developers come up with all methods of making controls that essentially work by hiding some stuff, then showing that stuff by animating or popping some container into existence. These are generally inaccessible and this might be a great opportunity to make sure you choose something that conforms to one of the patterns above.

If you find yourself venturing into this territory, probably stop. Go back and figure out what the requirements truly are, as opposed to relying on assumptions or a weird desire to invent a new pattern that nobody will understand.

When discussing this approach, call it consulting.

TL;DR

Be careful when using the word menu in your projects. Be certain you have chosen the term that accurately describes the control you want.