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.
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.
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
yes / no
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.
When the label is too long for the horizontal space available, it wraps to form another line.
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.
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.
When a switch represents multiple values that are not identical, the switch should appear as not selected. Any subsequent click or tap should select the switch, and update all values to be selected. Another click or tap after that should deselect the switch, and update all values to be not selected.
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.
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.
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.
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.
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.
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.
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.|
|Apr 13, 2020||6.2.1|
|Feb 26, 2020||6.2.0|
|Aug 22, 2019||6.1.0|
|Jul 31, 2019||6.0.0|
|Apr 20, 2019||5.0.0|
Includes all interactive states that are applicable (hover, down, focus, keyboard focus, disabled).
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).
Color is not used as the only visual means of conveying information (WCAG 2.0 1.4.1).
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).
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).
UI language and information design considerations have been incorporated into component design.
Includes relevant options (variant, style, size, orientation, optional iconography, decorations, selection, error state, etc.)
Includes guidelines for keyboard focus, layout (wrapping, truncation, overflow), animation, interactions, etc.
Includes a list of dos and don'ts that highlight best practices and common mistakes.
Includes content standards or usage guidelines for how to write or format in-product content for the component.
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.
All design attributes (color, typography, layout, animation, etc.) are available as design tokens.
Includes a downloadable XD file that shows multiple options, states, color themes, and platform scales.
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.
Component is included in the Spectrum for Adobe XD plugin.