Switches allow users to turn an individual option on or off. They are usually used to activate or deactivate a specific setting.
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.
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.
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.
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.
text / nothing
When the label is not defined, the switch appears as a standalone switch.
yes / no
yes / no
yes / no
When the label is too long for the horizontal space available, it wraps to form another line.
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.
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.
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.
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.
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.
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.
|Space||Toggles the switch between on and off.|
|Aug 22, 2019||6.1.0|
|Jul 31, 2019||6.0.0|
|Apr 19, 2019||5.0.0|
Includes all interactive states that are applicable (hover, down, focus, keyboard focus, disabled).
Includes relevant options (variant, style, size, orientation, optional iconography, decorations, selection, error state, etc.)
Works properly across all four color themes (lightest, light, dark, darkest).
Includes a desktop scale (UWP, macOS, web desktop) and a mobile scale (iOS, Android, web mobile).
Includes guidelines for layout (wrapping, truncation, overflow), animation, interactions, etc.
Includes a list of dos and don’ts that highlight best practices and common mistakes.
Follows WCAG 2.0 standards for contrast (AA).
Works properly across various locales and includes guidelines for bi-directionality (RTL).
Follows WCAG 2.0 standards for keyboard accessibility guidelines and includes a description of the keyboard interactions.
Includes a downloadable XD file that has been generated by code and shows multiple variations, states, color themes, and scales.
All design attributes (color, typography, layout, animation, etc.) are included in Spectrum DNA.