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?
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
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.
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
<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.
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
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
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.
<summary> are a native disclosure widget. That’s about it.
<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
<summary>, but in this case you are not using ARIA roles to enhance generic controls. You need a
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.
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
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.
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
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]" 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
<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.
The alternative is to not try.
Many of those seem to overlap quite a bit.
Also, clear simple examples per type would be great.
The overlap is why I wrote this and also why I offer links for each type, most of which have examples.
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?
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
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.
Clearly not everyone, every one.
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.
I appreciate the article @Adrian and agree with most of it. Nice response to the haters.
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.
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.
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.
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 sayhand 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 askHand me the tuxedo pantsorHand me the jeansorhand me those awful khakis.
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:
An opportunity missed.
Are you over-exaggerating a non problem to aggrandize yourself? Yes… Yes you are, stop it.
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.
wow, deep article – brutal comments! Thanks for putting this together :D
I liked this article and made a menu class from scratch
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?
It’s my birthday, and reading the comments made me smile.
Thanks for being a good egg.
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.
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
Stop using the word drop-down is an option, I will take this into consideration.
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?
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?
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
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.
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.
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.
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?
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!
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: https://www.w3.org/WAI/ARIA/apg/patterns/combobox/examples/combobox-select-only/