Text fields are text boxes that allow users to input custom text entries with a keyboard. Various decorations can be displayed around the field to communicate the entry requirements.
Text fields 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 text fields 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.
The width of a text field can be customized appropriately for its context.
By default, text fields 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 text fields 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.
Text fields can be marked as optional or required, depending on the situation. For required text fields, 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 text fields 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.
Text fields can display a character count indicator when the length of the text entry needs to be kept under a predefined value. Character count indicators can be used in conjunction with other indicators (validation icon, “optional” or “required” indicators) when necessary.
Text fields can display a validation icon when the text entry is expected to conform to a specific format (e.g., email address, credit card number, password creation requirements, etc.). The validation icon appears as soon as a user types a valid entry in the field.
A text field 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 the validation icon.
A text field 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 a field may become available later.
Text fields 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 text field does not have a read-only option if there is nothing entered in it.
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
text / icon / nothing
yes / no
|has character count|
yes / no
|show valid icon|
yes / no
yes / no
If there’s an error, this property overrides show valid icon.
yes / no
yes / no
The minimum width for a text field is 1.5× the height of the field, for both standard style and quiet style. This minimum width guarantees that small text fields are readable and easy to target on touch devices.
When the field label is too long for the available horizontal space, it wraps to form another line. The field text itself truncates.
When a text field presents multiple values that are not identical, the field should show an en dash (–).
Every text field should have a label. A field 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”).
Field labels and placeholder text 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 text fields are optional, only the required fields should be give an asterisk or have labels appended with “(required)”. If most of the text fields are required, only the optional fields should be appended with “(optional)”. An asterisk should never be used to note that a text field is optional.
For RTL (right-to-left) languages, the layout of the text field is mirrored. The label is right-aligned and various decorations (character count, validation marker, error icon) are left-aligned. Make sure to consider that some types of content (e.g., email addresses) are not translated.
|Tab||Tabbing into a text field selects the existing text.|
|Feb 26, 2020||5.2.0|
|Aug 22, 2019||5.1.0|
|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.