semantic pattern · Choice and binary state controls

Checkbox

A control that represents checked, unchecked, or optionally mixed state for one independent choice or each item in a multiple-choice group.

reviewpublishedV1 field note

Decisive boundary

If exactly one option in a visible set may be selected, use a Radio Group; if the task turns an ongoing setting on or off, consider a Switch.

Definition and intent

What is a Checkbox UI pattern?

Use the behavior, not the silhouette

A control that represents checked, unchecked, or optionally mixed state for one independent choice or each item in a multiple-choice group. 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 include or exclude independent choices while exposing checked state clearly. 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 Checkbox, the boundary is: If exactly one option in a visible set may be selected, use a Radio Group; if the task turns an ongoing setting on or off, consider a Switch.

Do not implement it as a Radio Group for multiple independent choices, a Switch for item selection, or a Toggle Button when the control is not a button 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 include or exclude independent choices while exposing checked state clearly.

Define opening and closing

Pointer activation or pressing Space while the checkbox has focus. There is no open surface; activating again changes the checked state according to the application rule.

Specify access behavior

Focus remains on the checkbox that changed. Space changes the state of the focused checkbox.

Reject the near miss

a Radio Group for multiple independent choices, a Switch for item selection, or a Toggle Button when the control is not a button

Behavior contract

What must survive the build

trigger: Pointer activation or pressing Space while the checkbox has focus.
dismissal: There is no open surface; activating again changes the checked state according to the application rule.
modality: Inline and non-modal.
focus: Focus remains on the checkbox that changed.
keyboard: Space changes the state of the focused checkbox.
interactive: The checkbox is the control; its visible label activates the same control when correctly associated.
persistence: The checked state remains until the user, form, or application changes it.
placement: Beside a visible label; related checkboxes may be presented as a labeled group.
mobile: Provide a visible label and a touch target large enough to activate without relying on the small box alone.
state: Checked or unchecked, with mixed allowed when a tri-state relationship is genuinely required.
choice: Supports one independent binary choice or zero, one, or several selections in a group.
grouping: Use a labeled group when several checkboxes answer one shared question.

Failure modes

Common wrong builds

Using checkboxes when exactly one answer is allowed.
Showing a mixed visual state without exposing mixed semantics.
Leaving the checkbox without an accessible label.

Observable checks

Verify the result

Space changes the focused checkbox state.
The accessible state matches the visible state.
A mixed state is used only when its parent-child meaning is defined.
The label activates the intended checkbox.
Each item can be selected independently when multiple choices are promised.
The group has a shared accessible label when needed.

Coding-agent handoff

Implementation brief template

Pattern: Checkbox
Purpose: Let users include or exclude independent choices while exposing checked state clearly.
Trigger: Pointer activation or pressing Space while the checkbox has focus.
Dismissal behavior: There is no open surface; activating again changes the checked state according to the application rule.
Modality: Inline and non-modal.
Focus behavior: Focus remains on the checkbox that changed.
Keyboard behavior: Space changes the state of the focused checkbox.
Interactive content: The checkbox is the control; its visible label activates the same control when correctly associated.
Placement: Beside a visible label; related checkboxes may be presented as a labeled group.
Mobile behavior: Provide a visible label and a touch target large enough to activate without relying on the small box alone.
Do not implement as: a Radio Group for multiple independent choices, a Switch for item selection, or a Toggle Button when the control is not a button
Acceptance checks:
- Space changes the focused checkbox state.
- The accessible state matches the visible state.
- A mixed state is used only when its parent-child meaning is defined.
- The label activates the intended checkbox.
- Each item can be selected independently when multiple choices are promised.
- The group has a shared accessible label when needed.

Claim-level references

Sources, not a confidence score

01Checkbox PatternW3C WAI-ARIA Authoring Practices · Official accessibility guidance

Checked, unchecked, mixed state, labeling, grouping, and Space key behavior

Frequently asked questions

Checkbox UI pattern questions

Direct answers based on the reviewed behavior contract above.

What is a Checkbox in web UI?

A control that represents checked, unchecked, or optionally mixed state for one independent choice or each item in a multiple-choice group. 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 Checkbox?

Let users include or exclude independent choices while exposing checked state clearly. The decisive boundary to confirm is this: If exactly one option in a visible set may be selected, use a Radio Group; if the task turns an ongoing setting on or off, consider a Switch.

What keyboard and focus behavior does a Checkbox need?

Space changes the state of the focused checkbox. Focus remains on the checkbox that changed. These statements describe the reviewed expectation, but the final implementation still needs testing in the component library and browser you ship.

How should a Checkbox behave on mobile?

Provide a visible label and a touch target large enough to activate without relying on the small box alone. Its modality is a separate requirement: Inline and non-modal.

How do I verify a Checkbox implementation?

Start with observable checks: Space changes the focused checkbox state. The accessible state matches the visible state. A mixed state is used only when its parent-child meaning is defined. Then verify the remaining checks and compare the result with the linked source guidance.