Take the 2-minute tour ×
User Experience Stack Exchange is a question and answer site for user experience researchers and experts. It's 100% free, no registration required.

Previous title: Default behavior of HTML “radio” inputs: Did they get it wrong?


In HTML, there are currently two types of "checkbox" style controls:

  • Checkbox: Allows toggling on/off, multiple values can be selected
  • Radio: Only one value in a group may be selected, does not allow toggling off individual inputs

If anything is unclear, see demo: http://jsfiddle.net/GYU8n/

My beef is with radios, and the inability to "uncheck" them (which is the default behavior in all browsers as far as I know). We just had an issue with one of our clients insisting that we need to get rid of the "Not Applicable" radio option on a form, but the field is not required.

Here's the problem: If someone selects a radio option, perhaps by misclick, there's no way out unless a "blank" option is provided (wording irrelevant). Very much like a dropdown box that does not have a blank option, but the difference is that a dropdown box doesn't take up more room in the UI whether it has 2 options or 20. Having the selectable values already present on the screen, without the extra click that the dropdown needs, is great - so we use radios all the time.

I cannot comprehend why the radio type inputs cannot be toggled off by clicking the input, and why this behavior is the default. Clicking a different option is the only way to deselect the current one, but it's very likely that none of the options are required or applicable, so once a value is selected - a selection is "locked in", regardless of which one it is.

My question:

Surely this behavior is deliberate and took a room full of experts to agree upon, but what could those reasons possibly be?

I'm thinking of going against the grain and writing some javascript to change this behavior, by default, for all future applications that I write. Is there any reason why I shouldn't?

Extra: Do non-techie users even have an expectation of how radios work? Is it likely that people are trying to un-select radio options by clicking them again, expecting a toggle, and getting frustrated?


Example: Look at this mockup: http://jsfiddle.net/f4vXj/1/ How could this be changed to appear the same way (all options visible, using checkbox style controls), and not require an "empty" radio, that itself will require a label like "n/a" or "I don't want to fill in this field". If someone mis-clicks an option, they're locked in to selecting one of the options.

share|improve this question
3  
It's the default behaviour in desktop applications too. Once you have selected one option (all of them can start deselected) you can't return to that state. –  ChrisF Nov 3 '11 at 21:52
2  
jsfiddle.net/f4vXj/2 from stackoverflow.com/questions/2117538/… I don't recommend this though, I've never heard of anyone try to "uncheck" a radio button. But if that's what your client wants, then give it to them. They will be the only ones that knows how it works though. –  Matt Nov 4 '11 at 7:13
1  
@Jon: You can unpush the pause button on 80's tape players, but the thing is we're talking about the web - an entirely different medium, so I don't see it as relevant. –  Wesley Murch Nov 4 '11 at 15:05
5  
@Jon: Your suggestion to use checkboxes but restrict to one selection... doesn't that break expected behavior for checkboxes? I know it would trip me up. Why would you hack checkbox to save radio? If no one expects clicking a radio to deselect it, and won't generally try to re-click it, then what expectation is actually being broken? All I can see is benefit. –  Wesley Murch Nov 4 '11 at 15:27
4  
@WesleyMurch: In the case of UX, "because it's always been that way" is a valid answer. All else being equal, change is bad for UX. I do prefer checkboxes over radio buttons for "select 0 or 1 choice" because a confused user won't get stuck. Compare, "I have no idea how to deselect the radio buttons" to, "I have no idea how to select more than one checkbox." The latter is preferable; the user is trying to do something illegal. That being said, I agree with the majority that just adding another option is preferable. –  Brian Aug 13 '12 at 16:47

15 Answers 15

up vote 82 down vote accepted

You're not supposed to leave radio buttons blank. They're allowed to be blank so you can avoid setting defaults as mentioned in the question about setting a default gender. You can't not pick a gender, it's a required field, though you can leave a "prefer not to say" etc. option; this is different than the user never touching the radio button, however. If the field is required, not setting a default allows extremely useful behavior; You force the user to fill in the field and you don't assume a default.

