Pickers (sometimes known as "dropdowns" or "selects") allow users to choose from a list of options in a limited space. The list of options can change based on the context.
Pickers 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 pickers 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,” prompts a user to select an option from the picker menu. It disappears once a user selects an option.
The value shows the option that a user has selected.
The width of a picker can be customized appropriately for its context. This option is not applicable to quiet pickers.
By default, pickers 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 pickers 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.
Pickers can be marked as optional or required, depending on the situation. For required pickers, 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 pickers 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.
A picker 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 picker 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.
Pickers 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 picker can have help text below the field to give extra context or instruction about what a user should select. The help text area has two options: a description and an error message. The description communicates a hint or helpful information, such as specific requirements for what to choose. The error message communicates an error for when the selection requirements aren’t met, prompting a user to adjust what they had originally selected.
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
text / nothing
Not applicable to quiet picker.
yes / no
text / icon/ nothing
yes / no
popover / tray
The option to display the menu in a tray is available on mobile devices only.
yes / no
yes / no
yes / no
text / nothing
text / nothing
The minimum width for a picker is 2× the height of the field button. This guarantees that small pickers are readable and easy to target on touch devices. Quiet pickers do not have a minimum width; their width depends on the length of the text.
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.
When the help text is too long for the available horizontal space, it wraps to form another line.
The picker menu can be as tall as necessary to show as many options as possible in the available space. There is no maximum height.
In Windows high contrast mode, picker should be displayed using the high contrast theme-specified colors for buttons. By default, border color should be the same as the button text color and labels should use default text color. In hover and keyboard focus states, the border color should display as the button border color. In the disabled state, border and text color should display as the disabled color. Items in a picker menu should display with default text color. A selected item should have the background and text colors defined for selected text.
Every picker should have a label. A picker without a label is ambiguous and not accessible.
In rare cases where context is sufficient and a label could be absent, make sure to have the design reviewed and approved by an accessibility expert. These should still include an aria-label in HTML (depending on the context, “aria-label” or “aria-labelledby”).
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.
When possible, the field button width should be wide enough so that any chosen menu items can be displayed in full.
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 pickers are optional, only the required fields should be given an asterisk or have labels appended with “(required)”. If most of the pickers are required, only the optional fields should be appended with “(optional)”. An asterisk should never be used to note that a picker is optional.
A picker’s description in the help text is can communicate what to select or how to select an option. This includes information such as:
The help text’s message should not simply restate the same information in the label in order to prompt someone to interact with a picker. Don’t add help text if it isn’t actually relevant or meaningful to a user in order to try to maintain layout continuity with other inputs that require help text.
The help text area also displays an error message. When a picker already includes help text and an error is triggered, the help text is replaced with error text. Once the error is resolved, the help text description reappears below the picker.
Since one gets replaced by the other, the language of the help text and error text need to work together to convey the same messaging. Help text explains the requirement or adds supplementary context for how to complete the interaction. Error text tells a user how to fix the error by re-stating the selection requirements or describing the necessary interaction. Make sure that the help text and the error text include the same essential information so that it isn’t lost if one replaces the other (e.g., minimum requirements).
Write error messaging in a human-centered way by guiding a user and showing them a solution — don’t simply state what’s wrong and then leave them guessing as to how to resolve it. Ambiguous error messages can be frustrating and even shame-inducing for users. Also, keep in mind that something that a system may deem an error may not actually be perceived as an error to a user.
Error text should be written in 1-2 short, complete sentences and in a clear and straightforward way. End sentences with a period, and never with an exclamation point. For pickers, the nature of the error is often related to something that needs to be fixed for in-line validation, so a helpful tone is most appropriate. For example, if someone were to miss selecting an option to note as their preferred contact method, write the error text like you’re offering a hint or a tip to help guide them to understand what needs to be selected: “Select a contact method.”
For RTL (right-to-left) languages, the layout of the picker is mirrored. Text and the checkmark are right-aligned while the chevron is left-aligned.
When the popover menu is closed:
|Space or Down Arrow||Opens the popover menu. The focus is set on the menu item selected.|
When the popover menu is open:
|Space||Selects the menu item in focus, closes the popover menu and moves focus to the field button.|
|Up or Down Arrow||Moves focus to previous or next menu item in the popover. Does not loop when the last or first menu item is reached.|
|Esc||Closes the popover menu and moves focus to the field button.|
|Dec 03, 2021||6.0.2|
|Feb 26, 2021||6.0.1|
|Apr 23, 2020||6.0.0|
|Feb 26, 2019||5.2.0|
|Aug 22, 2018||5.1.0|
|Aug 13, 2018||5.0.1|
|Apr 19, 2019||5.0.0|
Includes all interactive states that are applicable (hover, down, focus, keyboard focus, disabled).
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).
Color is not used as the only visual means of conveying information (WCAG 2.0 1.4.1).
Text has a contrast ratio of at least 4.5:1 for small text and at least 3:1 for large text (WCAG 2.0 1.4.3).
Visual information required to identify components and states (except inactive components) has a contrast ratio of at least 3:1 (WCAG 2.1 1.4.11).
UI language and information design considerations have been incorporated into component design.
Includes relevant options (variant, style, size, orientation, optional iconography, decorations, selection, error state, etc.)
Includes guidelines for keyboard focus, layout (wrapping, truncation, overflow), animation, interactions, etc.
Includes a list of dos and don'ts that highlight best practices and common mistakes.
Includes content standards or usage guidelines for how to write or format in-product content for the component.
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.
All design attributes (color, typography, layout, animation, etc.) are available as design tokens.
Includes a downloadable XD file that shows multiple options, states, color themes, and platform scales.
Includes a downloadable XD file, generated by code using design tokens defined in Spectrum DNA, and shows multiple options, states, color themes, and platform scales.
Component is included in the Spectrum for Adobe XD plugin.