Adobe Logo

Spectrum

Version 6.2.1

Switch

Switches allow users to turn an individual option on or off. They are usually used to activate or deactivate a specific setting.

Table of contents#

Anatomy#

Image illustrating through labels the component parts of a switch in selected and unselected state. The unselected switch places the handle on the left side of the switch track. The track color is lighter and an a darker outline is set on the switch handle. The selected switch features a handle that is on the right side of the switch track and a darker color for the track. The outline of the switch matches the dark track color. A label is placed on the right side for both switches.

Options#

Key example showing two switch groups for the option with label and standalone. A label is place on the right side of the first two switches. No label is placed next to the standalone switches.

Label#

Switches should always have labels. When the label is not defined, a switch becomes standalone. Standalone switches should only be used when their connection to other components is clear and they give sufficient context — for example, in application panels.

Key example showing the option for switch emphasis. Two switch groups with two switches each show the selected and unselected state. The color of the emphasized and selected switch is blue. The color of the not emphasized and selected switch is dark gray.

Emphasis#

By default, switches are not emphasized (gray). This version is optimal for when the switch is not the core part of an interface, such as in application panels, where all visual components are monochrome in order to direct focus to the content.

The emphasized (blue) version provides a visual prominence that is optimal for forms, settings, lists or grids of assets, and other situations where a switch needs to be noticed.

Key example showing the option for disabled switches. Two switches and switch label in a light gray color are disabled. The first switch is selected.

Disabled#

A switch in a disabled state shows that a selection exists, but is not available in that circumstance. This can be used to maintain layout continuity and communicate that an action may become available later.

Key example of read-only switches. Label, Label. Switches shows visual change when moused over, but text can still be selected.

Read-only#

Switches have a read-only option for when they’re in the disabled state but still need their labels to be shown. This allows for content to be copied, but not interacted with or changed.

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
When the label is not defined, the switch appears as a standalone switch.
–
is selected
yes / no
no
is emphasized
yes / no
no
is disabled
yes / no
no
is read-only
yes / no
no

Behaviors#

Switch placeholder labels, off, in focus.

Keyboard focus#

A switch can be navigated using a keyboard. The keyboard focus state takes the switch’s visual hover state and adds a blue ring to the switch in focus.

Key example of the text overflow behavior for switches. A selected and emphasized switch is placed on the left of a long switch label text. The long text breaks into a new line and is flushed-left at the same column as the first word of the label.

Text overflow#

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

Key example of the mixed value behavior for switches. A single switch is in the unselected state.

Mixed value#

When a switch presents multiple values that are not identical, the switch should appear as turned off. Any subsequent click or tap should turn the switch on, and update all values.

Key example of switch in Windows “high contrast black” theme with label “Switch”, selected switch with label “Selected switch”, and disabled radio with label “Disabled switch”.

Windows high contrast mode#

In Windows high contrast mode, switches should be displayed using the high contrast theme-specified colors for buttons. By default, borders should be the same as the button text color and labels should use default text color. In hover and keyboard focus states, a border should display as the button border color. A selected switch fill and border should be the same as button border color. In the disabled state, border and text color should display as the disabled color.

Switch (Windows high contrast mode) UI kit

Usage guidelines#

Emphasized or not?#

Emphasized switches are optimal for forms, settings, and other scenarios where the switches need to be noticed. Not emphasized switches are optimal for application panels where all the visual components are monochrome in order to direct focus to the canvas.

Key example showing the correct usage of emphasized switches. The first switch group in a form enable local storage and wifi features. The two switches are selected and the track color is blue. The second switch group show one switch in the not emphasized option inside an application panel. The switch selected and the track color is dark gray.

When to use a standalone switch?#

Standalone switches should be used in situations where the context is clear without an associated text label. For example, a switch located at the top of a panel next to the panel's title makes it clear that the switch will enable/disable the panel options.

Key example showing the correct usage of a standalone switch. A not emphasized switch without a label is placed inside an application panel. The switch is selected.