Say it's an extremely important yes/no question; the user is legally responsible for this yes/no question. You can't pick a default setting for the user in this case! But still, this option can't be left blank, they have to commit to one or the other. How is this helpful? You catch this in validation (preferably in page). This lets you make sure the user has filled in the field, rather than assuming the default, which can be very important.

As for your extra question: Anyone that's used a web form (or many OS forms) is familiar with how radio buttons work since they're so common. The first time they see a radio button they might click it again to try and untick it, but they'll quickly learn. And more importantly, radio buttons function like many physical buttons in real life — originally named after buttons on radios that shared the same functionality.

You press in a button, it goes click, and it stays depressed in a state where the user can no longer press it again. Other buttons on the same control press out other buttons. Old cassette tape players used these; pressing fast-forward or play popped out the "Stop" button because both functions can't happen at the same time.

Users that have used buttons know you can't "unpush" a button. The difference with radio buttons is that some buttons push out other buttons.

share|improve this answer
1  
See the last paragraph I just added; their behavior emulates functionality found in physical controls. Your car probably has a bunch of radio buttons and I doubt you try to "unpush" them –  Ben Brocka Nov 3 '11 at 20:25
3  
Well, you can usually deselect those real-life radio buttons by pushing them in halfway, but that's besides the point and probably a defect. The wikipedia article outlines the way radios work, but does little to validate the behavior or explain its reasoning. Why shouldn't a user be able to "unpush" a radio? It's the only way to force single-choice besides a dropdown. –  Wesley Murch Nov 3 '11 at 20:29
2  
@Wesley: short term it may seem like a win. Longer term it just adds confusion as users will unlearn the meaning of radio buttons - they won't check for unselected radio buttons in forms for example, and you as well need to find new alternatives to convey 'one option required' - and need to explain why some radio buttons can be unchecked and others can't. Just don't do it, it harms more than it creates benefit. –  Inca Nov 4 '11 at 16:06
1  
@Inca: That's maybe the most compelling answer I've heard so far. –  Wesley Murch Nov 4 '11 at 16:31
2  
It is always good for user experience if user can undo his last action, which he can't if there was no default option selected. Behaviour of web radio buttons is just inherently flawed. People have got used to it, I guess but place a young child in front of set of web radio buttons to play with it and I bet it is going to try to unselect it at some point. Regrettably I can't make this an answer to the original question. –  clime Nov 16 '13 at 16:56

Answer to your main question: This is legacy behavior left over from the desktop. This is how desktop applications did it for decades before the web came along. When form elements appeared in HTML, they just copied the behavior from the desktop. The original designers of the radio button probably couldn't have imagined how this control would be used over time and didn't anticipate this need.

What you're asking for is not uncommon: the standard solution is to have a choice which is basically "no choice".

Extra: I do think that if you hack radio buttons you will find lots of people will never try to "un click" a radio button. I wouldn't do this.

Extra credit: However, I have seen one other hack you might like: use checkboxes instead, but only allow the user to pick one checkbox. This is a control that users are familiar with unchecking and they often will get over the "huh I can only check one at a time" confusion.

share|improve this answer
1  
Why hack checkboxes and not radios though? "The standard solution is to have a choice which is basically "no choice" - That's exactly what I am trying to avoid (also the client's request). For dropdowns it's OK, because it takes the same amount of room and doesn't need a label, whereas an "empty" radio does need one (just a radio with no label makes no sense and may go unnoticed, but a dropdown with a blank slot is pretty normal). So all-in-all it's more clutter. –  Wesley Murch Nov 3 '11 at 20:16
4  
I think the problem with hacking radios is that most people who already understand them won't think to try unchecking them. To Hagan's point, with checkboxes they will at least know to try that, even if you've thrown them off a little be enforcing that only one may be selected... –  peteorpeter Nov 3 '11 at 20:32
    
