UX Patterns Guide

Foundation · lesson 2 of 20 · Selection And Choice

Checkbox group

Underlying principle: Choice controls express how many options are available, how many may be selected, and when the selection takes effect. The control should reveal the meaning and consequence of each choice.

Show native checkboxes in a labeled group with a select-all-that-apply hint, independent checked states, clickable labels, and group validation when a minimum or limit applies.

Start with the decision

Does this fit your task?

Users can choose zero, one, or many options.

Review the boundary: Compare the task with the alternatives in the decision section.

Review the decision →
Try the live example →Compare alternatives →
Study the interaction

Follow the task before choosing the component

Choice controls express how many options are available, how many may be selected, and when the selection takes effect. The control should reveal the meaning and consequence of each choice.

01 / Recognize the need

What the person is doing

Users need to review all available options and the selected set before submitting.

02 / Design the response

What the interface must communicate

Show native checkboxes in a labeled group with a select-all-that-apply hint, independent checked states, clickable labels, and group validation when a minimum or limit applies.

Unchecked option state.

03 / Judge the outcome

What to look for

Are these choices truly independent, and should users see them all together?

The selected set remains visible in the list and in any summary text.

Practice this pattern: Sketch checkbox group for this situation: Users can choose zero, one, or many options. Include this state: Unchecked option state. Review your sketch with this question: Are these choices truly independent, and should users see them all together?

Study the Selection And Choice family →Read the underlying principle →
Decision first

Choose this pattern when the problem matches

Use when

  • Users can choose zero, one, or many options.

Avoid when

  • Only one option can be selected.
  • The option set is long, dynamic, or needs search.
  • The selected values need compact chip management or async loading.

Problem it prevents

Users need to review all available options and the selected set before submitting.

Test the behavior

Try strong and weak versions of the interaction

Open the working example, try its controls, and compare the behavior against the decision guidance.

In the lab you can
  • switch between strong UI, weak UI, strong UX, and weak UX;
  • trigger required, empty, loading, error, and recovery states;
  • inspect keyboard and accessibility expectations beside the demo.
Launch Checkbox group in the lab
Pattern anatomy

What a strong implementation has to make clear

User need

Users need to review all available options and the selected set before submitting.

Pattern promise

Show native checkboxes in a labeled group with a select-all-that-apply hint, independent checked states, clickable labels, and group validation when a minimum or limit applies.

Required state

Unchecked option state.

Failure to inspect

A hidden all-or-nothing option.

Access contract

Use programmatic labels for every checkbox.

Quality bar

The difference between expert and weak execution

Strong implementation

Specific, visible, recoverable

  • Visible checkboxes with large hit areas, persistent labels, group legend, and aligned helper text.
  • Clicking the label toggles the checkbox.
  • Users can select multiple independent choices and review the selected set before submit.
Weak implementation

Vague, hidden, hard to recover from

  • Tiny custom boxes that are hard to target.
  • Using checkboxes for mutually exclusive choices.
  • Losing checked values after validation or page refresh.
  • A hidden all-or-nothing option.
UI guidance
  • Render visible native checkboxes with labels, checked states, group legend, select-all-that-apply hint, and group validation state.
  • Keep all short-list independent options visible for comparison and review.
UX guidance
  • Let users choose independent options and review the selected set before submitting.
  • Communicate minimum, maximum, required, or select-all-that-apply rules before errors occur.
Implementation contract

What the implementation must handle

States

  • Unchecked option state.
  • One or more checked option states.
  • Focused checkbox state.
  • Group validation state when required, limited, or left empty.

Interaction

  • The selected set remains visible in the list and in any summary text.

Accessibility

  • Use programmatic labels for every checkbox.
  • Group related checkboxes with a fieldset and legend or equivalent.
  • Associate group hints and errors through descriptions when available.
  • Tab moves between checkboxes.

Review

  • Are these choices truly independent, and should users see them all together?
  • Can the user tell how many options may be selected before they submit?
Evidence trail

Source-backed claims behind this guidance

GOV.UK Design System Checkboxes component

Government Digital Service - checked

GOV.UK checkbox guidance supports one-or-more selections, fieldset/legend grouping, select-all-that-apply hints, errors, and independent checked values.

U.S. Web Design System Checkbox component

U.S. Web Design System - checked

USWDS checkbox guidance supports multiple answers, selectable labels, vertical lists, positive labels, touch spacing, and fieldset/legend grouping.

WAI-ARIA APG Checkbox Pattern

W3C Web Accessibility Initiative - checked

APG checkbox guidance documents checked, unchecked, and mixed states, accessible labels, grouped descriptions, and Space-key toggling.

Full agent/debug reference

Problem Context

  • Choices are not mutually exclusive.
  • Users need to review all available options and the selected set before submitting.

Selection Rules

  • Choose checkboxes for short independent multi-choice sets where every option can remain visible.
  • State any minimum, maximum, or select-all-that-apply rule before users submit.
  • Use radio groups instead when exactly one option is allowed.
  • Use multi-select when the option set is too long, searchable, or dynamic to show as a visible checklist.

Required States

  • Unchecked option state.
  • One or more checked option states.
  • Focused checkbox state.
  • Group validation state when required, limited, or left empty.

Interaction Contract

  • Each option toggles independently without unchecking other selected options.
  • The selected set remains visible in the list and in any summary text.
  • Validation explains required, minimum, or maximum selection rules without clearing checked values.

Implementation Checklist

  • Use native checkbox inputs where possible.
  • Group related choices under a clear fieldset legend or equivalent accessible name.
  • Add a short hint such as select all that apply when the multi-choice rule may be missed.
  • Preserve selections during validation errors.
  • Avoid hidden defaults, ambiguous negative labels, and custom toggles without checkbox semantics.

Common Generated-UI Mistakes

  • Using checkboxes for mutually exclusive choices.
  • Hiding selected values after choice.
  • Not explaining max-selection limits until submit.
  • Scattering related checkboxes without a shared question or legend.

Critique Questions

  • Are these choices truly independent, and should users see them all together?
  • Can the user tell how many options may be selected before they submit?
Accessibility
  • Use programmatic labels for every checkbox.
  • Group related checkboxes with a fieldset and legend or equivalent.
  • Associate group hints and errors through descriptions when available.
Keyboard Behavior
  • Tab moves between checkboxes.
  • Space toggles the focused checkbox without changing other checked options.
Variants
  • Stacked checkbox group
  • Checklist
  • Tile checkbox group
  • Checkboxes with conditional reveal

Verification

Source trail checked:

Saved items