Checkbox

A checkbox is an input control that allows for single or multi select.

Example

See the Pen Checkboxes by SHC-FED (@SHC-FED) on CodePen.0

Design Specs

Desktop/Tablet/Mobile

Check box spec

  1. Unchecked check box icons are 18px (1.125em) and #AAAAAA
  2. Label text is Open Sans Regular in #001733
    • For Desktop, the font size is 15px
    • For Mobile, the font size is 14px
  3. Checked check boxes 18px (1.125em) and #005ccc
  4. Padding between a list of check boxes is 30px. Padding between the right edge of the check box and the text is 10px
Not Shown:
  • Checkbox icons are from the Enterprise Font Icon Library
  • Field Labels are Open Sans Semibold in #001733
    • For Desktop, the font size is 15px
    • For Mobile, the font size is 14px
  • On rollover the radio buttons and label turns #005ccc and the label gets underlined


Note: Design specs are for reference only. Developers should use classes from Global Enterprise Framework where possible. See the - "Example" section on this page.

Production Examples

  • Sears
  • Kmart

Desktop/Tablet/Mobile

An example of a checkbox on mobile on a form.

An example of checkboxes on mobile in the search filter.

Checkboxes as seen on PLP.

Checkboxes as seen in Checkout.

Desktop/Tablet/Mobile

An example of checkboxes on the Kmart mobile site.

Checkboxes in checkout.

When Do I Use This?

Checkboxes should be used when users need to select 0, 1, or several from multiple available selections, or when they have a simple yes/no or true/false type of selection to make.

Usage Guidelines

1. Use a single checkbox for Yes / No scenarios

Use a single checkbox when users need to answer a question with a true/false style choice (e.g. opting into email). Don't use more than one checkbox or radio buttons for these type of questions.

Use single checkboxes when the answer is a yes or no.

Don't use two checkboxes for yes / no answers or radio buttons.

2. Use for multiple Selections

Use a group of checkboxes when users may need to make more than one selection and the options are not mutually exclusive. When you need a user to make mutually exclusive selections use a radio button or dropdown list .

Use group of checkboxes to allow users to make one or more selections.

Don't use radio buttons when a user may want to make more than one selection.

Use a group of radio buttons to allow users to make one mutually exclusive selection.

Don't use checkboxes when you want users to make only one selection. Also, a checkbox implies something is optional, but this use context is for items that are required.

3. Use for Selection Only

Checkboxes shouldn't be used to perform commands or to open other windows / modals.

Use checkboxes to allow users to make selections.

Don't make checkboxes perform commands or open other windows / modals.

4. Clear Copy

When using a checkbox to opt-in to a service or for other singular selections, make your copy clear and avoid use of negatives. (See PDP study below)

Use clear copy when giving users a yes or no option, especially when it's for opt-in usage.

Default selection shown. The presence of the "not" combined w/ checkbox creates a double negative that is hard to understand.

5. Default State

Checkboxes should be unchecked by default. (See research link "State of the Experience" below)

Leave checkboxes unchecked by default.

Don't precheck checkboxes for users. In this example, we don't know how a user intends to use a new address. It is better to let the user explicitly make the selection.

6. Click and Tap Affordance

Let users select an option by clicking on either the checkbox itself or its label

Make both the label and the checkbox clickable for best usability.

Don't let the checkbox be the only part clickable to avoid poor usability.

7. Capitalization

Labels should generally follow capitalization rules for its content. (LINK to copy guidelines) All lowercase and all uppercase are not allowed

Both labels adhere to guidelines for their content

The first label is a sentence and should not be Title Case. The second label "Master Protection Agreement" is a proper name and should be Title Case.

ADA Compliance

The size and touch area of form checkboxes is based on considerations for users with visual and/or motion based limitations. A larger touch area ensures all users, regardless of ability, are able to make their proper and intended selection.

Checkboxes must be grouped properly for assistive technology such as screen readers to identify them correctly. Checkboxes without label tags are inaccessible to screen readers. On their own, checkbox input labels do not provide enough context to allow a blind user to easily respond to the questions.

In terms of code considerations to ensure checkboxes are accessible, the WebAIM guidelines say: “The element is used to associate a text label to a form control. This allows a screen reader to read the associated label text when the user navigates to the form control. Groupings of form controls, typically groups of related checkboxes and radio buttons, sometimes require a higher level description (such as "Shipping Method" for a group of shipping option radio buttons). This descriptive text can be associated to the group of form controls using fieldset and legend. The fieldset identifies the entire grouping and legend identifies the grouping's descriptive text. Using fieldset and legend ensures that the text description is read to screen reader users when the grouping is navigated to." Source: Web AIM Forms


Useful Links:

Rationale

Checkboxes rely on a user's model for checkboxes on paper.

SHC Design Rationale:
To maintain a visual balance cohesion with the text that corresponds to a checkbox, the size of the icon is set to 18px. A checkbox touch target area and padding takes into consideration touch friendly heights and imprecise clicking by a user to allow for ease of use. The selected color is blue to match the site-wide "selected state" standard. The radio and checkbox styles use a stand-in element to replace the default browser element; the goal being a more modern, branded look.

Research

PDP "Questions & Answers" module

Make sure text is clear when giving users a checkbox choice. see p14

view full study

State of the Experience 2014

Mobile "Installation > required parts" - p51 This is an example of checkboxes being used poorly. A checkbox implies something is optional, but the use context is for items that are required. "Required parts is auto selected and users have the choice to un- select parts. Users are not aware if required parts is un-selected, installation crew will not install without the required parts." This example violates best practice of unchecked by default - if followed, perhaps the copy and interaction would have better accounted for error prevention. Also, the user has 2 different hose options, perhaps radio buttons are a better solution.

view full study

Post a New Comment

Your feedback will help us improve this page. If you have a comment about the content of this page, use the form below, and the Patterns Team will get back to you within a business day.

For general questions or assistance, email the Patterns Team directly.