From a technical perspective, I'd rather use radios and fallback to radio behavior in case of a problem with the hack, to avoid multiple values being posted when only one is expected. So, what would you do if you were desperate to uncheck a radio? I would definitely try clicking it again, even if I know it won't work (while hoping it will). –  Wesley Murch Nov 3 '11 at 21:17
    
Not trying to be difficult, but wouldn't you rather just have a "no choice" option than cause a user to be "desperate" and try unusual behavior? Maybe the client would understand the drawbacks better if you cast the problem in this light? Re: the technical side, if your already hacking the controls, why not keep radios under the hood, but present the controls as checkboxes? –  peteorpeter Nov 4 '11 at 13:11
6  
No, no, please don't make checkboxes work like radio buttons! –  Patrick McElhaney Nov 4 '11 at 13:51

As other have said, this is perfectly normal and expected behaviour.

I'm thinking of going against the grain and writing some javascript to change this behavior, by default, for all future applications that I write.

Really bad idea. You would be making buttons that most people understand work in a different way. If you need on/off functionality, use checkboxes, but changing the functionality of an existing type of control is going to cause you huge problems.

share|improve this answer
    
Checkboxes are not an option because they can't be used to force a single selection from many (at least natively). I understand this breaks some users' expected behavior, but I don't see why this particular idea is a bad one. Can you offer an example? How could this possibly trip someone up? Accidental double click? That's all I can think of. –  Wesley Murch Nov 3 '11 at 22:27
3  
Exactly. The worst solution to a problem is to invent a control which looks familiar* to the user but acts differently. Bruce Tognazzini has more on this in "Tog on Interface" (worth a read anyway.) –  jensgram Nov 4 '11 at 7:20
1  
@wesley: "they can't be used to force a single selection from many" but that's exactly what radio buttons are for. If you want them to be able to not 'select' one of the radios, what you do is add another option 'no thanks', or 'not applicable' or the like. –  DA01 Nov 4 '11 at 15:00
    
@DA01: Yep, that's what I usually do, and why I use radios for forcing single choice. Using native checkboxes for that is not the right choice. It just strikes me as odd that a radio group can start off all unchecked, but going back to that state is impossible. –  Wesley Murch Nov 4 '11 at 15:12
    
@wesley I actually agree with you on that point. I, personally, don't feel that radio buttons should ever be completely unselected by default. –  DA01 Nov 4 '11 at 15:21

Radio buttons are meant to be used in cases where you definitely need the user to select something, it is a way to force users to give you an input.

From what I've seen around the web, there are no cases of radio button hacks whereas there are examples of checkbox hacks where you will note that the system does not allow you to select multiple checks. From a user perspective, it would be easier to understand that only one option can be selected from a checkbox vs leaving a radio selection blank.

share|improve this answer

According to the W3C, the default behavior of radio elements with no default control set to checked is undefined.

http://www.w3.org/TR/html401/interact/forms.html#radio

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". The INPUT element is used to create a radio button control. If no radio button in a set sharing the same control name is initially "on", user agent behavior for choosing which control is initially "on" is undefined. Note. Since existing implementations handle this case differently, the current specification differs from RFC 1866 ([RFC1866] section 8.1.2.4), which states:

