TL;DR: Do people tend to design interfaces with checkboxes even if the behavior actually requires radio buttons, because people are more familiar with check marks?
This seems to be a case that pits web standards & usability vs. aesthetics & user experience, which is not a good place to be in.
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:
- 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.
- 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.
- 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.
That was written in 2004.
I’m usually in this situation when design decisions are not up to me, and I have very little room to debate those choices. I don’t really mind spending more time on it, but if you work as closely to the “ground floor” of HTML, CSS, JS and sweat these details, it gets to you a bit.
I know that people probably understand a check mark better than concentric circles to signify an active state. Maybe it’s more necessary to show that, instead of the difference between multiple selection vs. single selection.
Or maybe some designers find the distinction between checkboxes and radios arbitrary, or prefer checkboxes aesthetically.
Or what if users aren’t as clueless after all, and have been familiar with web form controls for long enough?
Whether I find the answers to those things or not, I have to choose between:
- Using radios in markup, then injecting CSS/JS to make them look like checkboxes; or
- Using checkboxes in markup, then injecting JavaScript to force radio behavior.
#1 is more desirable because the markup is faithful to the intent (a single active state). It’s even possible to forego JavaScript and go POSH if you drop support for IE8.
But the fact that you have to do extra instead of letting the browser do its thing and render an already available feature, or the fact that a designer prefers to erase the default appearance of browser interface elements rather than design around them, does make me wonder.
The control which designers know in the print medium, and often desire in the web medium, is simply a function of the limitation of the printed page. We should embrace the fact that the web doesn’t have the same constraints, and design for this flexibility. But first, we must “accept the ebb and flow of things.”
At what point does the design of an interface reach “control freak” or “brute force hacking” levels, or how does one tell if it’s still “zen” enough?
Whose opinion holds more weight? Safe answer would probably be UX, but only if there’s supporting data. In which case, poor browser makers and their radio buttons—why design them that way in the first place? Is the convention no longer relevant?
Somewhere out there, there's a team that knows HTML, but doesn't know the difference between a radio button and a checkbox. pic.twitter.com/VBwk8Jxekd
— Erik D. Kennedy (@erikdkennedy) May 24, 2017
Probably another reason people want to work on native mobile apps, perhaps.
