Check Boxes: Design Guidelines

Article
01/26/2007

A check box presents the user with a single yes or no decision, or a decision between two opposite choices.

Make clicking a check-box label have the same result as clicking its associated check box.
Use check boxes only when both states of a choice are opposites and unambiguous. Otherwise, use option buttons or some other form of single-selection control instead. For example, if the alternative to the Print to File option is understood by your users to be printing normally (using the printer), then you can use a check box; otherwise, list both choices with option buttons.
Group related check-box choices. A check box in a group follows the same guidelines as a single check box. The user may select any combination of check boxes in a group.
In a group, list check boxes in a logical order (such as most likely to be selected to least likely, simplest operation to most complex, least risk to most, and so on).
It’s recommended that you use no more than five check boxes in a group. Do not exceed seven. If you need to display more than five choices, consider using a different type of control, such as a multiple-selection list box or a scrolling list box that contains check boxes and their labels.
Stack check boxes vertically, not horizontally. Horizontal alignment leaves insufficient space for localization.
Exception: You may lay out check boxes horizontally if their labels do not exceed five characters and if you leave space for the text to expand 30 percent during localization.
If a check box is a superior or subordinate control, follow the Subordination guidelines.
Do not make check boxes at a peer level interoperate in any manner.
You may make a check box interoperate with a peer control, provided that control is not another check box. For example, you can use the state of a check box to filter the contents of a list, as shown in the following illustration.
Make controls that interoperate with a check box contiguous with the check box in the tab sequence.
Do not make controls on one surface subordinate to a check box on another surface without explanation. For example, if the user needs to select the Enable Logging check box on a property sheet in order to make a View Log button active on another dialog box, clearly explain this relationship in both locations.
When check boxes are subordinate to another control, their default state should be cleared.
For check-box functionality in a toolbar, use button support within the toolbar control.
Do not create custom states for a check box. These will not be accessibility-compliant. Only selected, cleared, and mixed-value states are permitted. If you need to represent more choices, consider using another type of control, such as a drop-down list box.
If you use a check box to display a property that has multiple values (for example, a text selection that is partly in bold style and partly in normal style), display the check box in its mixed-value appearance.
If the user clicks a check box that is in the mixed-value state, set the check box as follows:
- At the first click, set the check box to the checked state. When the state is applied, toggle the values of the selected items to being set.
- At the second click, set the check box to the cleared state. When the state is applied, toggle the values of the selected items to being not set.
- At the third click, set the check box back to the mixed-value state. When the state is applied, assign all items in the selection their original values.
Do not move focus from the check box when the user clicks it. This surprises and disorients the user. For example, do not close the surface as soon as a check box is selected.
Exception: If the check box has subordinate controls that become active when a check box is selected or cleared, you may move focus to the first of the subordinate controls.
If you’re embedding check boxes in a list box control, use the flat check box appearance, as shown.

Check Boxes: Design Guidelines

See Also

Concepts

Additional resources