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”- Trigger
- Label
- Helper text
- Menu
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.
Menu
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.
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.
For designers
Section titled “For designers”- All list items and states must maintain accessible contrast.
- Focus styles must remain visible and meet WCAG AA contrast requirements across all supported surfaces. Focus should be clearly distinguishable from hover.
- Colour tokens used should be semantic (e.g. foreground/neutral/default) rather than fixed values. This ensures the component adapts correctly to different themes or surfaces.
For developers
Section titled “For developers”To ensure the list meets WCAG 2.1 AA and supports assistive technologies, follow these implementation standards:
- Keyboard Navigation
- Tab: Moves focus to the dropdown trigger.
- Enter or Space (on trigger): Opens the menu.
- Up/Down Arrow Keys: If closed, opens the menu and moves focus to the first/selected option. If open, navigates through list items.
- Enter: Selects the focused option.
- Esc: Closes the dropdown without making a selection.
- Tab / Shift+Tab: Moves focus out of the component and closes the menu.
- Focus Ring / Visible Focus
- List items must display a visible focus style, not only a colour change.
- Screen Reader Support
- Ensure the list has an accessible name when the context isn’t obvious (using
aria-labeloraria-labelledby). - Screen readers will automatically announce the number and position of items (“list with 5 items”, “item 1 of 5”, etc.) when using native list markup.
- Ensure the list has an accessible name when the context isn’t obvious (using
- Responsive and Tap Targets
- Interactive area must be at least 44 px in height to support touch accessibility.
- Roles and ARIA attributes
- For the dropdown trigger:
role="combobox",aria-haspopup="listbox",aria-expanded="true/false"(dynamic),aria-controls="dropdown-list-id". - For the list container:
role="listbox", provide anidreferenced by the trigger. - For each option:
role="option",aria-selected="true/false". - If the component supports search inside the dropdown: input uses
role="searchbox"or a standard<input>with correct labeling. Dynamically filter options while preserving arrow-key navigation.
- For the dropdown trigger:
- Focus order
- Tab → dropdown trigger: user sees focus indicator on the closed state.
- Enter/Space → open the dropdown: dropdown list receives focus (usually the selected item, or the first option if nothing is selected).
- Arrow keys to navigate options.
- Enter to select → focus returns to the trigger (now in “filled” state).
- Tab moves to the next form element.
- If dismissing with Esc: focus returns to the dropdown trigger.
- If clicking outside: dropdown closes, focus must remain on the trigger for accessibility consistency.
Roles & attributes
Section titled “Roles & attributes”| Element | Attributes |
|---|---|
| Trigger button | aria-haspopup="listbox", aria-expanded, aria-labelledby (pointing to a visible label) |
| List container | role="listbox". Add aria-multiselectable="true" for checkbox-style dropdowns. |
| Each option | role="option". Set aria-selected="true" on the active option. |
Use aria-activedescendant on the listbox to communicate the currently focused option without moving DOM focus.
Keyboard interaction
Section titled “Keyboard interaction”| Key | Action |
|---|---|
| Enter / Space | Open dropdown or select the focused option |
| ↑ / ↓ | Move focus between options |
| Home / End | Move focus to first / last option |
| Escape | Close dropdown, return focus to trigger |