Version 1.0.0

Field label

Field labels give context to the information that a user needs to input. They're commonly used in forms.

Anatomy#


Image illustrating through labels the component parts of a field label, including its label, required asterisk, and inputs.

Options#


Key example of a label for a field label. Label text, Country.

Label#

Inputs (text fields, checkboxes, sliders, etc.) 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 inputs without a visible label should still include an aria-label in HTML (depending on the context, “aria-label” or “aria-labelledby”).

2 key examples of field label placement. Label text, Country. Label positions on top of the input and to the left side of the input.

Label position#

A label can be placed either on top or on the side of an input. This option affects the bounding box of the component to ensure proper alignment. 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.

Image illustrating field label with necessity indicator sizing, beginning with the small size, then medium, large, and extra-large sizes.

Size#

Field labels come in four different sizes: small, medium, large, and extra-large. The medium size is the default and most frequently used option with medium-sized inputs. Use the other sizes sparingly; they should be used to create a hierarchy of importance within the page. Both small and medium field labels have the same font size, but different paddings when used as side labels.

Key example illustrating how to indicate that an input is necessary using an icon or text in the field label. For the icon necessity indicator, if the input is not required, there is no asterisk. If the input is required, there is an asterisk. For the text necessity indicator, if the input is not required, the label shows “(optional)” after the label name. If the input is required, the label shows “(required)” after the label name.

Necessity indicator (required or optional)#

Inputs can be marked as required or optional, depending on the situation, using a necessity indicator. There are two styles for the necessity indicator: icon or text.

By default, the necessity indicator is shown with an asterisk icon. Required inputs are marked with this at the end of the label. If you use this icon, be sure to include hint text to explain what it means. The asterisk used in this component is an icon that has specific spacing from the label text — not part of the label text itself. Optional inputs do not have an icon.

Alternatively, the necessity indicator can be shown with text. This appends text that reads either “(required)” or “(optional)” at the end of the label.

Key example of a field label in a disabled state. Label text, Country.

Disabled#

A field label 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 an input 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
size
small / medium / large / extra-large
small
necessity indicator
text / icon
icon
is required
yes / no
no
is disabled
yes / no
no

Behaviors#


Key example of text overflow behavior for a field label. Label text, What you’re hoping to learn from the seminar. Label text wrapped to 2 lines.

Text overflow#

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

Usage guidelines#


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

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 input fields are optional, only the required fields should be given an asterisk icon or have labels appended with “(required).” If most of the input fields are required, only the optional fields should be appended with “(optional).” An asterisk icon should never be used to note that a field is optional.

Key example of correct usage of marking fields as required or optional. Three inputs, labels Full name, Location, Profile description. Profile description field has text “(optional)" at the end of the field label.
Key example of incorrect usage of marking fields as required or optional. Three inputs, labels Full name, Location, Profile description. Full name and Location fields have text “(required)" at the end of the field labels.

Content standards#


For field label text, use a short, catch-all description (1-3 words) of the information that a user needs to provide. Field label text that gets too long can be overwhelming and distracting, especially in complex interactions and long forms. Supplementary information or requirements about what to input can be shown in help text below the field, or in a tooltip.

Use verbs like “enter,” “add,” or “input” in a field label sparingly#

Field labels generally communicate what a user should input, rather than direct them as to how to do it. The component design of fields and other inputs already implies that a user needs to enter, add, or input information in order to move forward with a task or workflow.

If the interaction may be new or unfamiliar it can be helpful to guide a user with action prompts using these verbs, but for more common patterns (such as forms), this can get redundant and clutter an interface.

Key example of correct way to write a field label. Label text, Personal email address.
Key example of incorrect way to write a field label. Label text, Enter your personal email address.

Don’t add a colon at the end of a field label#

Don’t add a colon (:) at the end of a field label to imply that the label text applies to the field it accompanies. The design of the component already communicates the relationship between the label and the input field.

Key example of correct way to write a field label. Label text, Name. No colon at the end of the label.
Key example of incorrect way to write a field label. Label text, Name:. Colon at the end of the label.

Use sentence case#

Following Adobe’s UX writing style, field labels are written in sentence case unless they contain words that are branded terms.

Key example of correct way to write a field label. Label text, Email address. Written as capital “E” in “Email,” lowercase “a” in “address.”
Key example of incorrect way to write a field label. Label text, Email address. Written as capital “E” in “Email,” capital “A” in “address.”

Internationalization#


Key example of a field label in Arabic. The field label text for “Email address” and necessity indicator asterisk are mirrored and right-aligned. Example input text, user@adobe.com, is also right-aligned with the beginning of the field.

RTL#

For RTL (right-to-left) languages, the layout of the field label is mirrored. The label is right-aligned. Make sure to consider that some types of content (e.g., email addresses) are not translated.

Changelog#


DateNumberNotes
Jan 11, 20211.0.0
  • This component has been added to the website

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

N/A

Keyboard interactions

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

Design tokens

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

Generated UI kit

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

In Spectrum for Adobe XD plugin

Component is included in the Spectrum for Adobe XD plugin.