Why is it impossible to deselect HTML "radio" inputs?

  • 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 Questions

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

    2. 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?

    3. Do non-techie users even have an expectation of how radios work?

    4. Is it likely that people are trying to deselect radio options by clicking them again, expecting a toggle, and getting frustrated?


    Look at this mockup: http://jsfiddle.net/f4vXj/1/

    How could this be changed to appear the same way with 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 clicks the wrong option by accident, they're locked in to selecting one of the options.

    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.

    http://jsfiddle.net/f4vXj/2/ from http://stackoverflow.com/questions/2117538/jquery-how-to-uncheck-a-radio-button 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.

    An alternative I've seen numerous times, is to use checkboxes with javascript that automatically deselects the other options (making sure the question says "Select one" or something).

    It’s a logical physical analogy: with *actual* radio/tape player buttons, you can’t “unpush” a button—unless of course you push in two at once just enough that the depressed one releases but the un-depressed one doesn’t catch, but that’s just silly.

    @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.

    @WesleyMurch: We use panels, buttons, sliders, meters, checkboxes, icons, labels, and knobs exactly like their physical counterparts. If you want radio buttons to be deselectable, you’re thinking about radio buttons wrong. You should use checkboxes and restrict them to a single selection—because that’s how it’s done on paper forms.

    @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.

    @WesleyMurch - Because as I'd said before Jon, I've already seen it numerous times on the internet. It is expected behavior in the right context, generally a quiz/form that says in the question "Select one". Making radios unselectable, I've not seen before...

    @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.

    _that’s how it’s done on paper forms_...Yes and usually if paper forms have many options, they also include a NONE option. On the web, checkboxes would not be the best option here, radio buttons with a none option would be the optimal solution.

    On a technical note, in html form submission, if no radio button is selected the name/value pair of the radio button input is not included in the form submission. This is also by design. I do not recommend changing their intended usage.

    You could add a fictive radio button to the end of the list called "None of the above" and possibly even have it marked by default (only possibly, since it wouldn't force users to knowingly choose an option). I've even seen this used in printed multi-choice exams (with trick answers).

    Obviously those experts in the room forgot a control which lets users select one option or none, but not more than one. Being that so, I think it is ok to fix it with javascript and checkboxes.

    People keep talking about 'mandatory'. I want exclusiveness, but in my case I don't want 'mandatory'. 'Mandatory' should be a separate property that I can set on different things. For instance "please select at least one checkbox" is normal to see. So I come down on the side of thinking the default behavior is bad, and wanting to fix it with JS.

    In your case, would it not be best to have an "applicable" checkbox, instead of a "not-applicable" radio button? For example, let's say I'm ordering a pizza online and the form allows me to add extra toppings. You could present a checkbox with the label "Add extra toppings". When clicked, radio buttons would appear/disappear with the possible toppings. It seems more intuitive to only display the extra toppings if the user wants them, because it de-clutters the form. Also, hiding the radio buttons prevents the values from being submitted.

    What about a clear selection button? To me this is more intuitive than using a radio button option to do it.

    You can sidestep this with a group of checkboxes that become disabled when one (or other appropriate number) oft them is toggled on.

    Just my observation... no matter how user friendly you design these things for humans there will still be one monkey... I have seen many people, clients, asking .."why is it not unchecking?" :/ literally..everyone expects it to uncheck even after writing mandatory text sentence or having '*' ... I also prefer to have unchecked functionality since we do understand this but normal people are still not aware of this simple thing even in 2020...

  • Ben Brocka

    Ben Brocka Correct answer

    9 years ago

    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.

    Totally agree, I prefer to have the user *explicitly* choose "n/a" by selecting the option (as opposed to skipping over the field entirely), but I don't get why the ability to deselect a radio would be a bad idea for any reason - it's just as if the field was in its default, unchecked state.

    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

    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.

    Radio buttons are usually used on Finite State Machines where each button is a state, "Off" or "Stop" usually has a button assigned to it, so having no buttons pressed in no longer makes sense

    I get what the control is trying to emulate, but I just don't see why this is needed on the web (the context in question). It seems like there should be a way to opt out of that behavior, or maybe another input type altogether. I feel like your first statement about ***not*** selecting default values (which I agree with) doesn't align with your statement that having no value selected "doesn't make sense".

    @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: That's maybe the most compelling answer I've heard so far.

    @Inca that quite nicely sums up how I was trying to explain them as Finite State Machines

    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.

    @Inca: one option required: that should be left to validation, and not imposed by the input itself. Just feels better.

    @clime: it is not about validation but about communicating expectations to the user.

    @Inca: Ye and there is a standard way to let a user know that an input is required - star upon label. You can type something into a required text input and then delete it for whatever reason, right? You can unselect an option that you selected before for a required select. You can uncheck all checkboxes where at least one is required. Yet, at the moment you click on one of radio buttons (all empty before because no default set), you cannot undo it - at least one button will stay checked. Frustrating. Just thinking about it makes me sick. But yeah, we need to live with that glitch for now.

    @Inca So here's the problem: it's **forced**. I keep running into this with all sorts of various disputes in technology: **I'm** the developer, don't force my components to do things just because that's the way they're "usually" used. I think the real solution here is to have an attribute on option buttons/selects that developers can set to make them clearable. One practical reason why you might want undo is if you select an option, then later question your decision. You may want to clear it and get back to it; this has nothing to do with validation, that's a separate matter for separate code.

  • 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.

    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.

    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...

    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).

    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: The client ended up folding to my pressure to keep the "blank" radio selection. As far as the technical side: It's easy enough to do, but in light of the viewpoints here I've come to my senses, and won't be hacking anything.

    As far as I remember since 2003, it was totally possible to leave radiobuttons without selection. Your "legacy" statement is wrong.

    @Nakilon It still is possible (unless validation). The discussion here is all about what happens after the user clicks one.

    I disagree that people would not try to uncheck a radio button. If they selected one and they want to undo that, and there is no obvious way, the first thing they will try is to click again. Because of the similarity between checkboxes and radio buttons, that behaviour makes sense. Because clicking on the button chaned its state, if they need to change the state again, they'll click on it again. This is totally intuitive.

  • 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.

    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.

    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.)

    @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: 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 I actually agree with you on that point. I, personally, don't feel that radio buttons should ever be completely unselected by default.

    @DA01: Yet they need to be unselected for e.g. man/woman case, or any questionnaire case. Deselection should be possible. We talk about web, not desktop. People are used to context changing meaning so I don't think that anyone would be confused that circle input on desktop is something tiny bit else than circle input on a web page. Users today have already wired the current behaviour of radios up in their heads but the change would not be that hard. Just to make: _no button selected_ equivalent to _not applicable/i don't want to answer_. The extra button would and should stay.

    @clime the interaction you are describing is that of a checkbox. So use a checkbox for that. Not a radio button. EDIT: oh, I see what you are commenting on. Yes, with man/women, it is nice to have it so that there is no default, thereby 'forcing' a user to make a choice. I will concede that.

    @DA01: I am describing this: _at most one option can be selected_.

    @DA01: Thank you. I am not a fan of any javascript hacks in this regard. I just believe radio buttons on web should behave like that by default. Maybe one day.

    @clime wait...maybe I'm confused. Are you talking about 'none selected by default'? If so, that is how they work on the web by default as long as you don't set the 'selected' attribute on any of them. Example: http://jsbin.com/ofomAXuL/2/ No JS is needed for that.

    @DA01: I am talking about possiblity to unselect a radio button. I would like radio buttons to behave like this: _at most one option can be selected_ but with possibility always get into _all unselected_ state again.

    @clime oh, I see. I guess that's where I disagree. In those situations, there should be a 'not applicable' or 'none' option of some sort. If it's a required field, then one has to be selected anyways. If it's not a required field, then I think it's OK to have a radio that helps indicate that. In the male/female example, I'd suggest a 3rd option of 'prefer not to answer' or something like that. That said, I could maybe be convinced in the right context. I guess having a way to 'completely deselect them all' could be applicable in very particular cases. In which case, the JS solution might be OK

    @DA01: I think the third option (_prefer not to answer_, etc) is cool. Nevertheless, even with it I would like radios to be deselectable. Just because if any of options was not checked initially a user should be able to return to that state after he/she clicked on some. It is possible with all other inputs so why shouldn't it be possible for radios. Ye, if it is a required field, one has to be selected, that is true, but it is just weird to enforce that on html input level when there is validation for not acceptable values. Desktop does not have that usually which makes the difference in reqs.

    I did so and I never had any complaint from the user. If the user doesn't think it works, he won't try. I don't see any negative consequence.

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


    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, 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.

    I couldn't find equivalent language in the HTML5 standard.

    "this isn't considered to be expected behaviour". Says who?

  • 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.

  • 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.

    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?

    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.

    If my memory serves when you halfway pushed it, the selection wouldn't necessarily change, just the button state.

    The behaviour when pushing halfway was somewhat erratic and could most definitely be considered a 'bug' due to the mechanical construction of different devices. On some devices, a halfway push would actually 'deselect' all channels with the result that only static came out of the speakers.

    There could be more than a couple of preset channels, otherwise a good description of mechanical buttons.

    It is called "radio buttons" because of the behavior that when you push one in, the other one pops out. That's all.

  • 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.

  • 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.

    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.

  • 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).

    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.

    "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.

    "who says that" = it's the very definition of a radio button. from: http://en.wikipedia.org/wiki/Radio_button "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."

    As for another control, I'm saying your suggestion of a checkbox list is appropriate, as a radio button list is not designed for selecting more than one option. As you state, limiting the selection to 'n' requires JavaScript. That doesn't necessarily mean it's inaccessible, though. Bottom line is that I would suggest a checkbox list with javascript and the appropriate/redundant server-side validation to ensure accessibility needs are met.

    To rephrase it: "a radio button is meant to have only one option valid" is a preposition that has no argument. You put it as a "fact of life", while this is no axiom or fact. It is an opinion. Be it your own opinion or opinion of W3C or anyone else - is of no consequence. Preposition is made true or false in a formal way, where opinions don't matter.

    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.

    Don't you understand that most screen readers, or automation testing tools don't and cannot execute JavaScript? If you can do it only in JavaScript, for certain purposes, it means you can't do it.

    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.

    In other words, limiting the selection to n via JavaScript doesn't mean it's inaccessible since you can certainly handle that server-side as well. The JavaScript is then a nice UX for those that have it, but won't make or break the system if it's not there.

    Historical use cases are irrelevant because the radio buttons in question function differently and serve a different function. They are only somewhat similar to their analogical prototype, but you can't make conclusions on this basis. There is no generic UI control, but there is a particular case of it. This is an obvious oversight from the engineering point of view.

  • 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.

    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.

    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.

    If a control has the capacity where the user doesn't have to make a choice, then it shouldn't be a radio control. Case in point, older electric flick switches. They either can be pushed to an OFF position, or an ON position. But there's no middle ground. Neither can you change your mind about it and say 'I don't wanna make a choice'. The button will have a state. In your case, look at using a checkbox instead of a radio button.

    Totally agree. For instance checkboxes have a variety with 3 states. "selected" "unselected" and "undefined". For radio buttons there are also use cases where "undefined" is a valid state. Unselecting a button would be the logical case.

License under CC-BY-SA with attribution

Content dated before 6/26/2020 9:53 AM