semantic pattern · Choice and binary state controls
Switch
A binary control that represents whether an ongoing setting or feature is on or off.
Decisive boundary
If the user is selecting an item rather than turning a setting on or off, use a Checkbox or Radio Group; if the element must remain a button, use a Toggle Button.
Definition and intent
What is a Switch UI pattern?
Use the behavior, not the silhouette
A binary control that represents whether an ongoing setting or feature is on or off. The term is used here as a semantic pattern whose role and interaction contract carry more meaning than its appearance. That distinction prevents a visual resemblance from silently deciding focus, keyboard, modality, or dismissal behavior.
Let users directly change and perceive an ongoing binary setting. A good implementation preserves that job while making the trigger, open state, close path, and responsive behavior observable to users.
Know when the label is wrong
The fastest way to identify a pattern is often to reject the nearest alternative. For Switch, the boundary is: If the user is selecting an item rather than turning a setting on or off, use a Checkbox or Radio Group; if the element must remain a button, use a Toggle Button.
Do not implement it as a Checkbox for a setting whose on or off consequence must be explicit, a Radio Group for two visible named choices, or a Toggle Button for non-button semantics If those requirements describe the real task better, use the related pattern page or the full Choice and binary state controls comparison before writing code.
Decision process
Decide before choosing a component
Record these requirements in plain language. A library component name is not a substitute for the contract.
Confirm the user job
Let users directly change and perceive an ongoing binary setting.
Define opening and closing
Pointer activation or pressing Space while the switch has focus. There is no open surface; activating again changes the on or off state.
Specify access behavior
Focus remains on the switch after its state changes. Space toggles the switch; Enter may also activate it when the implementation documents that behavior.
Reject the near miss
a Checkbox for a setting whose on or off consequence must be explicit, a Radio Group for two visible named choices, or a Toggle Button for non-button semantics
Behavior contract
What must survive the build
- trigger
- Pointer activation or pressing Space while the switch has focus.
- dismissal
- There is no open surface; activating again changes the on or off state.
- modality
- Inline and non-modal.
- focus
- Focus remains on the switch after its state changes.
- keyboard
- Space toggles the switch; Enter may also activate it when the implementation documents that behavior.
- interactive
- The switch is one control with a stable accessible label.
- persistence
- The on or off setting remains until the user or application changes it.
- placement
- Beside the setting name and, when needed, a short consequence description.
- mobile
- Keep the label stable, the current state visible, and the complete row safely tappable when designed as one control.
- state
- On or off, exposed through true or false checked state; mixed is not a valid switch state.
- choice
- Changes one ongoing binary setting rather than selecting an item from a set.
- grouping
- May appear with other settings, but each switch keeps its own label and state.
Failure modes
Common wrong builds
- Changing the accessible label from Enable to Disable when state changes.
- Using mixed state on a switch.
- Delaying the visible state change without explaining pending work.
Observable checks
Verify the result
- Space toggles the focused switch.
- The accessible state matches on or off visually.
- The label remains unchanged when the state changes.
- Mixed state is never exposed.
- The control communicates its current state without relying only on color.
- The setting consequence is understandable before activation.
Coding-agent handoff
Implementation brief template
Pattern: Switch Purpose: Let users directly change and perceive an ongoing binary setting. Trigger: Pointer activation or pressing Space while the switch has focus. Dismissal behavior: There is no open surface; activating again changes the on or off state. Modality: Inline and non-modal. Focus behavior: Focus remains on the switch after its state changes. Keyboard behavior: Space toggles the switch; Enter may also activate it when the implementation documents that behavior. Interactive content: The switch is one control with a stable accessible label. Placement: Beside the setting name and, when needed, a short consequence description. Mobile behavior: Keep the label stable, the current state visible, and the complete row safely tappable when designed as one control. Do not implement as: a Checkbox for a setting whose on or off consequence must be explicit, a Radio Group for two visible named choices, or a Toggle Button for non-button semantics Acceptance checks: - Space toggles the focused switch. - The accessible state matches on or off visually. - The label remains unchanged when the state changes. - Mixed state is never exposed. - The control communicates its current state without relying only on color. - The setting consequence is understandable before activation.
Claim-level references
Sources, not a confidence score
Frequently asked questions
Switch UI pattern questions
Direct answers based on the reviewed behavior contract above.
What is a Switch in web UI?
A binary control that represents whether an ongoing setting or feature is on or off. In this reference set it is a semantic pattern whose role and interaction contract carry more meaning than its appearance.
When should I use a Switch?
Let users directly change and perceive an ongoing binary setting. The decisive boundary to confirm is this: If the user is selecting an item rather than turning a setting on or off, use a Checkbox or Radio Group; if the element must remain a button, use a Toggle Button.
What keyboard and focus behavior does a Switch need?
Space toggles the switch; Enter may also activate it when the implementation documents that behavior. Focus remains on the switch after its state changes. These statements describe the reviewed expectation, but the final implementation still needs testing in the component library and browser you ship.
How should a Switch behave on mobile?
Keep the label stable, the current state visible, and the complete row safely tappable when designed as one control. Its modality is a separate requirement: Inline and non-modal.
How do I verify a Switch implementation?
Start with observable checks: Space toggles the focused switch. The accessible state matches on or off visually. The label remains unchanged when the state changes. Then verify the remaining checks and compare the result with the linked source guidance.