I'm currently reviewing the usability of an e-commerce website. When the user searches a product, filter options are provided to refine his search.

The following list of checkboxes is available:


download bmml source – Wireframes created with Balsamiq Mockups

The user can't select multiple choices which is pretty unusual for me. For instance, the user can't view all the products less expensive than $1000 at the same time.

I'm wondering if there is a convention which states that checkboxes necessarily mean 'zero or more choices', and radio-buttons mean 'one single choice'.

  • 7
    Radio buttons do only mean One Single Choice (unless nothing is chosen to start with). See this related question: ux.stackexchange.com/questions/13511/…
    – JonW
    Commented Feb 13, 2013 at 15:01
  • What do I do if I want to view all products with a price below USD 2500?
    – user
    Commented Feb 13, 2013 at 15:06
  • 2
    @MichaelKjörling in this example you should be able to select multiple ones. If you can't then they're not using checkboxes correctly so should be radio buttons if that's an intentional restriction - but it's debatable whether that is a sensible restriction to place on this choice, unless there is some back-end DB restriction on the type of query it links to.
    – JonW
    Commented Feb 13, 2013 at 15:08
  • 1
    I'm glad @Leo is reviewing usability on this site, because this is so wrong. This is the sort of thing that I would expect to see a comment for in the code that looks like this: //TODO: Fix query performance problem when multiple filter options selected. Limited to just one selection for now.
    – drawtheweb
    Commented Feb 13, 2013 at 18:25
  • 1
    It's probably a good idea to allow the user to enter a custom price range, too. Suppose I have a product of about $500 in mind. Then I have to select 0-499.99 and 500-999.99. That includes things which are more than twice as expensive, and it's very annoying.
    – Brendon
    Commented Feb 13, 2013 at 21:31

6 Answers 6


In the original GUI guidelines from the Lisa/Macintosh, Xerox Star, and Microsoft Windows, check boxes are, as the name implies, something you can mark (with a check-mark) if you wish to select or mark it - or clear if you wish to deselect it. Each checkbox choice is independent of each other, in terms of their activation.

Radio buttons, on the other hand, got their name from the buttons on your car radio or home radio/tuner. Just like you can only select one radio station to listen to at a time, you can only select one option from a list of radio buttons.

So, to answer your question - yes, according to all widely accepted guidelines and conventions, from their inception, checkboxes "mean 'zero or more choices' and radio-buttons mean 'one single choice'."

It is interesting that these have become so ingrained in user interfaces over the last 25+ years that the origins have been forgotten.

I don't think the original UI widget guidelines are available online, but you can find the current rendition for Windows check boxes here:

http://msdn.microsoft.com/en-us/library/windows/desktop/bb246460(v=vs.85).aspx http://msdn.microsoft.com/en-us/library/windows/desktop/bb226806(v=vs.85).aspx

and for radio buttons (which they've renamed to "option buttons") here:

http://msdn.microsoft.com/en-us/library/windows/desktop/bb246443(v=vs.85).aspx http://msdn.microsoft.com/en-us/library/windows/desktop/bb246423(v=vs.85).aspx

and here are the corresponding guidelines from Apple:


Scroll down the page to find the sections about Radio Buttons and Checkboxes

For a discussion by Jakob Nielsen on the subject, see this article: http://www.nngroup.com/articles/checkboxes-vs-radio-buttons/

Here is his salient point - read his full article for amplification and examples:

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.

  • 1
    Point of note: The exactly one choice for radio buttons also implies that having no selection at all is an abuse of radio buttons. There should always be an option selected.
    – André
    Commented Feb 14, 2013 at 12:45
  • 1
    @André no selection in a radio button should only be used for an "unfilled" state to prevent people leaving it in a "default" state. I find that an acceptable use of it in some forms
    – Ben Brocka
    Commented Feb 14, 2013 at 13:53
  • @Andre - Absolutely correct - Jakob also says so in his article (bullet 9): "By definition, radio buttons always have exactly one option selected, and you therefore shouldn't display them without a default selection. ... 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."
    – yosh m
    Commented Feb 14, 2013 at 13:54
  • @BenBrocka - see my comment to Andre - and read Jakob's article and the guidelines. Not adhering to this standard creates serious problems: for example, if a user accidentally selects a radio button, there is no way to return to the "unfilled state".
    – yosh m
    Commented Feb 14, 2013 at 13:57
  • @yoshm that's what I mean...the blank state should be used as a "you have to select something to continue" state, not as an actual input state. The empty state should not mean anything other than "no input yet" which would be a validation cue where input is required. Therefore there's no problem with "accidental", they have to enter something that's not empty anyway.
    – Ben Brocka
    Commented Feb 14, 2013 at 14:28

Yes, there is a convention:

checkboxes = option for multiple choices

radio-buttons = only one single choice among the options

  • 2
    Do you have any citations / evidence for this convention? Without it this is just a subjective statement.
    – JonW
    Commented Feb 13, 2013 at 15:08
  • 6
    @JonW: these conventions have been in place pretty much since the invention of the checkbutton and radiobutton. This distinction is precisely why there are two different types of buttons. Commented Feb 13, 2013 at 18:18
  • 4
    @JonW I think it's dangerous to demand that everything a UX person says need evidence documented. I understand the want for that here on SE, but in general, it'd a bad idea to insist that UX teams back up every single statement with citations. Something are 'just the way the are'. ;)
    – DA01
    Commented Feb 13, 2013 at 18:48
  • 2
    all that said, the simplest evidence is to create an HTML page with checkboxes and radio buttons. You sill see the default behavior in action.
    – DA01
    Commented Feb 13, 2013 at 18:49
  • 3
    If everyone knew this convention then this question wouldn't have been asked. It was asked because the OP is asking for knowledge about it, presumably because they want to give some informed advice back to the owner of the website that implemented this feature. OP can't just tell them that "its a convention but you'll have to take my word for it".
    – JonW
    Commented Feb 13, 2013 at 23:00

