Stop Using ‘Drop-down’

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

Illustration of IKEA stepping into a chest of drawers that is not secured to the wall, so it is falling on him.

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>

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

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

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

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

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

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.

Tip 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).

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

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

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

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

Tip When discussing this approach, call it consulting.

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:


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.



A lot to expect from different sets of people.

TrySpace; . Permalink
In response to TrySpace. Reply

The alternative is to not try.


Many of those seem to overlap quite a bit.

Also, clear simple examples per type would be great.

In response to Wes. Reply

The overlap is why I wrote this and also why I offer links for each type, most of which have examples.

In response to Adrian Roselli. Reply


In response to asd. Reply



Is that not what requirements are for?

Dropdown.. yeh ok technical scoping wouldn’t describe it as such if that’s not what is being created by a developer but it’s easier to understand for non technical folk?

In response to Mike. Reply

See this post for reasons why even non-technical folks could benefit from knowing and being explicit in requirements.


Damn, i wish i could get these minutes that i wasted reading this “problem” back

Ponytailed IT guy; . Permalink
In response to Ponytailed IT guy. Reply

What about the extra minutes you wasted leaving this comment?


Oh for fucks sake. Just call it a drop down. Everyone, every one understands what a drop down is. Aria what? I can’t even remember what you suggested already. For fucks sake. Just take it easy, man.

Donald Snaders; . Permalink
In response to Donald Snaders. Reply

Clearly not everyone, every one.

In response to Donald Snaders. Reply

Aria-info is rather important to certain group of users. You know, the blind fucks who make your life slightly more difficult by their total inability to see (as in VISUALLY perceive) what kind of control you have produced on the screen.

Oh, right. Those stupid blind fucks DO NOT have screens! Can you imagine? How arrogant of them to walk aroundm choosing blindess and demanding that you put in a bit of effort into your software to make their life possible.

I mean, why the fuck do they choose to go blind if it’s so hard for you, right? Dude, show respect. Or at least, have the sense to STFU.



In response to Cory. Reply



I appreciate the article @Adrian and agree with most of it. Nice response to the haters.

dominic; . Permalink

UX/UI Story telling might save :)


Why should what something is called define its implementation? If the goal is to have a control that allows the user to choose a single item from a list of items then why would you call it a “select” if it’s implemented using the HTML control and “ARIA Listbox” if it is implemented with ARIA? Functionally, and maybe even visually, the two implementations may appear identical, but if the team is forced to refer to them separately as distinct controls then you begin to introduce inconsistencies into specifications and business requirements.
To me, this type of issue, when it exists in software projects, is best handled by identifying and naming the patterns in use so that everyone can use the same shared language. If a team/organization wants to call a “select” a “picklist” then that should be ok as long as everyone involved has a shared understanding of what a picklist is, how it functions, its implementation requirements and how it is different from other similar controls.

Justin S.; . Permalink
In response to Justin S.. Reply

But “picklist” is meaningless outside of that team, introducing inconsistencies into specifications and business requirements.

Instead we can work on identifying and naming the patterns in use so that everyone can use the same shared language.

Weird. I pulled most of those two sentences from your comment verbatim. It is almost like you agree with my reasoning but just not the naming of the existing documented patterns.

In response to Adrian Roselli. Reply

To be clear, what I disagree with is the idea of naming a pattern based on the desired implementation. Just like a pattern for sewing something, it should be transferable across mediums. You can use the same pattern to make a pair of pants out of cotton or denim. You can also have variants of the pattern (boot cut, relaxed fit, etc..) or properties of the pattern (color, destressing, etc..), but you’re still talking about pants.
Now you might decide to use the medium, variant or property of your pattern so that you can be clear about which pair of pants you’re referring; blue jeans, flat front khakis, etc…, but again, I can look at them and say “hand me that pair of pants” and whomever I’m speaking to understands what I mean because we have shared understanding of what pants are and are not.

Justin S.; . Permalink
In response to Justin S.. Reply

Your analogue, hand me that pair of pants, implies there is only one pair of pants from which to choose. If I looked in a bin of user interface elements and there was only one control then I could just say hand me that control.

But when there are 11 pairs of pants on a table, how do you ask? Hand me a pair of pants? Will any pair of pants really do? Are you going to a wedding? A rodeo? An awkward office party? I posit in that scenario you would either ask your question and not get what you wanted, or you would ask Hand me the tuxedo pants or Hand me the jeans or hand me those awful khakis.

