There is a pseudo class selector, :indeterminate, whose job it can be to select radio button inputs which are neither selected (have attribute “checked”) or unselected (don’t have that). This is a CSS3 selector, which may be in response to the HTML5 spec, which explicitly allows radio buttons to be in this state:
If none of the radio buttons in a radio button group are checked when they are inserted into the document, then they will all be initially unchecked in the interface, until such time as one of them is checked (either by the user or by script).
What’s the point of all this? Well… why explicitly allow such bad UI?
Neither choice selected
In a comment here last week, Lee Kowalkowski summed it up nicely:
It’s poor UI in my opinion. The most popular option should be checked. If choosing nothing is valid, then a radio group isn’t a good fit because the user cannot easily revert the group to its indeterminate state.
It’s worth repeating: the user cannot easily revert the group to its indeterminate state.
The HTML4 spec made more sense:
At all times, exactly one of the radio buttons in a set is checked. If none of the <INPUT> 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”.
That second part there, in plain English: Since we know no browsers actually follow this, we are adding this special note to remind authors to take this into their own hands.
In my opinion, we should revert back to the HTML4 spec, but browsers should actually respect it, by forcing at least one radio button to be checked, per group, at all times. Which would then make the :indeterminate pseudo kind of useless.
Remember that radio buttons and select dropdowns are essentially the same thing (can only pick one choice from multiple). So if you need an “unselected” state, perhaps a <select> with a default option of “Choose” would do the trick for you.
… or “UNSPECIFIED”
“if you need an “unselected” state, perhaps a <select> with a default option of “Choose””
IMHO, I’d say that was a poor approach as well – it’s not a peer of the other elements in the set (it’s an instruction, a ‘meta’ part of the form, not a value – you don’t have a gender of “Choose” or live in the state of “Choose”). If it would look wrong as a radio button (which “Choose” certainly would) it’s wrong as a select option too.
An option of ‘None’, ‘Unknown’ or similar would be the standard consistent solution.
Sure, the word you pick is debatable, but at least you can move the select dropdown back to the state where nothing is selected. Or more accurately, there is an option selected, but in processing you would treat it as no option.
I certainly agree with the main point, that an indeterminate radio button is a broken radio button, and a specification that allows it is also broken. Rather than allowing the indeterminate state to be reselected, it should never occur. If ‘indeterminate’ is a state, it should be deterministically so :)
Or a checkbox with javascript (read jQuery) to ensure there will be only one selected checkbox.
checkboxes*
I do not agree. Checkboxes are not made to replace radio… imho is even worse UI.
Little know debate, keep up the reviews!
Chris – I’m confused by your saying that select dropdowns and radio buttons are essentially the same in that with both you only get to choose 1 option.
The select dropdown can allow multiple selections to take place: http://www.w3.org/TR/html401/interact/forms.html#adef-multiple
I’m pretty sure you know what I mean. When it’s NOT specifically a multiple choice select.
I think shoutyman hit the nail on the head. If ‘choose’ is not an acceptable option when submitting the form, it should not be a choice in the dropdown.
When you require a choice to be made, using radio buttons allows you to not select something by default and still make it obvious that something must be chosen.
The fact that they can’t go back to nothing being selected is -by design-. There’s no null gender option on purpose. Something must be chosen, so there’s no point in letting the user go back to having chosen nothing.
Related scenario: My father is very new the web. The other day, he had an issue where someone’s webpage died before he had completely signed up for their service. Because he hadn’t finished the signup, but logged back in, it used some default values. It chose his gender as ‘female’.
My father was enraged. It took me about an hour to get him to understand that it wasn’t a direct attack on him for something and it was just a simple default in their system that he could go change at any time.
Oddly enough, a very similar thing happened to me with my father. He’s quite new to the web, and I left him alone to fill out an online insurance form. Being a slow typer, his form timed out before he completed it, and when he hit submit it stuck him with all the default options.
At least one upshot of this would be that if the default state was ‘neutral’, it’d make form validation easier, so this sort of thing wouldn’t happen?
Actually I’d rather not have a server-side session needlessly expire. Which in practical terms you’d have no server-side session-state whatsoever.
There’s no reason why what has been submitted so far can’t be passed from page to page whilst uncommitted until such a time it makes a complete transaction.
Quick question:
How would you default select the example you give at the beginning?
Some people may* get offended if you automatically choose their gender for them.
*(I am not arguing whether they are right or wrong, I just know some people who live in a perpetual state of dumbassery)
Personally I’d make a dropdown with three choices. Choose Gender, Male, and Female.
For things like that I’m a big fan of using OPTGROUP – I just wish that browsers defaulted to that value instead of the first option listed.
OPTGROUP is a nice option but it’s really tough for accessibility. If you get a chance, sit through a page with OPTGROUP being read by a a screen reader. It’s pretty rough
That was also my first thought. But the selection of gender is one of the few examples where this applies. Take e.g. the selection of credit cards. No one would be offended here.
You could use links/buttons in a wizard-style flow, or checkboxes and consider having both checked as an invalid state (if you really want to ignore people that belong to this group).
If we ignore HTML for the moment and discuss purely UI, I’m not sure that I agree with setting a default in all cases. On a large form, the problem with choosing a default for all things, is that there is no way for the application to determine if the user skipped the field or just wanted the default.
I think smart defaults are a good thing, don’t get me wrong, but it does not work in all cases. I’ll give you an example. In a mortgage application I worked on, there are a series of yes/no questions. We could have set defaults on them, we even have a button for setting them to “typical responses”, but we wanted to able to warn the user if they had never actually been set. With our application, you can fill out data in any order and come back to it later. It is very useful for the user to know they actually touched that part of the application.
I think that’s a great point.
One thing that should have been made more clear is REQUIRED or NOT REQUIRED. If the radio button group is REQUIRED, leaving no default choice is fine as the user will be prodded to chose one anyway. But making field required is typically something that needs to happen with server side processing or client side JavaScript.
Although… HTML5 has an attribute for required inputs now. I bet that factors into this heavily.
Still, I almost feel like radio buttons should ALWAYS be required. If they are optional, then the indeterminate state is the only possibility for “not choosing”, which we know is impossible to get back to that state once something is chosen.
While all these arguments are valid, I have to stand strong on the point of UX Engineering versus technical aspects. Forms are very interactive elements within an application and you have to be very sensitive to your audience.
Simply stating that all radio buttons must be required is incorrect. Simply stating that having a default value always set on a radio button is also incorrect.
Take the question into context and what is the value of that question. Will having a default make the form easier or do you risk offending a user? Is the action of someone selecting that option more valuable then moving someone through the form quickly?
I think using the male/female options in this article was brilliant. When building a form, what is the value of that information? I have filed out many forms that ask this question and many times intent is 100% marketing and that is VERY frustrating to many people. Why does Facebook need to know this when I initially register versus if I am registering for a medical service. See what I mean?
Defaults and standards are great ‘guidelines’ but as a good developer, we need to be sensitive of the content, context and use case before we throw down a bunch of arbitrary technical restrictions.
that is my $0.02
There are situations where having an initial indeterminate state makes perfect sense. If you’re trying to collect accurate statistics on your site’s visitors, then pre-selecting the most popular option is definitely not the right way to go. Many people don’t like to be the “edge case user” and will tend to think that the pre-selected answer is the answer they’re supposed to choose.
I can’t really imagine a situation where I’d want to give the user the option of reverting back to an unselected state. If a question doesn’t apply, then that should be an explicit option for the user to select.
…then that explicit option should also be the default, no?
Having a non choice like this forces the user to make the choice. If selecting none of the options makes sense then it’s up to the developer to validate and feedback to the user. This will force the user to actually answer the question where if the “male” option was selected by default and a female user missed the question you data would be incorrect.
Mm, I agree – I was mulling over whether my previous statement about brokenness was entirely fair (it’s not) and came to the same conclusion: In some/many cases a default choice isn’t wise *and* a ‘non-value’ isn’t appropriate.
Usually when you use radio buttons you need to have an answer otherwise the user would not be able to go on with the form because the rest of the form will react to that value.
EX ( SEX: Male or Female ) the rest of the questions in the form could change based on which sex they choose. )
If you wanted to you could give them a third choice like Shoutyman was saying and it could be “No Response”.
Russell makes a good point too, but like Chris states you would need some other processing (such as javascript) to notify the user that the field was not filled out. I think that if this is going to become a “Law of the land”that it instead should add javascript or server side processing to remove the default choice rather than have no choice there by default.
It seems that the opinions commented are IMO why sometimes we fail as designers, (authors, developers, etc.). Why are we using term UI “user” “interface”, but are seemingly ignoring the user in this case. There will be specific times where unselected radio buttons are needed. The above example “male and female” is one of those cases.
In every case that I use radio buttons, the selection is required. In the above case, you could add a third choice and label it “prefer not to say” or something to that effect.
I’m just speaking from the standpoint of a user who doesn’t want their choice made for them even initially. Some woman visiting your site and having “male” selected it for them having to choose “female” OVER “male”, might just click “back” instead. Just a thought.
I don’t know if I would like forcing at least one radio button to be checked. The main point of radio buttons is the fact they can only pick one. You should just validate to make sure that they picked one if the user needs too. For example: the css-tricks current question of the month poll. (“What is your server-side language of choice?”)
This is another example where a choice is required. When a radio button group is required, it’s fine for no default option to be selected.
But when they are NOT required, that is where it gets tricky. Let’s say the user was faced with the MALE / FEMALE choice. The click male, then decide they actually don’t want to answer that question. There is no way to “uncheck” male, hence, bad UI.
As someone mentioned above, manually adding a third choice for “No Answer” may be the best/only way.
I believe that’s a very good UI.
The point of radio buttons is to “force” the user into choosing an option. In a there’s ALWAYS one option selected (even if it’s blank, useless or invalid).
I always saw this much more intuitive. It forces the user to stop and choose, and not just “oh great, the site chose for me, let’s ignore it”.
Radio button is depicting just that: buttons on old model of a radio.
Remember those? If not, ask around. Those were for choosing emitting frequency band: AM, FM and so on. Pressing one when another was pressed made it pop-up. That’s way the concept for option.
But, if you didn’t push hard enough, the current button would not remain pressed, leaving no buttons pressed, hence the indeterminate state.
We should remember that analogue systems still are models for concepts used in UI, and we should try and understand and relate to them, even if now we have touch-screen and hand gesture.
Because they had a meaning and strict functionality, I might add. Everything was in it’s place and nothing was left to chance.
Having none of it’s buttons pressed meant that that radio is SILENT, even if you messed up with the volume. Also, it could be use then as an amplifier.
Heh, the stories I could tell you. But I’m too old and need my nap :).
Interesting, I never knew that. Following on from the real life analogy, when you first buy an old-timey radio, I’m sure that none of the buttons will be depressed, so that the first thing you do after turning it on is choose a frequency band.
I suppose the same concept applies here. If none of the buttons are checked, it ‘forces’ you to make a choice.
That’s exactly right. And then you fine tune, looking for your radio station, on the same analogue scale, which was basically a little stick on a string behind a graded transparent plastic.
Much like the …. Slider control. Heh, never doubt our technical heritage again!
But, on the point, I believe that indeterminate really means user didn’t mess up with the set yet, so this info also can be useful sometimes. On validation, first check for an option without checking all radio buttons, but a simple value for the set.
I meant that:
– when you validate a form, you would mark red some wrong items
– it would be easy then to mark red required radio or check boxes never “touched”
Or how easy it is to change the visual style as soon as the user “touches” it. Showing the user what changes he had made to the form thus far.
And that without any new added classes.
You can still find these types of buttons at 50’s era diners and in antique stores. I find it interesting to look at these classic and timeless designs to see how human interaction worked and how a lot of people may feel comfortable interacting with new designs, like on web sites.
IMO, this is yet another scenario in web design where the answer is an emphatic it depends.
Do as much UX testing as possible to try and find the best solution for the user and roll with it.
Having one radio button checked by default is not always a good idea. Some people can take it to mean that it’s the preferred/obvious choice and alienate them.
If nothing is selected by default then
1) It’s optional, which is problematic because once an option is selected this is no way to unselect.
2) It’s required, which presupposes that you have code in place to handle that “required”
So if you want to leave an radio button group in it’s indeterminate state, it had better not be optional and you better be prepared to write code to handle the required stuff.
I bet that the ballot results for the EU browser of choice would look very interesting if one option was to be selected by default :).
In the end, this is for mark-up, isn’t? So, is it good? Yes, for the indeterminate state you don’t have to add a new class.
Is it for validation? No, ’cause you do validation NO MATTER WHAT, right?
This radio is in a set. Having a default value for a set it’s like going to vote with a stamp already imprinted on your ballot. It HAS to be an indeterminate state for it to be optional, unless it’s mandatory. But then, still, you validate, don’t suggest.
IMO.
Agreed about validation. Regardless of css/html, there should always be client-side and server-side validation.
If you must have a default value, the you must have tabs, or autocomplete/combo-boxes. It’s the missuses of the concept that are to blame, not the tristate of a radio.
They, radio buttons, represent, in the end, value. And the normal cycle for a value is: undefined, inserted/modified, validated.
As for:
1) It’s optional, which is problematic because once an option is selected this is no way to unselect.
you can simply add a radio to the set that adds an extra option that handles that scenario.
My English is too brocken!
hmm, I think that Chris makes some valid points.
If it were me i would probably only use radio buttons with an indeterminate state for required fields. otherwise i would probably use a select field for non-required fields.
I would imagine for a poll a select field is not very user friendly and create issues with biased results. However having a preselected radio button would do the same, so it only makes sense to have an indeterminate state in this instance. especially because in order to vote it’s required to select.
for a non-required question, having the option to not answer should always remain an option. I can imagine it would be very frustrating to accidentally answer a question and not be able to un-answer. Having a select box makes that easy.
I guess it is more a choice of the right tool for a specific task. A radio button makes certainly sense for required fields. When you expect (force) the user to make a decision.
I think the statement that radio buttons without default choice are poor UI is rather simplistic. It will apply often, but not always. Whether a field is required or not, maybe you want the user to make a conscious choice. Providing a required radio button with a default choice is the same as an optional field that users can skip. Sometimes you may not want that.
I don’t think it’s a good idea to make a design choice that disregards a standard just because every browser you’re testing/supporting has overlooked the said standard.
If it’s really important the user is not guided by your defaults, or if it’s inconvenient for the user to correct their errors later*, give them a list of links or icons up-front, separate from the bulk of the data capture. This could even be combined with the bulk of data capture if enhanced with JavaScript.
(*Complicated or lengthy forms ought to have a summary page for the user to review before committing their data if they cannot subsequently change what they’re about to send.)
Hi guys. I have a question which I haven’t been able to figure out. Can you target a Radio button without adding an ID or class to it?
Here’s why I ask. Whenever I put a border on INPUT in my CSS, it adds a border to the Radio buttons also (in IE). So I have to put a class on all the Radio buttons and add CSS for no border on this class. There must be a better way..no?
Try attribute selector:
input[type=”radio”].
Thanks!! Worked perfectly! I am way too excited by this ;)
You’re welcome. You should probably consider the following:
– use input { border: none}
– target by class, id or other means those elements that need border
removing border from all inputs is a little dangerous, unless you have a good plan in place. Submit buttons have default browser styling (like the gel button look in webkit), which breaks if you remove the border. So if you plan on replacing that with your own button style, go for it, otherwise leave those browser defaults in place.
Thanks Chris.
That’s why I said it has to be considered, as an alternative, the other side of a coin.
Like a new radio button in the set !
Chris has mentioned several times that one of the conundrums is that there is no way to revert to the indeterminate state.
1. Doesn’t the dreaded form Reset button do that?
2. For those times when you want your radio button group to reset, couldn’t you create (javascript) a dedicated “unselect” button next to that group?
Did you just say reset button? *Sigh*
:)
No easy way.
1. The dreaded form reset button does nothing of any use. If you had to re-echo the form with a server-side error, the reset button would revert the form to the re-echoed values.
2. If you wanted to depend on JavaScript, yes. Would the average user understand the button? Probably doesn’t even matter, if it was a valid thing for the user to do, you might as well just have that button as the first radio and make it the default. Your validation can force the user not to choose that option if you want it to.
I’m thinking of the Male/Female scenario and it being optional where “prefer not to say” is not applicable/appropriate to the form. Otherwise, that would be the default option. Again, this is regarding ways to “reset” to the indeterminate state.
I didn’t say I liked the Reset button. ;) It does seem to be a partial solution to the question.
I believe that indeterminate state is programmer’s code for a NULL value (for a radio-group), a value that is NOTHING yet, as in NOT zero, NOT blank. Catching that helps pre-validate.
You cannot achieve that with a select element. However, if you want a neutral value a user can return to, one can achieve using just that.
useful if you don’t want bias in selection, thanks!
This thread makes me think of the ‘one or more’ selection problem discussion in ‘Tog on Interface’ from 1992! Funny that we’re still having the same arguments, still no good solutions…
HTML5 contains an idiotic spec. Color me shocked.
The good reason for not forcing a selection: radio buttons are used in surveys. Forcing a default biases the results. A forced default would also allow for massively inaccurate, but technically valid, data when a respondent just clicks next all the way through.
If you forced your default radio to be an invalid answer, that avoids bias. You don’t need to use invalid HTML as if it were necessary.
So, we should add a radio button entitled “You haven’t chosen yet” as the default for every radio group we build? This is decidedly un-semantic, and I think it’s safe to say it would be confusing to the user as well.
It makes much more sense (IMO, and from a UI perspective) to apply some styling that draws the user’s attention to the group of choices that they haven’t yet chosen from.
Yes, you’re going to validate the inputs and explicitly remind them about it anyway – but why, when you could have provided a subtle, contextual reminder and saved them the trouble? Who prefers going back and fixing mistakes on a submission to getting it right the first time?
Why are we making things so complicated??? The thing is when using radio-group for selecting gender there’s is only two options, MALE and FEMALE. Don’t give them an option of NO ANSWER etc.
Actually I was once legally forced to apply this indetermindedness to a form by the Swedish Consumer Agency. It was a case where we wanted the choice of an extra insurance for an online travel agency to be prefilled but the Consumer Agency forced us to not make any choice for the customer. We were not even allowed to make ‘no’ as the default choice…