Checkboxes

On this page

Anatomy

States

Designer guidance

Developer guidance

Content editor guidance

Accessibility 

Support

Anatomy

Checkbox group

Standalone checkbox

States

Designer Guidance

When to use

Use the checkbox component when users need to:

• Select multiple options from a list.
• Select a single option that needs to be toggled on or off, such as agreeing to consent or agreement statements.

When not to use

Avoid using a text area component when:

• Only one of multiple options can be selected, use Radio buttons instead.

How to use 

• Grouping: Group related checkboxes together with a clear label or legend.
• Labels: Ensure each checkbox has a visible, descriptive label.
• Help text: Do not assume users understand that multiple selections are allowed - provide help text such as "Select all that apply" when helpful.
• Required checkbox groups: Clearly indicate required checkbox groups (e.g. “Select at least one option”).

Behaviours

• Error messages appear below the checkbox or checkbox group when validation fails. 
• Error messages must:
  • Be clear, concise and written in plain English.
  • Explain what went wrong and how to fix it.
• Avoid vague messages such as ‘An error occurred’. An error for a specific situation is more helpful.
• Do not apologise. It does not help the user resolve the problem.
• Frequency of errors should be tracked to help with testing and research.
• Focus state must be clearly visible.
• Disabled checkbox state:
  • Indicate that the checkbox exists, but is unavailable.
  • Must not accept checked state or be submitted.
  • Should display a "not-allowed" cursor on hover.
• Required fields must be clearly indicated using text (e.g “Required”) or an asterisk with supporting context.
  • Do not rely on colour alone to show required or error states.

Options

The checkbox group can include optional help text.

Use help text to:

• Provide clarification relevant to most users.
• Provide an example to help the user understand what the field is for.
• Explain section rules or constraints.

Help text should:

• Be no longer than a single short sentence.
• Not be used for long or complex instructions.

Developer Guidance

Best practices

• Use semantic HTML (<input type="checkbox">).
• Associate labels with inputs.
• Use <aria-describedby> for help text and error messages.
• Use <aria-required="true"> for required checkbox groups.
• Do not rely on placeholder text for instructions.
• Ensure keyboard operability and logical focus order.
• Apply visible focus styles.
• Include the checkbox label text in the touch target and maintain minimum target size (44×44px).

Content Editor Guidance

Best practices

• Use short, clear, descriptive labels.
• Use sentence case without punctuation.
• Provide help text separately if needed.
• Avoid jargon or ambiguous terms.
• Ensure error messages are actionable and specific.

Accessibility

Accessible checkboxes must:

• Always use a visible label.
• Provide additional instructions using <aria-describedby> when necessary.
• Required fields must be communicated to all users:
  • Visual: Clear text indicator (e.g “Required or asterisk”).
  • Programmatic: <aria-required="true">.
• Ensure sufficient colour contrast for text and borders.
• Be operable via keyboard and have visible focus indicators.

WCAG success criteria

• 1.3.1 Info and Relationships (Level A)
  Labels programmatically associated with inputs.
• 1.4.3 Contrast (Minimum) (Level AA):
  Text and borders must borders meet contrast requirements.
• 2.1.1 Keyboard (Level A):
  Fully operable via keyboard.
• 2.4.6 Headings and Labels (AA):
  Labels describe purpose clearly.
• 3.3.2 Labels or Instructions (A):
  Provide clear instructions for input and indicate required fields before submission.

Related components

Text area

Text input

Radio buttons