Data Entry
Selects (sometimes known as "dropdowns" or "pickers") allow users to choose from a list of options in a limited space. The list of options can change based on the context.
Selects 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 select can be customized appropriately for its context.
Selects come in three different sizes: small, medium, and large. The medium size is the default and most frequently used option. Use the other sizes sparingly; they should be used to create a hierarchy of importance within the page.
By default selects are assumed required and have no indication at all (such as an asterisk, as hint text would then need to be included to explain what it means). Text fields can be marked as optional. Optional text fields are denoted with text added to the end of the label — “(optional)”.
A select 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. If an error exists, the error icon always overrides any other icon.
A select 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.
Selects 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 select does not have a read-only option if no selection has been made.
A select 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.
The minimum width for a select is 2× the height of the field. This guarantees that small selects 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 can wrap to form another line. The field text itself truncates at the end, but the text can be shown in full in the menu. Note; browser defaults tend to make the options as wide as the longest option in the list and may wrap at the viewport width.
When the help text is too long for the available horizontal space, it wraps to form another line.
The select menu can be as tall as necessary to show as many options as possible in the available space. There is no maximum height.
Description and implementation notes
<p> code example </p>Includes all interactive states that are applicable (hover, down, focus, keyboard disabled).
Works properly across all color schemes (light, dark).
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).
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 Figma file that shows multiple options, states, color themes, and platform scales.