Combo boxes combine a text entry with a dropdown menu, allowing users to filter longer lists to only the selections matching a query.
Combo boxes should always have a label. In rare cases where context is sufficient and an accessibility expert has reviewed the design, the label could be undefined. These combo boxes without a visible label should still include an aria-label in HTML (depending on the context, “aria-label” or “aria-labelledby”).
Labels can be placed either on top or on the side. Top labels are the default and are recommended because they work better with long copy, localization, and responsive layouts. Side labels are most useful when vertical space is limited.
The placeholder text, also commonly known as “ghost text,” is temporary and disappears once a user enters text.
The value shows a user’s entered text or the option they’ve selected.
The width of a combo box can be customized appropriately for its context.
By default, combo boxes have a visible background. This style works best in a dense array of controls where the background helps to separate the input from the surrounding container, or to give visibility to isolated buttons.
Alternatively, quiet combo boxes can have no visible background. This style works best when a clear layout (vertical stack, table, grid) makes it easy to parse the buttons. Too many quiet components in a small space can be hard to read.
Combo boxes can be marked as optional or required, depending on the situation. For required combo boxes, there are two styling options: a “(required)” label or an asterisk. If you use an asterisk, be sure to include hint text to explain what the asterisk means. Optional combo boxes are either denoted with text added to the end of the label — “(optional)” — or have no indication at all.
The asterisk used in this component is an icon that has specific spacing from the label text — not part of the label text itself.
Combo boxes can automatically complete suggested results within the input field.
There are 3 options for how a combo box’s menu can be triggered: when a user starts typing (“input”), when focus is placed on the input field (“focus”), and manually when the user clicks or taps the field button (“manual”). These are used for different degrees of the information complexity and/or user familiarity of menu options.
By default, the menu is triggered when a user starts typing. This should be used when the content is readily familiar or commonplace enough to a user that they can begin populating values without seeing a list of all available options.
If the content of the combo box is unfamiliar or complex, the menu should be triggered when focus is placed on the input field because a user would benefit from seeing example content before selecting a value.
If the content of the combo box is highly familiar and autocomplete is sufficient to surface options, the menu can be set to trigger manually.
A combo box can be marked as having an error to show that a value needs to be entered in order to move forward, or that a value that was entered is invalid.
A combo box in a disabled state shows that an input field exists, but is not available in that circumstance. This can be used to maintain layout continuity and communicate that it may become available later.
Combo boxes have a read-only option for when content in the disabled state still needs to be shown. This allows for content to be copied, but not interacted with or changed. A combo box does not have a read-only option if no selection has been made.
From the design point of view, each component has a number of options. These options and their names are platform agnostic, and each implementation should adapt these to fit into their framework.
text / nothing
top / side
text / nothing
yes / no
yes / no
text / icon / nothing
yes / no
input / focus / manual
yes / no
yes / no
yes / no
The minimum width for a combo box is 2.5× the height of the field button for standard style, and 2× the height of the field button for quiet style. This minimum width guarantees that small combo boxes are readable and easy to target on touch devices.
When the field label and menu text are too long for the available horizontal space, they wrap to form another line. The field text itself truncates at the end, but the text can be shown in full in the menu.
The text input functionality of the combo box is meant to make large lists easier to search. If you have fewer than 6 items, use radio buttons. If you have more than 6 items, consider whether your list of selections is complex enough to merit searching and filtering. If it's not complex enough for a combo box, you can use a traditional dropdown.
It’s okay to suppress the popover when the combo box contains entries the user is familiar with, and when autocomplete is enabled. A suppressed popover can still be opened when the field button containing the chevron is clicked.
Launch the popover immediately if your user is highly unfamiliar with the content in the combo box, or if the data is especially complex.
Launch the popover on text change if your user can get started typing without seeing a long list of options.
When a suggestion is appended to the end of typed text, it remains the selected value when focus leaves the field. This guards against the scenario when a user sees a word completed in a field, continues to another form component, and the failure to commit changes erases the suggestion.
When autocomplete is disabled, best matches get a hover style in the popover, but don’t get saved as a value unless they’re clicked on or "Enter" is pressed.
Every combo box should have a label. A combo box without a label is ambiguous and not accessible. In rare cases where a label could be absent, make sure to have the design reviewed and approved by an accessibility expert.
Keep menu items short and concise. Long menu items that cause text to wrap to multiple lines are discouraged. If text wrapping becomes a frequent concern, consider revising the text or use alternative UI patterns that will give your content more space.
Choose a width for your combo boxes that is likely to accommodate the majority of selections available within it. When a combo box is in focus and the typed input exceeds the width of the field, push the leftmost text out of sight while allowing text to continue to be entered towards the chevron. When a combo box is deselected, truncate the selected entry with ellipsis before it collides with the chevron button.
Field labels, placeholder text, and menu items should be in sentence case.
In a single form, mark only the required fields or only the optional fields, depending on whichever is less frequent in the entire form. If most of the combo boxes are optional, only the required fields should be give an asterisk or have labels appended with “(required)”. If most of the combo boxes are required, only the optional fields should be appended with “(optional)”. An asterisk should never be used to note that a combo box is optional.
For RTL (right-to-left) languages, the layout of the combo box is mirrored. Texts are right-aligned while the chevron and checkmark are left-aligned.
|Typing||Initiates autocomplete or popover (unless suppressed).|
|Down Arrow||If the popover is unsuppressed and not already open, the down arrow opens the popover menu.|
|Up or Down Arrows||Move through selection of options in popover or autocomplete.|
|Esc||If the popover is open, close the popover.|
|Feb 28, 2020||5.2.0|
|Aug 22, 2019||5.1.0|
|Aug 13, 2019||5.0.1|
|Apr 19, 2019||5.0.0|
Includes all interactive states that are applicable (hover, down, focus, keyboard focus, disabled).
Includes relevant options (variant, style, size, orientation, optional iconography, decorations, selection, error state, etc.)
Works properly across all four color themes (lightest, light, dark, darkest).
Includes a desktop scale (UWP, macOS, web desktop) and a mobile scale (iOS, Android, web mobile).
Includes guidelines for layout (wrapping, truncation, overflow), animation, interactions, etc.
Includes a list of dos and don’ts that highlight best practices and common mistakes.
Follows WCAG 2.0 standards for contrast (AA).
Works properly across various locales and includes guidelines for bi-directionality (RTL).
Follows WCAG 2.0 standards for keyboard accessibility guidelines and includes a description of the keyboard interactions.
Includes a downloadable XD file that has been generated by code and shows multiple variations, states, color themes, and scales.
All design attributes (color, typography, layout, animation, etc.) are included in Spectrum DNA.