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. Learn more about representing mixed values.
Checkboxes come in four different sizes: small, medium, large, and extra-large. The medium size is the default and most frequently used option. Use the other sizes sparingly; they should be used to create a hierarchy of importance within the page.
By default, checkboxes are not emphasized (gray). 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 emphasized (blue) version provides a visual prominence that is optimal for forms, settings, lists or grids of assets, and other situations where a checkbox need to be noticed.
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.
From the design point of view, each component has a number of options. These options and their names are platform agnostic, and each implementation should adapt these to fit into their framework.
Property | Values | Default value |
---|---|---|
label | text / nothing When the label is not defined, the checkbox appears as a standalone checkbox. | – |
is selected | yes / no | no |
is indeterminate | yes / no When a checkbox is indeterminate, it overrides the selection state. | no |
size | small / medium / large / extra-large | medium |
is emphasized | yes / no | no |
is disabled | yes / no | no |
is error | yes / no | no |
is read-only | yes / no | no |
A checkbox can be navigated using a keyboard. The keyboard focus state takes the checkbox’s visual hover state and adds a blue ring to the checkbox in focus.
When the label is too long for the horizontal space available, it wraps to form another line.
In Windows high contrast mode, checkboxes should be displayed using the high contrast theme-specified colors for buttons. By default, borders should be the same as the button text color and labels should use default text color. In hover and keyboard focus states, a border should display as the button border color. Selected checkbox fills should be the same as button border color. In the disabled state, border, and text color should display as the disabled color.
Emphasized checkboxes are optimal for forms, settings, etc. where the checkboxes need to be noticed, or to bring attention to selected items such as cards or table rows. Not emphasized checkboxes are optimal for application panels where all the visual components are monochrome in order to direct focus to the canvas.
Standalone checkboxes should be used in situations where the context is clear without an associated text label. An example of this would be when a checkbox is connected to other controls inside of a panel.
Checkboxes and radio buttons are not interchangeable. A set of checkboxes should be used to select as many options as desired (or none). A set of radio buttons should be used to select only a single option from a list of mutually exclusive options.
Checkboxes are best used for communicating selection (e.g., multiple table rows) while switches are best used for communicating activation (e.g., on/off states). Checkboxes, unlike switches, can have an error state.
Sets of checkboxes should always have a clear label that describes what the list of options represents and guides users what to do. This is important for accessibility, since a screen reader will read the label before each option.
When a checkbox represents multiple values that are not identical, the checkbox should appear in the indeterminate state. Any subsequent click or tap should select the checkbox, and update all values to be selected. Another click or tap after that should deselect the checkbox, and update all values to be not selected.
For RTL (right-to-left) languages, the layout of the checkbox is mirrored. The checkmark is placed on the right side of the text.
Key | Interaction |
---|---|
Space | Toggles the checkbox between selected and not selected. If the checkbox is partially selected initially, the checkbox becomes selected first (subsequent toggles alternate normally between selected and not selected). |
A theme is an intentional, systematic customization of Spectrum. It has unique visual attributes. For more information, view Theming.
Checkboxes in Spectrum for Adobe Express have indigo accents. They are slightly larger and more rounded compared to the default Spectrum checkboxes.
Date | Number | Notes |
---|---|---|
Feb 24, 2023 | 7.0.2 |
|
Sep 08, 2022 | 7.0.1 |
|
Apr 06, 2022 | 7.0.0 |
|
Feb 15, 2022 | 6.3.1 |
|
Jan 19, 2022 | 6.3.0 |
|
Apr 13, 2020 | 6.2.1 |
|
Feb 26, 2020 | 6.2.0 |
|
Aug 22, 2019 | 6.1.0 |
|
Jul 31, 2019 | 6.0.0 |
|
Apr 20, 2019 | 5.0.0 |
|
Includes all interactive states that are applicable (hover, down, focus, keyboard focus, disabled).
Works properly across all four color themes (lightest, light, dark, darkest).
Includes a desktop scale (UWP, macOS, web desktop) and a mobile scale (iOS, Android, web mobile).
Color is not used as the only visual means of conveying information (WCAG 2.0 1.4.1).
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).
UI language and information design considerations have been incorporated into component design.
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 XD file that shows multiple options, states, color themes, and platform scales.
Includes a downloadable XD file, generated by code using design tokens defined in Spectrum DNA, and shows multiple options, states, color themes, and platform scales.
Component is included in the Spectrum for Adobe XD plugin.