Sizing
A select has a flexible container - it can adapt in width to different screen sizes or specific contexts. A Select has a fixed height.
On the smaller screens (the smallest viewport range for web or mobile apps) a select generally occupies the full width of the container (with exceptions in case two fields form a horizontally stacked group).
On larger screens a maximum width applies. Adjust it accordingly to make sure there is enough room for the expected selection and to provide the best reading experience.
- Full-width sizing on small screens or within contained elements
- A select should have a maximum width to optimise for expected input and readability
- In some specific cases a select can form a group with a text field or another select. In this case, a combination of fixed width fields and full width fields could apply. The entire group itself it set to a maximum width
Spacing
Spacing is crucial for readable forms. Make sure to apply consistent spacing to provide the best experience. Though the spacing between individual fields is set by the consumer of the component, try to follow these guidelines as much as possible.
The spacing between individual vertically stacked fields should be set to 24px. The spacing between individual horizontally stacked fields should be set at 16px.
Layout and order
In general, a form field layout runs vertically from top to bottom using a single column layout. Try to stick to this as much as possible, opposed to creating a two or three column layout. A single-column layout allows users to easily move from one field to the other as they scroll down the screen, making the form easy to read and enables the user to fill out the form quickly. Only in very specific situations, take flight search for example, a multi-column layout could apply for larger viewports.
If you have the feeling that your form becomes too long, please check if all fields are necessary to have and/ or if some fields could form a logical horizontal grouping.
In terms of individual field order, try to start with the easy ones first before asking more complex information from the user. In that way, the user gets an immediate feeling of progression and is more likely to complete the form.
Error handling
When a required select has no selected value, an error is displayed right below the field it applies to. Try to stick to this as much as possible, opposed to other ways of handling errors, as it makes the error easy to locate and users can see the message and instructions while fixing it.
In situation with multiple errors a notification may be used to let users know that there are errors that need to be fixed, whether those errors are in the viewport or below the fold. This can give the user a global understanding of the errors and forces them to look for them. In a scenario like this, never use a notification only but combine them with error states for the individual fields. However, It is not always necessary to add the notification - when the form is short it is usually redundant.
Assistive elements
Hint text
The hint text can be displayed right below the label. It is an assistive text that can provide important additional help or context.
Placeholder text
A placeholder text is a temporary text in case no value has been selected. It disappears after the user has made a selection.
There is a difference between a hint text and a placeholder text. A hint text contains information or guidance that might be crucial to fill in the form correctly. It is important that it stays there when the user fills out the text field. A placeholder provides a temporary text when nothing has been selected yet.
Required vs optional
A form often contains both required and optional fields. A user should be aware of what information is required or optional while felling out the form. This prevents errors and keeps the user in a continuous flow. To do so, we mark the fields that are optional as most situations require mostly required information in order to proceed.
Accessibility considerations
Native selects, that is, the ones generated by the browser, have rich keyboard support. A user is going to expect that:
- Pressing enter, or alt+down arrow, opens the dropdown.
- Up and down arrow keys select a value.
- Enter, or tabbing awawy, commits the currently selected choice.
- Typing the first few characters of an option in the select, selects that option.
- Screen readers are aware of the currently selected option at all times.
A select requires an accessible name, either the visual label or an accessible label through ARIA. The first option of the dropdown is not a satisfactory label to the dropdown, similar to how placeholder text in a textfield cannot only be labeled by its default placeholder text.