I recently encountered the following box on a major website's registration page. It contains at least two design mistakes. See if you can find them before reading further.

Mistake #1 is the primary focus of this article: The erroneous use of checkboxes where radio buttons should be. Because the two choices above are mutually exclusive, the page should present users with radio buttons, which restrict them to selecting exactly one option.

Mistake #2 is to present two questions in the first place, and then to put them in a big, verbose box. A single, shorter question would be far better here: "Yes, send me information about other featured products, solutions, services, and educational opportunities."

Ironically, with a single question, using a checkbox would have been correct because the user would be answering yes or no. The recommendation from user testing of e-commerce sites is to leave the checkbox blank by default, so users must actively click it to opt in for further messages.

When to Use What Widgets

Ever since the first edition of Inside Macintosh in 1984, the rule has been the same for when to use checkboxes versus radio buttons. All subsequent GUI standards and the official W3C Web standards have included the same definition of these two controls:

1. Radio buttons are used when there is a list of two or more options that are mutually exclusive and the user must select exactly one choice. In other words, clicking a non-selected radio button will deselect whatever other button was previously selected in the list.
2. Checkboxes are used when there are lists of options and the user may select any number of choices, including zero, one, or several. In other words, each checkbox is independent of all other checkboxes in the list, so checking one box doesn't uncheck the others.
3. A stand-alone checkbox is used for a single option that the user can turn on or off.

Sounds simple enough, right?

Yet I frequently encounter Web pages that use radio buttons and checkboxes wrong. Even after twenty years, it's worth stating these guidelines once again.

Additional Guidelines

4. Use standard visual representations. A checkbox should be a small square that has a checkmark or an X when selected. A radio button should be a small circle that has a solid circle inside it when selected.
5. Visually present groups of choices as groups, and clearly separate them from other groups on the same page. The boxed example above violates this guideline because the layout makes the two checkboxes appear to be addressing separate topics when they’re actually alternative options for a single topic.
   • Use subheads to break up a long list of checkboxes into logical groups. This makes the choices faster to scan and easier to understand. The risk is that users might view each subgroup as a separate set of options, but this is not necessarily fatal for checkboxes — each box is an independent choice anyway. A list of radio buttons, however, must always appear unified, so you cannot use subheads to break it up.
6. Lay out your lists vertically, with one choice per line. If you must use a horizontal layout with multiple options per line, make sure to space the buttons and labels so that it's abundantly clear which choice goes with which label. In the following list, for example, it's difficult to see the correct radio button to click for option four.
   One Two Three Four Five Six Seven
7. Use positive and active wording for checkbox labels, so that it's clear what will happen if the user turns on the checkbox. In other words, avoid negations such as "Don't send me more email," which would mean that the user would have to check the box in order for something not to happen.
   • Write checkbox labels so that users know both what will happen if they check a particular box, and what will happen if they leave it unchecked.
   • If you can't do this, it might be better to use two radio buttons — one for having the feature on, and one for having it off — and write clear labels for each of the two cases.
8. If possible, use radio buttons rather than drop-down menus. Radio buttons have lower cognitive load because they make all options permanently visible so that users can easily compare them. Radio buttons are also easier to operate for users who have difficulty making precise mouse movements. (Limited space might sometimes force you to violate this guideline, but do try to keep choices visible whenever possible.)
9. Always offer a default selection for radio button lists. By definition, radio buttons always have exactly one option selected, and you therefore shouldn't display them without a default selection. (Checkboxes, in contrast, often default to having none of the options selected.)
   • If users might need to refrain from making a selection, you should provide a radio button for this choice, such as one labeled "None." Offering users an explicit, neutral option to click is better than requiring the implicit act of not selecting from the list, especially because doing the latter violates the rule of always having exactly one option chosen.
10. Because radio buttons require exactly one choice, make sure that the options are both comprehensive and clearly distinct. In tests with older users, for example, people couldn't complete a form that required them to select their job because it didn't offer "retired" as an option. If it's impossible to be comprehensive, offer a button labeled "Other," supplemented by a type-in field.
11. Let users select an option by clicking on either the button/box itself or its label: a bigger target is faster to click according to Fitts's Law. In HTML forms, you can easily achieve this by coding each label with <label> elements, as I've done for the example with horizontal radio buttons above (to select that option, click on the word "Four"). In testing Web-based applications in Flash, we found that user errors are further reduced by generous click zones that extend a few pixels beyond the visibly clickable area. (This effect can be hard to achieve in HTML, though some CSS hacks might do the trick.)
12. Define accesskeys for frequently used checkboxes and radio buttons so users can quickly select their preferred options from the keyboard. This enhances accessibility for users with disabilities and also serves as an accelerator for experienced users. (In my example with horizontal radio button, hit ALT-5 to select option Five.)
    • If there were standards for accesskeys, I'd recommend that you follow them. Unfortunately, we don't have such standards as yet. Instead, define your own standard within your organization for any options that appear on multiple pages so that the same option always has the same accesskey on your website and intranet.
13. Use checkboxes and radio buttons only to change settings, not as action buttons that make something happen. Also, the changed settings should not take effect until the user clicks the command button (labeled "OK" for example, or "Proceed to XXX" where "XXX" is the next step in a process).
    • If the user clicks the Back button, any changes made to checkboxes or radio buttons on the page should be discarded and the original settings reinstated. The same guideline obviously holds if the user clicks a Cancel button (though navigational Web pages don't need a cancel option because the Back button serves the same purpose).
    • If the user first clicks Back and then Forward, then it's most appropriate to interpret this sequence as an Undo-Redo pair, meaning that the appearance of the controls should show the user's changes as if the user had never clicked Back . These changes should still not take effect on the backend until the user clicks "OK" or an equivalent command.

Why These Guidelines Matter

Am I just being picky when I insist on the correct use of checkboxes and radio buttons? No. There are good usability reasons to follow GUI standards and use the controls correctly.

Most important, following design standards enhances users' ability to predict what a control will do and how they'll operate it. When they see a list of checkboxes, users know that they can select multiple options. When they see a list of radio buttons, they know that they can only select one. (Of course, not every user knows this, but many do, especially since this has been a design standard since 1984.)

Because many people know how to operate standard GUI widgets, employing these design elements correctly enhances users' sense of mastery  over technology. Conversely, violating the standards makes the user interface feel brittle — as if anything can happen without warning. Say, for example, that you assume you can click on a radio button without any immediate impact, and can thus consider your choices after making a selection but before hitting "OK." In such a case, it's jarring when a website violates this standard and unexpectedly moves you to the next page once you enter a selection. Worse, it makes you fear what may happen as you work with forms elsewhere on the site.

The biggest usability problems for checkboxes and radio buttons come from labels that are vague, misleading, or describe options that are impossible for average users to understand. Contextual help can alleviate the latter problem, but it's still best to user test any important set of interaction controls. Luckily, checkboxes and radio buttons are easy to test using paper prototyping, so you don't need to implement anything to see if users understand the labels and can use the widgets correctly.

No professional interaction designer would make the mistake of using checkboxes when radio buttons are called for. The distinction between these two controls is one of the first things taught in any interaction design class. So here's a final reason to use the right widget: if you don't, you'll be taken for an amateur.

Share this article: Twitter | LinkedIn | Google+ | Email