Open any checkout page and you’ll probably run into a country selector. Baymard Institute (2025) found that 78% of sites in its checkout benchmark include one, and the list behind it often holds more than 200 options.
Baymard ties those long lists to two problems. Users lose the overview, and scrolling produces errors.
The control in question is a dropdown. It collapses a list of options behind a trigger and shows only the selected value until a user opens it. A command menu runs an action or opens a page, but a dropdown stores a choice, which is why it shows up in forms, filters and sort bars where space is tight.
What Is a Dropdown in UI?
Space is the whole point. A field the height of one input can hide twenty choices until someone asks for them.
Nielsen Norman Group (2017) credits dropdowns with saving screen space and with keeping bad data out of forms, since users can only pick legal choices. People also already know how to operate them. The same article adds a caveat, that usability would improve if designers reached for them less often. I tend to agree.
Dropdowns sit beside other common interface components that collect input. Carbon Design System puts them in forms (on full pages as well as in modals and side panels) and in filter and sort controls.
The names overlap, which causes confusion. Nielsen Norman Group calls the value-holding kind a dropdown box, meaning a form field or an attribute picker, and saves dropdown menu for the kind that starts a command or sends the user somewhere new.
Apple’s Human Interface Guidelines call the single-choice version a pop-up button and keep the name pull-down button for commands.
Accordions and tab sets only reveal content. Neither stores a choice, so they belong to a different family.
Parts and States of a Dropdown
Most dropdowns come with a label, a trigger that shows the selected value, a chevron icon, an option list and the options inside it. Helper or error text sits under the field when needed.
Anatomy
The label tells users what the options are for. Siemens Healthineers marks it optional in its UI MarCom component spec, but the CMS Design System says every dropdown needs one. I’m with the CMS Design System on this.
The trigger is the closed field. It shows placeholder text until a choice is made, with a chevron icon at the end. Siemens marks the arrow mandatory, and in Carbon a click anywhere in the field opens the list.
Carbon sets each option in the list to the same height as the field. Hints, requirements or error messages go underneath as helper text.
Once someone picks an option, its text replaces the placeholder in the trigger.
Interactive states
A dropdown cycles between closed and open, and design systems add field states on top. Carbon lists eight: enabled, hover, focus, error, warning, disabled, skeleton and read-only.
The selected state is simply the closed field showing the chosen value.
The open state follows a few fixed rules. A click opens the list, and so does Enter or Space when the trigger has focus. Escape or a click outside closes it. While the list is open, the trigger takes an active state.
Those rules come from the Semrush Intergalactic design system, which also bars opening one dropdown from inside another. Carbon says the same about nesting.
Unavailable options stay in the list, grayed out. Removing them breaks spatial consistency and makes the interface harder to learn, according to Nielsen Norman Group.
Types of Dropdowns and How They Differ
Most dropdowns you’ll run into are a select, multi-select, combobox, action menu or navigation dropdown. Only the first three store a value. The other two trigger something.
| Type | Result | Typing | Typical use |
|---|---|---|---|
| Select | One value | Jump to a letter | Form fields, sort order |
| Multi-select | Several values | Optional filter | Filters |
| Combobox | One value or custom text | Yes | Long or database-fed lists |
| Action menu | Runs a command | No | Toolbars, More menus |
| Navigation dropdown | Opens a page | No | Site headers |
Carbon describes a combo box as a dropdown list with a text field on top, so people can type to find a match or enter a value that is not listed. A plain select only lets you jump to an option by typing a letter.
Multi-select keeps the menu open while people tick options, shows a count tag in the field, and offers an optional “All” parent checkbox. Carbon (last updated September 2026) advises dropping that checkbox in filters, where choosing all and choosing none give the same result.
Material Design’s exposed dropdown menu puts the chosen item inside a text field and can accept typed input to act as autocomplete. On mobile, Material allows a native picker instead.
Apple’s line falls in the same place (Apple Human Interface Guidelines). Pop-up buttons hold mutually exclusive choices that aren’t commands, and pull-down buttons are where the commands go.
Bootstrap’s dropdown component sits on the command side. It is a toggleable overlay for lists of links and other content, and it opens on click, not hover, by design.
Navigation dropdowns carry their own warning from Nielsen Norman Group: keep global top-level navigation out of them on desktop, because burying categories makes them harder to find. A short link list works with dropdown menus built in plain CSS, but hover alone leaves keyboard users out, so add a click or focus trigger.
Native Select or Custom Dropdown?
Use the native select unless the options need rich content or search. Rebuilding its behavior by hand is where custom dropdowns tend to fail.
Baymard Institute (2017) found that 82% of ecommerce sites use a custom dropdown in checkout, and 31% of those custom dropdowns have significant usability issues.
Baymard ties the failures to missing native behavior and calls it hard to rebuild even for the largest sites. Walmart’s custom card-expiry dropdown showed 3 month options and gave no sign that 9 more existed.
| Option | Pros | Cons |
|---|---|---|
| Native select | Keyboard, focus and form submission handled by the browser | Plain text options, no search |
| Custom dropdown | Rich options, search, brand styling | Every native behavior rebuilt and maintained |
What the native element gives for free
The select element wraps option elements, and optgroup groups related options under a label (MDN Web Docs). Each option carries a value attribute for the data sent with the form, and the multiple attribute allows more than one selection.
Browser support is a non-issue. MDN lists select as Baseline widely available, working across browsers since July 2015.
Baymard’s checks for a custom build double as a list of what the native control already does:
- Reachable by Tab
- Visible keyboard focus
- Jump to an option by typing a character
- List height adjusts to the space available
- List opens up or down depending on viewport position
Carbon points the same way for form-heavy or mobile-heavy products. The native select submits cleanly with a form and uses the platform control on phones.
Styling the native select with base-select
Chrome 135 added appearance: base-select, announced by Chrome for Developers on March 24, 2025. Chrome was the first browser to implement it, and both the select and its ::picker(select) pseudo-element need the property to opt in.
Options can then hold HTML such as images and SVG, and the picker sits in the top layer, positioned with anchor positioning. Parts like the picker icon and the checkmark become styleable too.
The cost side is real, though. The built-in mobile operating system component is gone. The select no longer takes the width of its longest option, and it won’t render outside the browser pane.
As of MDN’s August 2026 revision, customizable select is labeled limited availability and is not Baseline. Browsers without support fall back to a classic select, though MDN warns that some JavaScript frameworks block the features or cause hydration failures under server-side rendering.
A lighter route exists. Home Depot’s checkout shows a custom closed state that opens a native list, the shell approach Baymard recommends when the goal is purely visual.
The older appearance: none route is covered in this guide to styling a native select with CSS.
How Keyboard and Screen Reader Support Works
Keyboard support follows a fixed key map. Screen readers rely on ARIA roles, namely combobox, listbox and option.
Baymard Institute (2017) found that 24% of desktop users consistently enter the card expiry date using only the keyboard.
The W3C ARIA Authoring Practices Guide (APG) select-only combobox example, last updated August 2025, defines the reference key map:
| Key | List closed | List open |
|---|---|---|
| Down Arrow | Opens the list | Next option |
| Up Arrow | Opens, first option | Previous option |
| Enter or Space | Opens the list | Sets the value, closes |
| Home or End | Opens, first or last option | First or last option |
| Printable character | Opens, jumps to a match | Jumps to a match |
Escape closes the list and keeps the current value. Tab is where the sources part ways.
- The W3C APG has Tab set the value to the focused option, close the list and move focus to the next element.
- Carbon has Tab close the dropdown without changing the selected option.
- A native select closes the list on Tab but does not move focus, per the APG note.
Since they disagree, pick one behavior and document it. Then test it with real assistive technology.
Screen readers learn what a custom dropdown is from ARIA roles and attributes. The APG pattern puts the combobox role on the trigger and a listbox on the popup, and each item gets the option role.
- aria-expanded on the trigger tracks open or closed
- aria-controls points the trigger at the listbox
- aria-activedescendant names the highlighted option while DOM focus stays on the trigger, and the script has to scroll that option into view because browsers do not (W3C APG)
- aria-selected marks the highlighted option
Not every system follows the APG here. Carbon’s default dropdown and multiselect use a button with aria-haspopup set to listbox, and only its combo box uses an input with the combobox role.
Browser support is the other failure mode. WebKit bug 231724, filed October 14, 2021, reported that Safari with VoiceOver did not read the options in the select-only combobox pattern, and commenters still reproduced it on Safari 17.5 in July 2024.
A comment dated July 9, 2025 reports it working on Safari 18.4, though WebKit Bugzilla still lists the bug as new. The APG itself warns of support gaps across browser and assistive technology pairs and advises testing before production use.
The CMS Design System (version 18.1.0) builds its dropdown on Adobe Spectrum instead of a native select. Its maturity checklist marks keyboard navigation and screen readers complete, leaves WCAG 2.1 Level AA conformance incomplete, and notes that Axe flags a hidden input as a known false positive.
The web accessibility requirements behind all of this sit in WCAG 2.2, a W3C Recommendation since October 5, 2023. Criteria 2.1.1 Keyboard and 2.4.7 Focus Visible apply directly, along with 4.1.2 Name, Role, Value, which asks that every script-generated component expose its name and role programmatically.
When Is a Dropdown the Right Control?
A dropdown fits when users pick one value from a fixed, known set that is too long for radio buttons and short enough to scan.
Carbon Design System calls the dropdown the default choice for alternatives, and a good fit when screen space is limited. The set should be predefined and familiar to users, with only one value needed. Space is usually tight, as in filters, sort controls and dense forms.
Run the choice through these questions, in order.
- Is the user storing a value? If the control runs a command or opens a page, build a menu instead.
- Can people type the answer faster than they can find it? Use a text field. Nielsen Norman Group points to birth day, month and year, data users already know by heart.
- Do they need to see every option to compare them? Use radio buttons.
- Is the list long? Use a combobox or an autocomplete field.
Whatever is left after that is a dropdown.
| Control | Option count | Selection | Field examples |
|---|---|---|---|
| Radio buttons | A handful | One, all visible | Shipping method |
| Dropdown | A mid-size set | One, hidden until opened | Return reason, sort order |
| Combobox or autocomplete | A long list | One, typed to filter | Country |
| Text field | Any | Free text | Name, date of birth |
Baymard’s checkout research replaces several common dropdowns with something better.
- Title fields become a single full name field.
- State is replaced by automatic address lookup, so most users skip the field.
- Card type gets detected from the first six digits of the card number.
- Country turns into an autocomplete field when the input must be validated.
Dropdowns still win when users do not know the options in advance, or when answers must arrive in a structured format.
Amazon’s “Reasons for Return” dropdown holds 12 options, above the usual limit. Baymard allows the exception because a structured answer can matter more than free text.
When a Dropdown Does Not Work
Option count is the first way a dropdown goes wrong. Too few options, and users open the list just to see what it holds. Radio buttons would have shown the choices up front.
Long lists are worse. Baymard found that with the cursor outside the list the wheel scrolls the page and hides the options, and in some browsers the list keeps scrolling while it has focus, which leaves erroneous data.
Familiar data is another weak spot. Birth dates and similar details get typed faster than they get scanned (Nielsen Norman Group).
Then there’s the problem of a selection that changes the page. The CMS Design System, citing WCAG 2.1, says not to change page content or navigate when a value is picked, and to warn users if a control changes context.
Dependent dropdowns, where one control changes the options in another, confuse users (Nielsen Norman Group, CMS Design System). Toyota Europe’s DX Playbook also rules dropdowns out for frequent or rapid access and for critical actions that deserve an explicit button.
Here is what each source says about option counts.
- Baymard Institute (updated January 28, 2025) advises avoiding dropdowns with fewer than 5 or more than 10 options in ecommerce checkout.
- Baymard also found that 55% of users opened an optional dropdown with 1 to 4 options just to see its contents, then closed it again.
- The CMS Design System suggests a dropdown for about 7 to 15 options.
- USWDS says to use radio buttons under seven options and to consider a combo box above 15.
- Carbon Design System says not to use a dropdown for two options.
The sources disagree on the window. Baymard says its numbers describe checkout flows and that survey forms and application software can deviate.
Where Baymard and the CMS Design System overlap, at 7 to 10 options, both accept a dropdown. Below that band the sources point to radio buttons, and above it to a combobox or autocomplete field.
The CMS Design System also repeats the usability experts’ label for dropdowns, “UI of last resort”, and tells teams to test them with their own audience.
Common Questions About UI Dropdowns
Can placeholder text replace a dropdown label?
No. The CMS Design System says every dropdown needs a visible label, and it warns against dropping the “State” label so the field reads only “Select a state”.
Once a user picks an option, the placeholder is gone and the field has no stated purpose.
How should dropdown options be ordered and labeled?
The CMS Design System sets alphabetical order as the default, and it pre-selects an option when most users will pick the same one.
The Helsinki Design System adds that labels should be short and concise, and that option text should fit on one line.
Do dropdowns work well on mobile?
Yes, when the dropdown is a native select, because the operating system supplies its own picker. Material Design points to that picker on mobile, and Carbon recommends a native select for mobile-heavy products.
Baymard advises against native dropdowns for site navigation on mobile, so keep them for form values.
Should unavailable options be disabled or hidden?
Disable them. Nielsen Norman Group advises graying out unavailable options instead of removing them.
In a native select, the disabled attribute on an option element does exactly that.
Testing a Dropdown Before You Ship It
Run the checks in this order before release.
- Keyboard only, no mouse
- Screen reader on each target browser
- Sessions with the real audience
The keyboard run costs minutes and exposes focus faults that would distort the screen reader run. Audience sessions come last because they need a build that already works for both.
The same tests apply to every other control in a form, so the next step is building accessible forms around the dropdown.
The test order holds until customizable select reaches Baseline status, which MDN did not list as of October 26, 2026. Once it does, fewer dropdowns will need custom code, and fewer will need the full test.
Many of his resources are available on various design marketplaces. Over the years, he's worked with a range of clients and contributed to design publications like Designmodo, WebDesignerDepot, and Speckyboy, Slider Revolution among others.
- How to Insert Image in Figma With Ease - November 3, 2026
- How to Download Figma Files Fast and Free - October 30, 2026
- Figma Keyboard Shortcuts That Will 10x Your Speed - October 25, 2026