In response to Justin S.. Reply

good point. This also applies to modal, pop-up window, dialog box, etc. It seems to depend on team shared vocabulary


Me trying to explain what a select box is
“You mean a dropdown? Oh i know those!” :rolling_on_the_floor_laughing:

Colleen M Dailey; . Permalink
In response to Colleen M Dailey. Reply

An opportunity missed.


Are you over-exaggerating a non problem to aggrandize yourself? Yes… Yes you are, stop it.

Stop It; . Permalink
In response to Stop It. Reply

Thank you for validating me.


Thank you, I think. Having written code for a very long time, I only recognize “drop down” as shorthand for “drop down list box”, or ddlb, which is a select tag in HTML.

Robert King; . Permalink

wow, deep article – brutal comments! Thanks for putting this together :D

Philip; . Permalink

I liked this article and made a menu class from scratch

In response to Akif Eyler. Reply

Akif, this is interesting, but I am not sure what problem you are trying to solve. It does not conform to the ARIA Menu pattern (as described above). It has no roles, so it is not exposed to screen readers as a menu. It does not work for keyboard. The number field has no accessible name. Is it just a prototype, an experiment?



In response to bun. Reply



It’s my birthday, and reading the comments made me smile.

Thanks for being a good egg.

Jonathan Holden; . Permalink
In response to Jonathan Holden. Reply

Unfortunate way to spend a birthday, but happy one nonetheless.


Out of curiosity, do you have any idea why screen readers appear to read elements so differently? Like, it seems ridiculous that has so many different interpretations (would you not just read it as “datalist”?). Would you recommend using a different method instead to ensure consistent reading like the ARIA implementations?

Side note: good article. I don’t think referring to an item as a drop down is a 100% bad thing in conversation because people are roughly familiar with the general concept of one (e.g. the whole ‘oh a dropdown, I know that!’ stick customers will inevitably do), but I think it’s important to be as specific as possible and to explain what you really mean and what specific element you’re using, especially when defining requirements.

In response to Toby Ward. Reply

Usually I lay the blame at the feet of browsers, but in this case it is up to the screen readers to describe the controls. For <select> the announcement on macOS makes sense because the native implementation is different than on Windows and functions more as a pop-up menu. I would not try to force a consistent announcement across screen readers, partly because you will break from platform defaults and potentially confuse users.

The differences with <datalist> make a bit of sense when you consider that most screen readers are conveying it is just a text field, but with a bit more. So they announce similar to text fields.


Stop Using TL;DR

In response to Hossein. Reply



Stop using the word drop-down is an option, I will take this into consideration.

Jakob Nielsen; . Permalink
In response to Jakob Nielsen. Reply

You aren’t him.


Great write up.

I think a datalist resembles an autocomplete more than a comboxbox because it shows suggestions as you type.

What do you think Adrian?

In response to Adam. Reply

Both datalist and combobox are restricted to what is in the DOM at the moment. Neither of them can understand misspellings or foreign variants if not already in the datalist, for example.

An autocomplete is typically written to understand variations and generally has a component that communicates with the server (or a service) to look for near matches, and address common typos or variants.

I did not experiment with dynamically-updating datalists, because in the end the code is still a datalist. Autocompletes can be coded using a variety of means, just as programmatically-associated lists (as in your example).

So, programmatically I think datalist and combobox are more closely aligned.

If explaining this to a non-technical person outside of your development workflow (such as a client), then any wording would work as long as you get enough detail in requirements analysis to understand which technical implementation is the best fit.

Does my decision tree make sense?

In response to Adrian Roselli. Reply

Thanks, Adrian, yeah I think I follow your logic for the most part.

I thought I’d elaborate on my original message with a few more thoughts in response to your comment:

1. My definition of a comboxbox is that it’s a mix of a text box and select box. The user can type into it or open up the options and select one. Suggestions do not appear as the user types.

2. My definition of an autocomplete is it’s primarily a text box that users type and get suggestions.

3. I think there’s certainly cross over between (1) and (2). For example, with an autocomplete I think the user should be able to just scroll the options without typing anything like a combobox.

4. While a good autocomplete will forgive typos and include variants, I don’t think that’s the defining characteristic of an autocomplete. By that I mean a datalist is a bad autocomplete, but an autocomplete nonetheless.