At all times, exactly one of the radio buttons in a set is checked. If none of the elements of a set of radio buttons specifies `CHECKED', then the user agent must check the first radio button of the set initially.

Since user agent behavior differs, authors should ensure that in each set of radio buttons that one is initially "on".

While browsers currently agree on allowing radio controls to be unchecked by default, this is not considered to be the expected behavior.

share|improve this answer

The answer to this is really to try understanding why they are called "radio buttons".

In ancient times - well, before the world went digital at least - radios used to have a couple of preset channel buttons. Those were mechanical, and when you pressed one button, the previously pressed button would "pop up" and become deselected. The same arrangement were used on amplifiers as well, selecting the source device. In this application, it's even more obvious that having none selected is not really an option.

This behaviour carried over to the skeuomorphism of the software UI radio button.

I won't say if it's correct or not, just that the origin of the behaviour is hidden in its name.

share|improve this answer
1  
But you COULD half-way push in the radio button to de-select the previously selected one! Why does everyone who quotes the history of the radio button forget this? –  Graham Apr 24 '13 at 20:38
    
It's more of a mechanical bug than an actual feature. Using the original radio case, deselecting any channel like that would usually leave you with just static, so using the power button/switch was a more valid use case. Also, when you started turning the frequency knob to select a frequency manually, the selected preset channel wouldn't pop out - which would be a proper behaviour. –  CB Du Rietz Apr 24 '13 at 23:09

Radio button = mandatory single value field.

One has to be selected for submission. If you want a None option. make the first Radio 'None'.

Otherwise use checkboxes - which allow multi select

share|improve this answer

The real solution is to either use a combo/select with the none option plus all the other options or radios for all the options with the none option selected by default.

From Wikipedia:

A radio button or option button is a type of graphical user interface element that allows the user to choose only one of a predefined set of options.

So you must provide an option for NONE if you plan to offer an option for none otherwise use the combo.

share|improve this answer
    
That could be a solution although it could increase fill-out time for the form by a lot. Users cannot see all the options and when you have lots of these combo/select boxes it poses a readability/scanability problem. –  Roberto De Vivo Aug 14 '12 at 9:22

A purely UX solution might be to simply append the ubiquitous red asterisk (*) to the question, which most everyone understands to mean "required."

The main problem with the behavior of radio buttons seems to be that, on questions designed like the one shown at the jsfiddle link, the user doesn't know what to do if their answer is "none of the above." The first thought is to click a button again expecting it to be a toggle, which is a quite common capability in physical buttons.

Adding the "required" marker confirms that the user must pick one of the options (and probably leave a nasty comment, if possible, for not providing a "none of the above" type option.)

share|improve this answer

This may be subjective, but I really felt like this needed to be said. I think the standard way radio buttons work already are fantastic.

I'll explain why.

Let's think about the user for a second. What if the radio button is already selected on what the User needs in order to fill out their form? Would that not provide a wonderful User Experience?

Let's think about a possible user interaction scenario:

Providing one less click/touch, that the user may not have to deal with, will most definitely provide a better User Experience. Now granted,the overall user experience may have a lower chance of being that perfect " I don't have to change my selection " experience, but it is possible. Especially if setup that way.

Radio buttons already have an option selected when you first come into the page. Now again this is very subjective, but if the User Research is done well, it might just be possible to achieve that no touch/click goal with the radio button if the default is the majority of what people will select.

Pretty awesome stuff if you ask me. I agree with the others in sticking to the standard and familiar use of Radio buttons.

In the end, I think it really comes down to what your goals are for the project you're working on.

Here is a very simple example of what I mean by an option is already selected:

http://www.echoecho.com/htmlforms10.htm

share|improve this answer

Instead of downvoting others, I'd rather add my tiny voice to the opposite side.

Both behaviors are needed for performing different tasks. Unfortunately, I came across this question when needing to do the opposite of the default behavior. Now, if you ever think about accessibility, then if you try to alter the default behavior in JavaScript - well, you are out of the game.

Now, for all those who defend the "mandatory input" ideology: please look around yourself for the actual use cases. For example, okcupid.com (it's a dating site) has lots and lots of questions that would fit into radio-group control, unless it was so rigidly and unwisely designed to behave as some enterprise Java brain-dead manager designed it.

If there was a control that could provide n choices of m, where n <= m, then radio-group, as it is now, would be justified as a particular case of that more generic control, but, alas, there's not such control (checkboxes allow for variable number of choices, restricting the number of choices programmatically would, again, break the accessibility).

share|improve this answer
1  
A radio button is meant to have only one option valid. Your example of an actual use case would be something OTHER than a radio button list. As you state, checkboxes could work--and could also be accessible. The use of JavaScript does not, itself, make something inaccessible. –  DA01 Aug 13 '12 at 17:45
    
"A radio button is meant to [...]" - who says that? Do you have "some other" browser control to offer? I'd sure use that instead. The use of JavaScript, in this particular case makes the functionality of deselecting all options by repeated selection of one already selected impossible. –  wvxvw Aug 13 '12 at 18:46
1  
I have no idea what you are getting at. Radio buttons (both the physical ones that used to be on radios, and the ones now used in GUI interfaces) have always been defined as a set of options where only one can be selected. That is a fact. The 'argument' is prior usage and the precedent that the original physical device created. –  DA01 Aug 13 '12 at 18:58
1  
Screen readers and automation testing tools that can't handle javascript are woefully antiquated given that we have standards such as ARIA now. Yes, I admit, some popular screen readers (such as the horrendous JAWS are antiquated). Also (as I previously stated) client side validation may be required depending on the level of accessibility requirements one seeks. –  DA01 Aug 13 '12 at 18:59
1  
let us continue this discussion in chat –  DA01 Aug 13 '12 at 19:02

Totally agree with the OP on this one. The argument that 'you don't push a radio button to select between 2 options' is totally bogus. Take a look at your computer or any other electrical equipment - you push a button to turn something ON and push the very same button to turn it OFF. Not allowing deselection of a radio button is NOT intuitive for end-users but exactly the opposite. I have a case where we need to let users opt to show old data or only current data - they don't want 2 radio buttons because it's a binary operation (show/no-show). If they click then change their minds there's nothing to let them do that except a page refresh. Why shouldn't they be able to select/deselect the ONE option? There are countless use-cases for this functionality. You're STILL only submitting one (true/false) value so the logic is not broken.

share|improve this answer
1  
I don't see how that particular analogy applies to radio buttons. The situation you describe ("you push a button to turn something ON and push the very same button to turn it OFF") is analogous to a checkbox which has an inherent true or false value. –  Matt Obee Apr 23 '13 at 21:26
    
Hi @RadioButtonBad. Welcome to the UX Stack Exchange! I like your suggestion of the standard usage of a power button providing a potential affordance for how users would expect a radio button to work. Perhaps you could edit your post more directly to answer the OP's question though? He's already remarked on how it seems odd to him that radio buttons can't be deselected and is asking why they were designed this way. –  3nafish Apr 23 '13 at 21:49

The thing here is, if you have (a group of) radio button(s), that means it is mandatory to select one of them (That's how radios are made to behave), they are all blank by default to avoid the user from not choosing one and going with the default. If your client wants a control that can not be chosen then you must be using check boxes, and no don't make them uncheck each other that's not how they are meant to work, if a user only wants to make one choice he must have the freedom and many choices too.

share|improve this answer

You can use a small subtle button (e.g. a small 'x') for each radio group. Pressing this button clears the radiobuttons in the associated group. This may give less clutter then having all these extra 'n/a' radiobuttons, plus you do not have to think about how to label these extra radiobuttons.

share|improve this answer

I see two solutions:

  1. have a radio button "other" when none of the others apply. You should even provide an "other" for gender selection. A transexual may not feel "male" nor "female" and prefer another option. What you do with it is your choice. If you want to know the percentage males in a survey you might ignore the "other"s and just count males and females.

  2. Add a checkbox to the radio button group and gray out the entire group when the checkbox is unchecked. You could name the checkbox "select gender" for the above example, and process it as if a radio button "other" was selected when the checkbox is unchecked.

share|improve this answer

protected by JonW Nov 15 '13 at 15:22

Thank you for your interest in this question. Because it has attracted low-quality answers, posting an answer now requires 10 reputation on this site.

Would you like to answer one of these unanswered questions instead?

Not the answer you're looking for? Browse other questions tagged or ask your own question.