Data Entry
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.
Labels can be placed on either side of a switch. Labels to the right, or end, are the default for consistency with other input types (checkbox, radio), but additional utility classes can be used for other label maximum widths and alignments. For example switch lists common in application settings etc.
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.
By default, switches are not emphasized. This 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 Primary, or emphasized, switch 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.
A switch can be navigated using a keyboard. The keyboard focus state takes the switch’s visual hover state and adds a ring to the button in focus, copying the color style of the variant.
When the label is too long for the horizontal space available, it wraps to form another line.
Description and implementation notes
<p> code example </p>Includes all interactive states that are applicable (hover, down, focus, keyboard disabled).
Works properly across all color schemes (light, dark).
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).
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 Figma file that shows multiple options, states, color themes, and platform scales.