Switch
Switches allow users to turn an individual option on or off. They are usually used to activate or deactivate a specific setting.
Anatomy#
Options#
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.
Selection#
Switches can either be selected or not selected. They cannot be in an indeterminate state (unlike checkboxes). When a switch represents multiple values that are not identical, the switch should appear as not selected.
Size#
Switches come in four different sizes: small, medium, large, and extra-large. The medium size is the default and most frequently used option. Use the other sizes sparingly; they should be used to create a hierarchy of importance within the page.
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.
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.
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.
Behaviors#
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.
Text overflow#
When the label is too long for the horizontal space available, it wraps to form another line.
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.
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.
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.
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.
Representing mixed values#
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.
No partial state#
Switches can only be on or off. Indeterminate switches don’t exist in accessibility APIs, so it’s not possible to make an indeterminate switch accessible. If you need to show a partial state, use a checkbox instead of a switch.
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).
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.
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.
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.
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
Use sentence case#
Following Adobe’s UX writing style, labels for switches are written in
Keyboard interactions#
Changelog#
- Updated read-only option design
- Updated disabled text color (from gray-500 to gray-400)
- Updated all colors to 6.0.0
- Added size option
- Updated keyboard focus state to be more accessible
- Added read-only option
- Added text overflow behavior
- Replaced “standard/quiet” variants with emphasis (“emphasized/not emphasized”)
- 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).
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).
Accessible use of color
Color is not used as the only visual means of conveying information (WCAG 2.0 1.4.1).
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).
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).
Content design
UI language and information design considerations have been incorporated into component design.
Defined options
Includes relevant options (variant, style, size, orientation, optional iconography, decorations, selection, error state, etc.)
Defined behaviors
Includes guidelines for keyboard focus, layout (wrapping, truncation, overflow), animation, interactions, etc.
Usage guidelines
Includes a list of dos and don'ts that highlight best practices and common mistakes.
Writing guidelines
Includes content standards or usage guidelines for how to write or format in-product content for the component.
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 available as design tokens.
UI kit
Includes a downloadable XD file that shows multiple options, states, color themes, and platform scales.
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.
In Spectrum for Adobe XD plugin
Component is included in the Spectrum for Adobe XD plugin.