Data Entry
Checkboxes allow users to select multiple items from a list of individual items, or to mark one individual item as selected.
Checkboxes should always have a label. When the label is not defined, a checkbox becomes standalone. Standalone checkboxes are only used when their connection to other components is clear and they give sufficient context — for example, in application panels.
Checkboxes can be selected, not selected, or in an indeterminate state. They are in an indeterminate state when they represent both selected and not selected values.
By default, checkboxes are not emphasized. This version is optimal for when the checkbox is not the core part of an interface, such as in application panels, where all visual components are monochrome in order to direct focus to the content. The Primary, or emphasized, version provides a visual prominence that is optimal for forms, settings, lists or grids of assets, and other situations where a checkbox needs to be noticed.
The Bordered variant provides a higher level of visual prominence that is best for situations such as a questionnaire or survey where a checkbox group is the primary component on a page. These work particularly well on touch screen devices as the target area is more clearly visible.
A checkbox in a disabled state shows that a selection exists, but is not available in that circumstance. This can be used to maintain layout continuity and communicate that an action may become available later.
Checkboxes can be marked as having an error to show that a selection needs to be made in order to move forward, or that a selection that was made is invalid. For example, in a form that requires a user to acknowledge legal terms before proceeding, the checkbox would show an unchecked error to communicate that it needs to be selected.
Checkboxes have a read-only option for when they’re in the disabled state but still need their labels to be shown. This allows for content to be copied, but not interacted with or changed.
Checkboxes can be marked as optional, depending on the situation. Optional checkboxes are denoted with text added to the end of the label — “(optional)”.
A checkbox can be navigated using a keyboard. The keyboard focus state takes the checkbox’s visual hover state and adds a ring to the checkbox in focus, copying the color style of the variant.
When the label is too long for the horizontal space available, it wraps to form another line.
Checkbox items when checked can reveal additional, conditional content.
Description and implementation notes
<p> code example </p>Includes all interactive states that are applicable (hover, down, focus, keyboard disabled).
Works properly across all color schemes (light, dark).
Text has a contrast ratio of at least 4.5:1 for small text and at least 3:1 for large text (WCAG 2.0 1.4.3).
Visual information required to identify components and states (except inactive components) has a contrast ratio of at least 3:1 (WCAG 2.1 1.4.11).
Includes relevant options (variant, style, size, orientation, optional iconography, decorations, selection, error state, etc).
Includes guidelines for keyboard focus, layout(wrapping, truncation, overflow) animation, interactions etc.
Includes a list of dos and don'ts that highlight best practices and common mistakes.
Includes content standards or usage guidelines for how to write or format in-product content for the component.
Works properly across various locales and includes guidelines for bi-directionality (RTL).
Follows WCAG 2.0 standards for keyboard accessibility guidelines and includes a description of the keyboard interactions.
All design attributes (color, typography, layout, animation, etc.) are available as design tokens.
Includes a downloadable Figma file that shows multiple options, states, color themes, and platform scales.