Version 5.1.0

Text field

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.

Three text fields arranged vertically and labeled Email address, Password and Job title.

Anatomy#


Image illustrating through labels the component parts of a text field including its label, a required asterisk, character count, placeholder text, validation marker and the text field.

Options#


Key example displaying the standard option for a label with the text "Email address" on top of a text field with an email address as a placeholder.

Label#

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”).

Key example showing two text fields. The first field positions the label on top. The second field aligns the label on the left.

Label position#

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.

Key example showing a label on top of a text field. An example email address is placed as a placeholder inside the text field.

Placeholder#

The placeholder text, also commonly known as “ghost text,” is temporary and disappears once a user enters text.

Key example showing a text field with entered text and a label. The entered value of the text field appears in a darker text color than the placeholder color.

Value#

The value shows a user’s entered text.

Key example showing two text fields where the width of the second text field is wider.

Width#

The width of a text field can be customized appropriately for its context.

Key example showing the quiet text field option. The first text field follows the standard option and the second quiet text field has no visible background and the background color of the page appears behind the text.

Quiet#

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.

Image illustrating the required or optional label for three text fields. The first text field features the word "optional" in parentheses. the second field places "required" in parentheses and the last text field features an asterisk behind the label.

Required or optional#

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. Make sure to include hint text to explain what the asterisk means.

Key example showing a text field with a character count label above. The number 24 is displayed on the right side of the label, aligned with the right side of the text field, referring to 24 more characters that can be typed into the text field.

Character count#

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.

Key example showing a validated email text field with the label "Email address" and the typed in email address user@adobe.com. A green checkmark is placed in the right side of the field.

Validation icon#

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.

Key example showing the error option of a text field. The text field features a red border and a red alert icon is placed inside the text field on the right.

Error#

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.

Key example showing the disabled text field option. The text field background is grayed out, matching the gray border of the text field.

Disabled#

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.

Table of options#

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.

PropertyValuesDefault Value
label
text / nothing
label position
top / side
top
placeholder
text
value
text / nothing
width
number
is quiet
yes / no
no
necessity indicator
text / icon / nothing
icon
is required
yes / no
no
has character count
yes / no
no
show valid icon
yes / no
no
is error
yes / no
If there’s an error, this property overrides show valid icon.
no
is disabled
yes / no
no

Behaviors#


Key example displaying a standard and a quiet text field for entering the state id. "CA" for California is entered in both fields and enough padding surrounds the entered text.

Minimum width#

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.

Key example showing the overflow behavior for text field and text field label.

Text overflow#

When the field label is too long for the available horizontal space, it wraps to form another line. The field text itself truncates.

Key example showing the behavior for mixed values. The textfield value is an en dash for the label "Width".

Mixed value#

When a text field presents multiple values that are not identical, the field should show an en dash (–).

Usage guidelines#


Include a label#

Every text field should have a label. A field without a label is ambiguous and not accessible.

Key example showing the correct use of a label.
Key example showing the incorrect use of a label. The label is missing from the text field.

Review label-less designs#

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”).

Key example showing the correct use of a label-less text field. The text field is acting as a page counter for a pagination component, indicating page 2 followed by a text string containing the total page count "of 89 pages".

Follow capitalization rules#

Field labels and placeholder text should be in sentence case.

Key example showing the correct sentence case capitalization rule. The first letter of the label "Email address" is capitalized.
Key example showing the incorrect sentence case capitalization rule. The first letter of each word from the  label "Email Address" are capitalized.

Mark the minority of text fields in a form as optional or required#

In a single form, mark only the required fields or only the optional fields, depending on whichever mention is less frequent. For required text fields, there are two styling possibilities: a “(required)” label or an asterisk. Make sure to include hint text at the end of the form to explain what the asterisk means.

Key example showing the correct usage of limiting the required label. Two of the three text fields for the first name, last name and email address are required as the last label features the word "optional in parentheses.
Key example showing the incorrect usage of marking text fields as required. Two of the three text fields feature the word "required" in parentheses while the last text field does not feature the word "required" in the label marking it as optional.

Internationalization#


Key example featuring the usage of text fields for right-to-left languages. The three text fields and their labels are horizontally mirrored.

RTL#

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.

Keyboard interactions#


KeyInteraction
TabTabbing into a text field selects the existing text.

Changelog#


DateNumberNotes
Aug 22, 20195.1.0
  • Added text overflow behavior
Apr 19, 20195.0.0
  • This component is now individually versioned (individual versions of existing components start at 5.0.0)
  • Added RTL (right-to-left) guidelines

Design checklist#


All interactive states

Includes all interactive states that are applicable (hover, down, focus, keyboard focus, disabled).

Multiple options

Includes relevant options (variant, style, size, orientation, optional iconography, decorations, selection, error state, etc.)

All color themes

Works properly across all four color themes (lightest, light, dark, darkest).

All platform scales

Includes a desktop scale (UWP, macOS, web desktop) and a mobile scale (iOS, Android, web mobile).

Defined behaviors

Includes guidelines for layout (wrapping, truncation, overflow), animation, interactions, etc.

Usage guidelines

Includes a list of dos and don’ts that highlight best practices and common mistakes.

Accessible contrast

Follows WCAG 2.0 standards for contrast (AA).

Internationalization guidelines

Works properly across various locales and includes guidelines for bi-directionality (RTL).

Keyboard interactions

Follows WCAG 2.0 standards for keyboard accessibility guidelines and includes a description of the keyboard interactions.

Downloadable UI kit

Includes a downloadable XD file that has been generated by code and shows multiple variations, states, color themes, and scales.

Design tokens

All design attributes (color, typography, layout, animation, etc.) are included in Spectrum DNA.