semantic pattern · Choice and binary state controls

Switch

A binary control that represents whether an ongoing setting or feature is on or off.

Switch behavior diagram
reviewpublishedV1 field note

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.

01

Confirm the user job

Let users directly change and perceive an ongoing binary setting.

02

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.

03

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.

04

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.