My inspiration for this week’s
column comes from reading yet another one of Jakob
Nielsen’s Alertbox articles
. In this case, the topic is the proper (and
improper) use of check boxes and radio buttons on Web forms.

Although I frequently differ with
Nielsen’s conclusions, I think he’s right on target. Entirely too many Web
designers misuse check boxes and radio buttons. Sometimes the error forces
visitors to work through overly verbose copy with multiple options when a
clear, simple question would work better. Other times, the problem is using
check boxes in place of radio buttons, or vice versa. His article gives a good
example of the first error and includes some guidelines for working with check
boxes and radio buttons. I’ll add my voice to the general call for better use
of form controls and elaborate on a few of Nielsen’s usage suggestions.

Check boxes vs. radio buttons

Every computer user is familiar with
check boxes and radio buttons; they’re ubiquitous, appearing in dialog boxes
and other onscreen forms in nearly every program and operating system, as well
as in Web forms.

Perhaps it’s this familiarity that
contributes to the confusion some Web builders experience when it comes to the
proper use of check boxes, radio buttons, and other form controls. Most of us
tend to pay scant attention to the definition of something when we already
intuitively understand how it works. However, designing a form requires a
deeper understanding of the form’s components than does merely using the form.
The choice between using a check box or a radio button is usually obvious, but
when the choice isn’t as clear, it’s important to appreciate the subtle differences
in the controls.

Here are the standard definitions
for form controls:

  • Radio buttons are for lists of two or more mutually exclusive
    items. In other words, you can choose only one of several options—like a
    multiple-choice question.
  • Check boxes offer a binary choice—turning the option on or off—like
    a true/false question.
    • Groups of check boxes allow the visitor to choose any
      number of items from the list.
    • Single check boxes are for stand-alone, yes/no style

These definitions are reasonably
clear, but common mistakes continue to appear on Web sites. Consider these
examples culled from some recent surfing:

  • A question followed by two
    radio buttons labeled Yes and No. That offers two mutually exclusive
    choices, but a single check box would do the same thing much more
  • A list of several check
    boxes, preceded by instructions to check only one item. If only one
    selection is allowed, use radio buttons instead of check boxes.
  • A list of check boxes, with
    instructions to check all that apply. The instruction is redundant since
    the ability to check multiple options is implicit in the use of check
    boxes instead of radio buttons. Apparently, the Web builder felt that this
    instruction was necessary to clarify that the list is an example of the
    normal use of check boxes. This is an indication of the confusion caused
    by the widespread misuse of check boxes where only one selection is
  • Two separate questions,
    related and contradictory, each with its own stand-alone check box.
    Related choices should be grouped together with radio buttons for
    responses if the choices are mutually exclusive. Better yet, combine the
    questions into one choice with a single check box.

About additional guidelines

Nielsen’s Alertbox article goes on
to present 13 guidelines for using radio buttons and check boxes. The
guidelines are very good, and I encourage all Web builders to read them. I won’t rehash all 13 guidelines,
but I will comment on a couple of them:

Lay out your lists
He recommends vertical lists with one item per line because it
can be hard to tell which radio button goes with which label in a
horizontal list. However, horizontal lists can be a much more efficient
and attractive way to arrange several short options. Therefore, I think a
better guideline would be: Provide ample white space or other
separators between items in a horizontal list.

If possible, use radio
buttons rather than drop-down menus.
His argument is that radio buttons
keep all the options visible while drop-down lists hide all the options
except the current selection. Although that’s true, I don’t think it’s
always necessary (or even desirable) to keep all the options visible. On
the contrary, I tend to prefer drop-down lists in many cases because
they’re more space efficient and contribute to a clean, uncluttered page
design, where it’s easier to review the final selections before submitting
the form. As a result, I suggest replacing this guideline with: Use
radio buttons rather than drop-down menus when it’s important for all the
options to remain visible.

A list of guidelines for drop-down lists
should include a corollary to this rule, making the list preferable when
space efficiency is important. The list guidelines should also include an
admonition to make sure that the labels and instructions adequately
describe the hidden contents of a drop-down list.

My only major quibble with Nielsen’s
article is that he presents his guidelines as rules for all Web pages to follow
and continues his crusade for usability by adherence to a standard formula. In
contrast, I view the guidelines as being somewhat less restrictive rules of
thumb, more as standard practices that a good Web designer should follow unless there is a good reason not to. As
a designer, I know that good design sometimes means breaking rules, and I don’t
think there’s anything wrong with that when you do it in a way that doesn’t
confuse visitors.