Version 6.1.0

Switch

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

Group of three switches. The first switch is selected. The label "available offline" is on the right side of the first switch. The track color is blue and the white switch handle is on the right side of the switch.
Two unselected switches below with a gray track color and a darker gray outline and a left aligned handle and the labels "require password" and "allow commenting".

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.

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

Behaviors#


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.

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.

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
Aug 22, 20196.1.0
  • Added text overflow behavior
Jul 31, 20196.0.0
  • Replaced “standard/quiet” variants with emphasis (“emphasized/not emphasized”)
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.