Checkbox

Use checkboxes when offering multiple choices within a group or category.

Checkboxes are commonly used for multiple choice settings or actions that may a require a user’s approval or consideration before submission or saving.

Standalone checkboxes are often used to confirm or accept actions or terms. Unlike radio buttons, a checkbox allows the user to select and unselect their option before confirmation. It also provides friction to make the user consider their choice before submission. For this use case, a button is often paired with the checkbox to submit or confirm the user’s selection or action.

To feature multiple options within a category, select the checkbox group. In a checkbox group, a group label (fieldset/legend) is typically required. If there are more than five items in a group, consider using the select component.

Align checkboxes vertically when possible to eliminate confusion around labeling and which option the user is selecting. Horizontal alignment is only recommended for two options or less for this reason. Similarly, if using longer labels, and the text wraps, vertical is the preferred alignment.

These are the sizing and spacing specifications built into the component.

Checkboxes can be selected, unselected, or indeterminate by selecting the checkbox or its associated label.

All checkboxes require a clear, concise, and unique label
For checkbox variants without labels, such as those used within a table, a hidden label is still required for assistive technologies.
WCAG 2.1: 1.3.1 Info and Relationships, 2.4.6 Headings and Labels

Avoid default selections
Pre-selected choices are considered a deceptive practice for all users. Implement a default unselected state.

All keyboard interactions and ARIA labels must meet accessibility criteria
WAI-ARIA Checkbox Authoring Practices

Capitalization
Use title case for group labels and sentence case for all other labels.

Character length
Checkbox labels should be scannable, consistent, and concise. Standalone checkboxes (for example as part of terms and conditions) may have a sentence or more of text so that the user is informed about what they’re agreeing to. When checkboxes are used as a group of options, try to keep the labels short. While it’s technically feasible to create long labels, checkbox labels that wrap to a second line may provide a poor user experience.

Labels
The biggest usability issues for checkboxes come from labels that are vague, misleading, or describe options that are difficult for users to understand.
Use clear and concise labels so users can easily scan options. Make sure you present all choices, and that those choices don’t overlap. All checkbox labels should be consistent in length, tense, and meaning. For group labels, state the category of the grouping.
Do:

• Ages 1 to 10
• Ages 11 to 15
• Ages 16 to 20

Don’t:

• Ages 1 to 10
• Ages 10 to 16
• Ages 16 to 20
  
  

Organization
Make sure checkbox options are organized in a logical and meaningful way. Keep in mind, that when listing items alphabetically, the order will change when text is localized.

Punctuation
Avoid punctuating checkbox labels. An exception is if the label is a complete sentence (for example, in terms and conditions).

Specificity
Be explicit about the results of a user’s selection.

Terms and conditions
When a checkbox is asking users to agree to terms or service, use the first person and punctuate the sentence. In most cases, a link or an explanation of the terms and conditions must be available in the context of acceptance of those terms.
Example: I agree to the terms and conditions.

Tone
Use a positive tone, signaling affirmation, instead of negation to avoid confusing users. Use imperative verbs when writing labels.
Do: Receive email promotions
Don’t: No, I do not want to receive email promotions.

Ethics
Do not pre-select or have a default item selected for your users.