The behavior of checkboxes learned by users is to be able to choose multiple options.

In your case, it may be a relic of some former functionality, e.g. a form with some strange dependencies.

  • 1
    As an example of 'strange dependencies' that can lead to this sort of customer requirement area history of paper forms and decision makers with low technical literacy. "It has to be exactly the same as out pen and paper version it's replacing" and paper forms do traditionally use check boxes for both single and multiple select cases. Commented Feb 13, 2013 at 20:02

Not only is this a convention, but the expected behavior is explicitly called out in the HTML 4.01 spec (and I wouldn't be surprised if it was in pretty much every other version, as well):

Several checkboxes in a form may share the same control name. Thus, for example, checkboxes allow users to select several values for the same property.


Radio buttons are like checkboxes except that when several share the same control name, they are mutually exclusive: when one is switched "on", all others with the same name are switched "off".

To reverse this is purposely avoiding the standard behavior, making the website more confusing for users, and actually making the development harder. I also don't see how you could make this work for users with JavaScript disabled.


Traditionally, checkboxes have been used to indicate simple on/off choices. Occasionally, they are used to indicate on/partially-on/off or on/off/indeterminate state (the technical term for that being tristate checkboxes), but that's unusual and I do believe a lot of users get tripped up by that. (For a specific example of the latter, try the folder properties dialog in Windows Explorer when some files have the read-only attribute set and some do not.) For example, the "read-only" and "archive" file attributes are not interrelated, and can be toggled independently of each other. Doing it with any mutually-exclusive control would require four controls instead of two: off/off, off/on, on/off, on/on. It gets even worse if you consider the "some of the selection are 'on' and some are 'off'" state: it balloons to nine (3^2) possibilities. Add a third and you have 27 (3^3) controls to keep track of! MS-DOS used four file attributes: archive, read-only, system and hidden. With "some on and some off", that adds up to 81 possible choices (even without, it's still 16 different combinations to keep track of).

Radio buttons, on the other hand, indicate that only a single choice can be made. They also usually indicate that a choice must be made, either by accepting some default value or by making an explicit choice.

On the web, even with few choices, comboboxes or selection lists of some kind that display only the currently selected choice (until the control is activated) seem to be common. I'm not sure what the actual usability aspects are, there, myself, but radio buttons can certainly be made less readable. For any non-trivial number of choices, there are certainly upsides to a combobox approach from a UI design point of view.

Personally, when I see radio buttons I know that only a single choice can be made. If I see checkboxes, I generally expect that more than one choice is possible -- and when the UI starts to actively work against the user's expectations, it causes frustration and acute forehead contact with wooden or other skin-covered surfaces.

As for references, I'm not sure how much it counts but even Wikipedia's introductory sentence on the subject says that "a checkbox (check box, tickbox, or tick box) is a graphical user interface element (widget) that permits the user to make multiple selections from a number of options (contrary to a radio button where only one choice is possible) or to have the user answer yes (checked) or no (not checked) on a simple yes/no question.".


Back to Leo's original question, I guess that he has inherited a non-designed UI where a not-quite-expert programmer lumped together a bunch of checkboxes without further analysis, nearly at 3:00am.
And that his goal was to provide the user a means to select price ranges in a smart way.
But that by allowing the users to check any button they got strange price-ranges, not a single segment but several, and that it was either difficult to program the query, or non-performant, so they tried to add restrictions in order to force a single price range.

The solution is to replace the checkboxes group by any other means to select a price range.
Like for example two radio button columns labeled like from and to, or a single one and fix the lower bound as 0$, or a range slider.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.