Field label

Version 3.0.0

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

2 examples of field labels. First example, field label for a text field, label Email address, input text user@adobe.com. Second example, a group of radio buttons, field label Account type, radio button labels Admin, Member, Guest. Admin radio button in selected state.

Table of contents

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 (, , , 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.

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.

do
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.
dont
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.

do
Key example of correct way to write a field label. Label text, Personal email address.
dont
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.

do
Key example of correct way to write a field label. Label text, Name. No colon at the end of the label.
dont
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.

do
Key example of correct way to write a field label. Label text, Email address. Written as capital “E” in “Email,” lowercase “a” in “address.”
dont
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.

Theming#

A theme is an intentional, systematic customization of Spectrum. It has unique visual attributes. For more information, view Theming.

Key example of a field label in the Spectrum for Adobe Express theme with an asterisk icon as the necessity indicator, label Full name.

Spectrum for Adobe Express#

Field labels remain the same across themes.

Changelog#

Design checklist#

check

All interactive states

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

check

All color themes

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

check

All platform scales

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

check

Accessible use of color

Color is not used as the only visual means of conveying information (WCAG 2.0 1.4.1).

check

Accessible contrast for text

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

check

Accessible contrast for UI components

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

check

Content design

UI language and information design considerations have been incorporated into component design.

check

Defined options

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

check

Defined behaviors

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

check

Usage guidelines

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

check

Writing guidelines

Includes content standards or usage guidelines for how to write or format in-product content for the component.

check

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.

check

Design tokens

All design attributes (color, typography, layout, animation, etc.) are available as design tokens.

check

UI kit

Includes a downloadable XD file that shows multiple options, states, color themes, and platform scales.

check

Generated UI kit

Includes a downloadable XD file, generated by code using design tokens defined in Spectrum DNA, and shows multiple options, states, color themes, and platform scales.

check

In Spectrum for Adobe XD plugin

Component is included in the Spectrum for Adobe XD plugin.