Stop Using ‘Drop-down’

TL;DR: Stop using the word drop-down. Instead choose a term that accurately describes the control you want.

I have worked both with native platform developers and web developers. While control names might differ, if a control was functionally the same then it was not an issue. A TextBox, for example, translates pretty easily to <input type="text"> in HTML. Or at least in 1995 it did.

I’ve also worked with ad agencies as they spun up their web teams. Translating their HyperCard or Director skills meant their lingo also worked its way into web projects. But we could still posit that a hypertext region in a design comp was probably a link in HTML.

The word drop-down (dropdown, drahp-daughn, daft-dolt) was common with both sets of clients. However, if you used the term with one group, you might get a specific control that does not translate to the web. With another group you might get a design that makes a specific control impossible to build.

With broken processes that didn’t get everyone in the room at the same time and without a common understanding of drop-down, we ossified into our current situation.

As you embark on a design or build or specification, it is important to understand what you are producing and why. When you say drop-down, which one of these things 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?

1. <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.

2. 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>.

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. There is more than one way to implement a control that uses the listbox role, with the critical difference being the trigger. See the articles linked at the end.

3. <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.

Until recently, HTML had no equivalent to a native combobox, but the <datalist>/<option> roughly addresses that. Screen readers seem to enjoy announcing it differently depending on, well, reasons — listbox pop-up on iOS, text field on macOS, edit box on Android, type in text in JAWS with IE11, combo in JAWS with Chrome, text pop-up in JAWS with Firefox, and has auto-complete with NVDA.

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.

4. 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 (generally) the listbox role.

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. You may still need to do further testing to identify if you want the ARIA 1.0 combobox, ARIA 1.1 combobox (linked above), or draft ARIA 1.2 combobox.

5. 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.

6. ARIA Menu

If you are trying to recreate a native 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 youfind 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.

7. <details>/<summary>

While <details> and <summary> support in browsers is relatively recent (and absent in IE and legacy Edge), this a handy native element for hiding and showing content. For unsupporting browsers you will still need JavaScript for a polyfill.

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.

8. 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 aria-controls despite falling support) and an associated content container whose visibility is toggled.

The disclosure widget at the ARIA Authoring Practices document is one of the few mature patterns in that note, and you can use it as the basis for your code. The pattern is robust and can even be used for navigation.

Use the term disclosure widget to refer to this pattern.

9. 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.

The accordion widget at the ARIA Authoring Practices document is one of the other mature patterns in that note, which you can use as the basis for your code. You need a <button> with aria-expanded (and aria-controls despite falling support) within a header and an associated content container whose visibility is toggled while also toggling the visibility of the other content containers.

When discussing this pattern, call it an accordion.

10. Fly-out Navigation

Web site navigation has been referred to as drop-downs for years. For evidence of how common it is, and its age, the Suckerfish drop-downs 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.

11. 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.

Otherwordingness

I suspect someone might mention <menu> and <menuitem>, but those elements are deprecated for lack of implementation. I refer you to ARIA menus above if you think you have a use case.

I have heard the term pop-up in place of drop-down. Pop-up is an even more confusing term since it can also mean a tool-tip, a native dialog, a modal dialog, or even a new window (remember pop-unders?). This is not helped when screen readers refer to some <select>-like controls as pop-ups.

If someone asks for a pop-up, you first have to disambiguate (hey, a Wikipedia word!) between a dialog-like thing, a form control, or display widget thing. Then you need to be diligent in what terms you use.

The term menu also gets tossed around when referring to a <select>, combobox, or navigation, all of which contributes to the confusion. There are arguably fewer potential meanings for menu than for drop-down, but you can apply the same logic to try to pare down what anyone means who uses it.

For a deeper dive into the <select>, listbox, or combobox patterns, particularly if you plan to implement any of them, I strongly recommend the following articles by Sarah Higley:

• <select> your poison
• <select> your poison part 2: test all the things

TL;DR

Stop using the word drop-down. Instead choose a term that accurately describes the control you want.

Update: 16 April 2020

In the Nielsen Norman Group post, Listboxes vs. Dropdown Lists, the author describes the difference between two controls based on their visual affordance. Given that the article is talking about these concepts generally, it’s fair to not expect it to use the specific technical terms.

However, in a web context their dropdown example maps to <select> or an ARIA listbox.

Their listbox example maps to <select size="[>0]">, <select size="[>0]" multiple>, side-by-side versions of these controls (for moving items between them), or a collection of checkboxes in a container that may or may not scroll. Or it can map to an ARIA listbox.

The cited example is the product filters on the Sephora site, each of which can be a <fieldset> / <legend> construct with a fixed height that allows scrolling and contains checkboxes.

There is a table at the end of the post to help you identify which of the two patterns may be a good fit for your needs. However given the potential difference in interactions between the possible five distinct ways of coding these, it fails in interaction guidance. For example, is one pattern more cumbersome for a screen reader user? How should one choose when considering keyboard-only users?

From a user experience perspective the article is a handy reference for initial discussions. From a development perspective, it misses an opportunity to disambiguate and offer guidance on specific interactions, potentially continuing the confusion about what these names mean.

Update: 1 July 2021

This post has a sibling now: Stop Using ‘Pop-up’

If you are interested in my take (and alternatives) for the often misapplied term pop-up, then that post is for you. It also uses an image from IKEA.