Switch

🧭 When to Use a Switch

Use a Switch when:

• The action occurs immediately (e.g., turn notifications on/off)

• You need to clearly represent system or feature states

• The user should not need to click a submit button to confirm the change

Avoid Switches when:

• A user needs to select multiple options — use a Checkbox

• Selection is part of a form submission — use a Checkbox or Radio Button

• The on/off choice isn’t clear or needs confirmation — use a Button

🎚️ Switch Item

The Switch Item is the visual toggle with a track and a thumb. It does not include a label or helper text by default.

🎯 Statuses

• Default – Idle, waiting for interaction

• Hover – Slight highlight or elevation on track or thumb

• Focus – Visible ring or glow for keyboard navigation

• Disabled – Inactive and dimmed

• Error – Indicates an issue with the setting or interaction (e.g., “You must accept terms before proceeding”)

Error states should be visually distinct, often with a red border or shadow, and may include an icon or helper message.

🎨 Types

• Unselected – Switch is off

• Selected – Switch is on

There is no indeterminate or mixed state for Switches — they are always binary.

📏 Sizes

• Large (lg) – Use in mobile UIs or with high emphasis (e.g., featured settings)

• Medium (md) – Default; works well in most desktop and form layouts

Size affects the overall track width, thumb size, and spacing from the label.

🧩 Switch (Component)

The full Switch component includes:

• A Switch Item (interactive track + thumb)

• A Label – Clearly states what the switch controls

• Optional Subtext – Additional explanation or state-specific messaging (e.g., "This will affect your public profile")

All parts are vertically aligned and use token-based spacing for consistency.

This component supports:

• All the same statuses as the Switch Item

• All types (selected/unselected)

• The error variant, with visual cues and space for feedback

♿ Accessibility Considerations

From a design perspective:

• Use a clear label — Switches should never be unlabeled

• Visually differentiate the “on” and “off” states, especially in dark mode

• Use subtext sparingly and only when clarification is needed

From a code perspective (if implemented):

• Use <input type="checkbox" role="switch">

• Use aria-checked="true" or false to describe current state

• Always include a visible label (or aria-label)

• For error states, link error text with aria-describedby and use aria-invalid="true"

✅ Best Practices

• Only use Switches for instant-action toggles

• Avoid using Switches when confirmation is required

• Do not mix Switches and Checkboxes in the same group

• If you include an error state, be sure the message clearly explains what’s wrong and how to resolve it