What it must accomplish
Make an on/off state visible and directly controllable.
Usage
Choose the control by behavior
- The setting has two opposing states
- The change can take effect immediately
- People benefit from seeing the current state before changing it
- The choice is submitted with a form; a checkbox may be clearer
- More than two options exist
- The control starts an action instead of changing a state
Anatomy
Stable parts create a reliable contract
- 1Track
- 2Thumb
- 3Persistent label
- 4Optional state text
- 5Optional description
Interaction and keyboard behavior
- Tab moves focus to the switch
- Space toggles its state
- A state change should not unexpectedly move focus
Visual similarity does not guarantee behavioral equivalence. The component contract must preserve state, focus, semantics, and recovery across input methods.
Accessible behavior
- Expose a stable accessible name and current checked state
- Do not rely on thumb position or color alone
- Keep the label unchanged when the state changes
- Announce failures if the immediate update cannot be saved
Responsive considerations
Adapt the decision—not only the dimensions
Keep the label and control on the same row when possible, but allow long labels to wrap without shrinking the target.
Content considerations
Language is part of the component
- Name the setting, not the action of toggling it
- Use explicit On/Off text when context is not sufficient
- Explain side effects before the control
Patterns that weaken the experience
Changing the label from Enable to Disable
Using a switch for a destructive action
Requiring a separate Save button after implying immediacy
Optimistically changing state without handling failure
Comparison
What to study across systems
Material and Fluent expose switches as stateful controls; Apple platform conventions strongly influence size and motion; web implementations still need native semantics and visible focus.
Open comparison