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 this demo.
My beef is with radios, and the inability to "uncheck" them (which is the default behaviour in all browsers as far as I know). We just had an issue when one of our clients insisted that we 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.
Surely this behaviour is deliberate and took a room full of experts to agree upon, but what could those reasons possibly be?
Do non-techie users even have an expectation of how radios work?
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
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
I don't want to fill in this field?
If someone clicks the wrong option by accident, they're locked into 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.
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).
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...
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 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.