Checkbox

COMPONENT GUIDE

Explore behaviors before defining the interface.

Quick guide for designers

Always consider the context of the application, even when the guidance follows a standard pattern. Interaction design documents intent. Behavior must be verified in the implementation.

When to use

Use for independent choices, allowing more than one selected option.

What to draw

Show labels, checked and unchecked states, focus, and disabled states. Include a mixed state when needed.

How it behaves

Clicking the control or label toggles selection. By keyboard, Tab reaches each available option and Space toggles its state.

What to document in Figma

Record the group name and toggling rules if a mixed state exists.

How to review

Check whether the purpose and states are clear on small and large screens and with zoom. Verify documented behavior in the implementation, including keyboard and screen reader use where applicable.

Full guidance

Interaction Design

Questions to ask when designing interactive components of type Checkbox.

Important:
Depending on the context in which you build your components, there may be further questions, and some listed here may not be necessary. Assess each case individually.

Designing for "no interaction"

Before interacting, can you tell that each option can be checked or unchecked?
When there is a group, does its label communicate the options' purpose?
Can you distinguish checked, unchecked, partially checked, and disabled states?

Designing for mouse use (any pointing device)

Is there visual feedback when hovering over the checkbox or its label?
Does clicking the label also change the checkbox state?
Is the state change visually clear?

Designing for gesture use

Does the touch target include the associated label?
Does tapping the label or control change the state?
Is the touch area comfortable on small screens?

Designing for keyboard use (any non-pointing device)

Is there visible focus on the checkbox?
Can the state be changed with SPACE?
Does navigation with TAB follow the form's expected order?

Designing for screen reader use

Is the checkbox label announced correctly?
Is the checkbox role announced?
Is the checked, unchecked, or mixed state announced?
Are error or help messages read with the field when present?

Interaction methods

Possible interaction methods for components of type Checkbox.

Important:
Only the main methods are listed here. Custom components require further study.

Mouse interaction (any pointing device)

Clicking the control or label toggles between checked and unchecked.
For mixed checkboxes, the rule for switching between mixed, checked, and unchecked must be predictable.
Disabled states should not perform actions.

Keyboard interaction (any non-pointing device)

TAB moves focus to each available checkbox.
SPACE toggles the focused checkbox's state.
SHIFT+TAB returns to the previous item in the flow.

Keyboard (or gesture) interaction + screen reader

The component must have a programmatically associated label.
Groups should use fieldset and legend when applicable.
The state should be exposed semantically.

Gherkin

BDD (Behavior-Driven Development) methodology focusing on three pillars: User Stories, Acceptance Criteria, and Gherkin Syntax (Given, When, Then).

Scenario: Given that I am on a page containing a checkbox

Keyboard navigation

WHEN I use the Tab key to move focus to a checkbox
The focus I SEE is strongly indicated visually
THEN, when I use the Space
I SEE the checkbox toggle between checked and unchecked

Desktop screen reader

When I use a screen reader on a computer (NVDA, JAWS, VoiceOver) and move focus to the component
- I HEAR the field's label and purpose.
- I HEAR that the component is a checkbox.
- I HEAR its current state, such as checked, unchecked, or mixed.
THEN, when I activate or change the component
I HEAR or perceive that its corresponding state, value, content, or action has been updated.

Mobile screen reader

WHEN I use a screen reader on a phone (TalkBack, VoiceOver) and swipe to focus the component, the following happens:
- I HEAR the field's label and purpose.
- I HEAR that the component is a checkbox.
- I HEAR its current state, such as checked, unchecked, or mixed.
THEN, when I double-tap or use the appropriate gesture to activate the component
I HEAR or perceive that its corresponding state, value, content, or action has been updated.

Considerations

Considerations for components of type Checkbox.

Do not use checkboxes when a person can choose only one option in a group; use radio buttons for that.
The label should be clickable and touchable and associated with the field.
Custom checkboxes need to preserve focus, name, role, and state.

References

Additional references for components of type Checkbox.

Important:
Most references are on the course platform alongside the lessons cited in this material.

Disclaimer:
The links listed here are a curated collection of references where you can find implemented components, rather than recommendations. There is no unified implementation format and no guarantee that these links follow every design pattern. Direct questions to the teams responsible for the linked materials. Before copying a model, remember that all materials are constantly updated and that patterns, particularly proprietary ones, may change.