Checkboxes.
Sometimes called multi-select. Checkboxes let learners pick more than one option from a list. If they can pick more than one, it's checkboxes — not radio buttons.
Multi-select questions and lists.
Each checkbox toggles independently. Selecting one doesn't deselect the others — that's the defining behaviour and the only reason to reach for checkboxes rather than radio buttons.
- "Select all that apply" questions.
- Filters where multiple criteria can be combined.
- Optional preferences or toggles in a settings list.
- Consent and agreement checkboxes — one per item.
Single-choice anything.
If the learner should only pick one answer — even if "none of them" is a valid response — you want radio buttons, not checkboxes.
- Questions with one correct answer (use radio buttons).
- Yes/no toggles for a single setting (use a toggle).
- Long lists of more than 7 items (use a multi-select dropdown or chips).
- Combining a "select all" with mutually exclusive options.
Try it.
A typical eLearning multi-select check-in. Tick any number of options. Each checkbox is independent — selecting one doesn't deselect the others. The count updates as you go.
Which of these have you done in the last fortnight?
Tick all that apply. There's no wrong answer.
We're showing a count of selections, not a "correct" state. Multi-select questions usually aren't right/wrong — they're a snapshot of what's true for the learner.
Get the visuals right.
Square, not circular
Checkboxes are square; radio buttons are circular. This is a hard convention. Reversing it confuses learners about which interaction they're in. If you've inherited a design with circular multi-selects, fix it — don't argue for consistency with the bad pattern.
Visible tick on selection
The selected state needs a clear tick (or cross) inside the box. A filled colour alone isn't enough — colour blindness and low contrast displays make colour-only states unreliable.
Large clickable row
The whole label and the checkbox should be one clickable target. A 14px checkbox in 200px of whitespace is technically clickable but feels broken. Wrap the input in a <label> and make the label clickable too.
Accessibility — semantics
Use native <input type="checkbox"> inside <label>, grouped inside a <fieldset> with a <legend>. Screen readers will announce the group, the question, and the checked state of each option. Custom-built checkboxes almost never get this right.
Accessibility — keyboard
Tab focuses each checkbox in turn. Space toggles. Unlike radio buttons, arrow keys do not navigate between checkboxes — each one is independent. Make sure your custom-styled boxes preserve this behaviour.
Indeterminate state
A third visual state — neither checked nor unchecked — is useful for "some sub-items selected" or "select all" controls when only some are picked. Most authoring tools support this natively. Use it where it earns its place; ignore it for simple lists.
How to use checkboxes well.
If only one answer fits, you don't need checkboxes.
This is the test. "Which of these is a renewable energy source?" — one right answer. Use radio buttons. "Which of these are renewable energy sources?" — multiple right answers. Use checkboxes. The plural form of the question is your tell.
Make it clear that multiple selections are expected.
The question wording has to signal multi-select. "Tick all that apply", "Select any that are true", or "Choose your three favourites" are all clearer than just listing options. Without that signal, learners assume single-choice and only tick one — even when the design says otherwise.
3 to 7 options. After that, switch patterns.
Two options is a single yes/no. Eight or more starts overwhelming the learner — and scrolling a checkbox list on a phone is painful. For long lists, use a search input or grouped categories. For very long lists, rethink the question.
Avoid "all of the above" and "none of the above" entirely.
"All of the above" doesn't work for checkboxes — the learner ticks all the individual items, which makes the meta-option redundant. "None of the above" is technically valid but rarely useful: if no options apply, learners should be able to submit nothing and move on. Design for that case instead.
Don't mix exclusive options into a multi-select.
A checkbox group with "Mornings", "Afternoons", "Evenings", and "I have no preference" is broken: the last option is exclusive. Learners either tick it alone (correct) or tick it along with others (logically inconsistent). Either split into two questions or use radio buttons with an "any of the above" option.
Confirm what was selected on submit.
If the question is consequential — feedback decisions, eligibility for a path, a learning plan — echo back what the learner picked before they move on. "You selected: A, C, D. Is this right?" prevents accidental submissions and gives the learner confidence their answer landed.
Order matters, even when items are independent.
Group related items. Lead with the most common answers if you know them. Alphabetical order is fine for filter lists; for survey questions, intentional order works better. Random order on each attempt is rarely useful for checkboxes — learners need consistent positions to scan a multi-answer list efficiently.
When you'd reach for checkboxes.
Risk identification in WHS
"Which of these are hazards in this image?" — multiple correct answers, no fixed order. Classic checkbox use case.
Pre-course self-assessment
"Which of these topics have you worked with before?" — a baseline check that adapts the rest of the course. No right or wrong answer.
Consent and acknowledgements
Multiple discrete agreements at the end of a compliance course — privacy policy, code of conduct, training acknowledgement. Each is its own decision.
Filters in a resource library
"Show me content tagged with: leadership / sales / for managers." Each filter is independent and combinable.
Want a course
built well?
We apply these principles on every course we build. Three-week delivery, transparent pricing, zero drama.