Switch or checkbox?#

Switches are best used for communicating activation (e.g., on/off states), while checkboxes are best used for communicating selection (e.g., multiple table rows). Switches, unlike checkboxes, can't have an error state.

Key example showing the correct usage for switches. A single switch with the label "Wifi" is selected.
Key example showing the incorrect usage of a switch. A switch labeled "agree to terms" is selected.

No partial state#

Switches can only be on or off. When a parent switch represents a group of switches, it should be turned off unless all of the switches are on (turning the parent switch on turns all of the switches on). To show a partial state, use checkboxes instead.

Key example showing the incorrect usage of a partial state. A single switch on top of a group of three switches has the handle set in the center of the track. Two of the grouped switches are selected and one is unselected.

Content standards#

A label for a switch describes a setting that is either on or off — two mutually exclusive states. Use a short description (1-3 words) of the setting. Try to include all necessary information in the label, but it’s OK to add clarifying text after to supplement if needed.

Keep in mind that when a user takes an action on a switch, that action will often affect other content in an experience. Think systematically to ensure that all labels are paralleling each other in their writing.

Consider if the label should use a verb or a noun#

A switch shows a state of persistence for something — a noun or a proper noun — as either being “on” or “off.” A verb isn’t usually needed to communicate the thing being turned on or off, but there can be instances where phrasing the label as a verb can aid in clarity. Just try to keep switches consistently using either verbs or nouns if you have more than one of them in a single view.

Correct usage of how to write labels for a switch. Labels, Set date and time automatically. Show admin view.
Incorrect usage of how to write labels for a switch. Labels, Date and time automatic. Admin.

Avoid using verb phrases related to a state of activity#

Avoid using verb phrases related to activity states in a switch label, such as “turn on” or “turn off.” A switch is naturally either in a state of being on or off — active or inactive — so repeating in the label that something is “on” or “off” is redundant and clutters an interface.

Correct usage of how to write labels for a switch. Label, Wifi assist.
Incorrect usage of how to write labels for a switch. Label, turn on Wifi assist.

Use a neutral tone#

Because switches are used for controls and utility, their labels are written in a neutral, utilitarian way. There’s no need for overly celebratory language.

Correct usage of how to write labels for a switch. Label, Wifi assist.
Incorrect usage of how to write labels for a switch. Label, Turn on wifi assist for extra speed!

Use “you” or “your” if needed to refer to the user directly#

Describe switches objectively by using only the names of features or settings, or what those features and settings will do. In the case where it’s necessary to refer to a user directly, do so sparingly and use the second person “you/your.” We aim to be conversational and talk to the user — not as them.

Correct usage of how to write labels for a switch. Labels, Show unresolved comments. Show your unresolved comments.
Incorrect usage of how to write labels for a switch. Labels, My unresolved. Show my unresolved comments.

Use sentence case#

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

Correct usage of how to write labels for a switch. Labels, Save cloud documents locally, using sentence case. Always add to Project, using sentence case except for the word “Project,” which is capitalized.
Incorrect usage of how to write labels for a switch. Labels, Save Cloud Documents Locally. Always Add to Projects. Both label examples using title case where all words are capitalized.

Internationalization#

Key example showing two switches in the right-to-left language use case. The switches are placed on the right side of the switch label.

RTL#

For RTL (right-to-left) languages, the layout of the switch is mirrored. The track is placed on the right side of the text and the handle is positioned to the left when the switch is turned on.

Keyboard interactions#

KEYINTERACTION
SpaceToggles the switch between on and off.

Changelog#

DateNumberNotes
Apr 13, 20206.2.1
  • Updated keyboard focus state to be more accessible
Feb 26, 20206.2.0
  • Added read-only option
Aug 22, 20196.1.0
  • Added text overflow behavior
Jul 31, 20196.0.0
  • Replaced “standard/quiet” variants with emphasis (“emphasized/not emphasized”)
Apr 20, 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.

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.