5. A datalist is restricted to what’s in the DOM, yes. But we can, for example, dynamically update the DOM in response to an AJAX call so I’m not sure how relevant that is.

Keen to hear your thoughts on the above.


very useful article for web designers
I will never use drop down again

Arka web design; . Permalink

Provoking title of the article!

Why not directly giving a name to the article as
“Stop using the word drop-down. Instead choose a term that accurately describes the control you want.”
I thought you have some news about the techniques, but in fact it’s just a concern how people are refering to the current subject.

Well, leave that decision to people and let them describe their own way. For me a Drop Down term is clear. I click the select box and a drop down list spears. ComboBox let’s me search within the drop-down list. So, you won’t change my grammar and vocabulary on that and many others will agree with me.

It’s a programming language and not English literature.


In response to Revaz. Reply

That would have been a really long title. I put the additional information in the first sentence, the last sentence, and the meta data so it gets fed into social media cards and abstracts when shared. I have also seen that qualifier used in most places that have linked this post. So, shrug emoji?

You are welcome to not change your vocabulary or grammar. As you point out, this is not English literature. But if you do development then not using the right term in requirements or specifications can cause unneeded refactoring for all the reasons I cited in the post and in response to the valid comments here. You do you.


I’m so on the fence with this. I love the idea of normalizing using the correct terminology with clients because something I run into a LOT is when a client throws out “pop-up” or “drop-down” in a request for something they want me to implement and I have to go through a process of trying to disambiguate what they’re actually asking for pretty often. I generally ask them to send me a link to a website that has the thing they want so that I can just see what they’re asking for, but it would be nice if they knew the correct terminology, too, so we could both save the billing hours going back and forth in emails trying to get on the same page.

On the other hand, when it comes to the ARIA stuff, I think trying to get clients to understand and incorporate these terms into their vocabulary when talking to us is a little too much to ask. ARIA stuff is important to screenreaders and it’s undoubtedly integral to our wheelhouse as designers/developers, but I don’t think it makes much sense to try to get a client to understand these terms. Admittedly, I’m still fairly green in this field having only been doing web design professionally for a few years now, but even I still struggle a LOT with ARIA stuff. I literally have to Google almost all the time when it comes to an ARIA term and what its function is.

I do agree, though, that things like listboxes, , modals, flyout menus, accordions, etc. are important to help the client get used to and learn to use. These types of terms are the ones that I use when replying to a client’s request, generally by offering links to other websites that use these functions and labeling them appropriately, then asking the client which one is the one they envisioned me using. It makes everyone’s life easier when we use the right terms because it saves so much time trying to clarify each other’s vision.

TL;DR: thanks so much for this article and the “pop-up” one. Gives me a lot to think about and some renewed confidence in my previous and present attempts to get the client to start to understand the correct terms.

In response to Jen. Reply

Ultimately I do not expect clients (at least, non-technical clients) to understand this stuff. For your technical clients, co-workers, collaborators, and so on, I do expect different.

Your approach of asking for an example of the thing is a tried and true method. It also an opportunity to add value to a client relationship by explaining the pattern, its uses, and caveats, and then only referring to it as that going forward. Even if they still call it the wrong thing.

Good luck.


Hi Adrian,
Thanks for the in-depth article.
I don’t necessarily agree with _everything_, but it’s really nice to have it laid out like this.

One thing I wanted to point out is that the APG only provides examples of listboxes that are always expanded (i.e., none of them exist on the page as a single labelled field which can ‘drop down’ to reveal items).
So it is entirely possible to infer that they _cannot_ expand and collapse like a select (at least the non-multiple version). I’m not sure if there’s a reason there is no such example. if they are synonymous, at least one example that behaves like the default select would help, no?

Mike Gower; . Permalink
In response to Mike Gower. Reply

I do not reference APG because it is not a standards document (it was demoted from a Note too). It shows what its authors think is an ideal implementation of ARIA regardless of support. But if you want to see what APG thinks is analogous to a native <select>, then look at APG’s select-only combobox.


This is a really good explanation, thanks!

Cole Andersson; . Permalink

As somebody who started with native programming in the 90s, calling things that aren’t comboboxes comboboxes is one of my biggest pet peeves.

The W3C should be embarrassed:

Leave a Comment or Response

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>