Dropdown
A dropdown displays a list of selectable options in a floating panel, allowing users to choose from predefined choices in a compact interface.
Ready to use
A Dropdown lets users select an option from a list of choices that appears when they interact with a trigger. It helps keep interfaces clean by hiding secondary or large sets of options until needed, which makes it useful when space is limited or when the user needs to choose from a set of mutually exclusive actions or values. The component is fully responsive and intentionally designed to be used across all viewports.
Anatomy
Section titled “Anatomy”- Hybrid
- Plug-in Hybrid
- Electric
- Trigger
- Chevron
- List
- Selected option
When to use it
Section titled “When to use it”Use the Dropdown when:
- You need to offer 4–12 options without overwhelming the interface.
- The selection doesn’t need to be immediately visible until the user interacts.
- The user has to switch between predefined values or trigger an action.
- Space is constrained and a compact UI is preferred.
- You need to organise secondary actions tied to a primary object or context.
Avoid the Dropdown when:
- The user needs to compare all options at once — consider radio buttons or a list.
- The selection needs frequent or rapid access — a persistent UI element is better.
- The action is a highly visible or critical CTA — use an explicit button.
- The options include complex content like large images or long descriptions — use a menu or a select list instead.
Properties
Section titled “Properties”State
Rested, Hover, Filled, Disabled, and Focus. The filled variant carries a subtle background so users can see at a glance which dropdowns hold a value; focus shows a 2 px outline so the trigger stays reachable from the keyboard.
Label
A persistent label sits above the trigger and names the selection. Keep it visible while the user interacts — placeholder-only labels fail when the user comes back to revise the form.
Helper text
Optional one-line helper text beneath the trigger. Use it to communicate constraints or examples (for example “Choose your preferred year”), not to repeat the label.
List
The list of options that opens beneath the trigger. Keep option labels short and scannable, and organise long lists alphabetically or by category to reduce cognitive load.
Chevron
The direction indicator inside the trigger. It points down when the list is closed and flips up while it is open.
Platform considerations
Section titled “Platform considerations”Desktop
The menu opens beneath the trigger and matches its width by default. Adapt the width to fit the longest option where clarity matters more than alignment.
Tablet
Same behaviour as desktop. Don’t auto-open on focus — it’s disorienting and doesn’t reflect typical usage patterns.
Mobile
The dropdown often promotes to the native picker on mobile. Keep the visible trigger tall enough for comfortable tapping and ensure clickability is clear without relying on hover.
Best practices
Section titled “Best practices”Treat the dropdown as a way to compress a known set of choices — not as a hiding place for important content.
Do
Keep option labels concise and easy to scan, organise long lists alphabetically or by category, use placeholder text that clearly indicates the expected action (“Select model” rather than “Choose”), pre-select an option only when there’s a strong default, keep terminology consistent across dropdowns in the product, and adapt the trigger width to fit the longest option when clarity matters.
Don't
Don’t overload the dropdown with too many items (a searchable dropdown fits very long lists), don’t mix unrelated content types inside the list, don’t use vague or repetitive labels like “Option 1” or “Item”, don’t rely on hover to indicate state on touch devices, don’t hide critical information inside a dropdown if it affects the user’s decision, and don’t auto-open on focus.
Content guidelines
Section titled “Content guidelines”Write option labels that stand on their own — users shouldn’t need surrounding context to understand them. Keep them short and scannable (one line wherever possible), use sentence case for readability, and make sure the wording is parallel across the menu (all nouns or all verbs). Use placeholder text that tells the user what kind of choice the dropdown holds (“Select model”), and reserve helper text for constraints or examples rather than restating the label.
Styles
Section titled “Styles”A dropdown displays a list of selectable options in a floating panel.
Recipes
Section titled “Recipes”Select List
Section titled “Select List”
Powertrain333 miOption 1
Powertrain333 miOption 2
Powertrain333 miOption 3
Checkbox List
Section titled “Checkbox List”The dropdown follows the WAI-ARIA Listbox pattern — a trigger that opens a single-select list of options — and meets WCAG 2.1 AA. An accessible dropdown keeps that list reachable and operable from the keyboard, keeps assistive technology informed of its open state, and gives every element an accessible name — so the choice it holds is clear whether the user is looking at it, listening to it, or tabbing through it.
For designers
Section titled “For designers”- All list items and states must maintain accessible contrast on every supported surface. Source: WCAG 1.4.3 Contrast (Minimum).
- State must never be conveyed by colour alone — pair it with text, an icon, or a shape. Source: WCAG 1.4.1 Use of Color.
- Focus styles must stay visible, meet contrast requirements on every supported surface, and be clearly distinguishable from hover. Source: WCAG 2.4.7 Focus Visible.
- Use semantic colour tokens (e.g.
foreground/neutral/default) rather than fixed values, so the component adapts correctly across themes and surfaces.
For developers
Section titled “For developers”Expose the trigger, list, and options to assistive technology through native list semantics and ARIA. Screen readers announce the count and position of options (“listbox, 3 items, item 1 of 3”) automatically when native list markup is used. If the dropdown supports search, give the input a role="searchbox" (or a labelled <input>) and filter options while preserving arrow-key navigation. The per-element roles, names, and states are in the Labelling elements section below.
Keyboard interaction
Section titled “Keyboard interaction”| Key | Action |
|---|---|
| Enter / Space | Open the dropdown, or select the focused option |
| ↑ / ↓ | Open the dropdown, then move focus between options |
| Home / End | Move focus to the first / last option |
| Escape | Close the dropdown, return focus to the trigger |
| Tab / Shift + Tab | Close the dropdown and move to the next / previous control |
Interactive targets must be at least 44 px high for comfortable touch use — comfortably clearing the WCAG AA minimum. Source: WCAG 2.5.8 Target Size (Minimum).
Focus order
Section titled “Focus order”Focus reaches only the trigger and, once the list is open, each option in turn — a roving tabindex walks the options while the list container and chevron never receive focus. Selecting an option returns focus to the trigger. The keys that drive this are in the Keyboard interaction table above.
- Hybrid
- Plug-in Hybrid
- Electric
- Trigger
- Option 1
- Option 2
- Option 3
Source: WCAG 2.4.3 Focus Order.
Labelling elements
Section titled “Labelling elements”Give every element the role, name, and state assistive technology needs.
Trigger
aria-haspopup="listbox" with aria-expanded kept in sync with the open state. Name it from a visible label wired with aria-labelledby, or aria-label="Powertrain" when there’s no visible label — never leave the name to the placeholder alone.
Options list
role="listbox" (add aria-multiselectable="true" for checkbox-style dropdowns). Name it with aria-label or aria-labelledby when its purpose isn’t obvious from context, so it doesn’t announce as an unnamed list.
Options
role="option" on each item, with aria-selected="true" on the selected one. Each option takes its accessible name from its text content — keep that text self-describing.
Source: WCAG 4.1.2 Name, Role, Value.