Entirely too many Web designers misuse check boxes and radio buttons. Builder.com columnist Michael Meadhra shares his thoughts on basic guidelines for working with form controls.
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 questions.
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 efficiently.
- 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 allowed.
- 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 vertically. 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.