Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

The current standard says something else:

> If none of the radio buttons in a radio button group are checked, 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).

That behaviour makes more sense for the Web, so that the user is required to make an explicit choice, and I'm not sure if browsers ever cared about this little part of the standard. When interacting with OS components, it makes sense that there's some default or already configured value.

https://html.spec.whatwg.org/multipage/input.html#radio-butt...



Huh, that's odd that it got changed. I can't think of any valid case where [no option] checked is part of a set of radio buttons. The user must be presented by a default, their entire reason for existing as is that one of them is checked all of the time.

Microsoft's Windows guidelines implicitly says that one option must always be checked: https://learn.microsoft.com/en-gb/windows/win32/uxguide/ctrl...

> If none of the options is a valid choice, add another option to reflect this choice, such as None or Does not apply.


Surveys are a valid use case for radio buttons that come unchecked by default.

You do not want to influence people by presenting them with a default (already checked) choice. (You also typically want to randomize the order, at least when there is no inherent order to the options, e.g. when you are asking about frequency.)

Surveys are also the place where that distinction between single choice (radio buttons) and multiple choice (checkboxes) becomes most apparent because surveys tend to liberally mix the two, so any additional UI signposts you can use to help people filling out the survey are helpful. (The typical recommendation for multiple choice is to still explicitly call out in text that multiple options can be checked.)

Surveys sometimes also have the absolutely wild combined list with checkboxes and – typically as the fixed last option even if you randomize the rest of the options – a radio button (e.g. “None of the above”) that automatically unchecks all other options (and is unchecks itself if any other option is picked).

I don’t think this exists in any spec anywhere but is the most normal thing in the world in most survey software.

I‘m always very precise with whether I use checkboxes or radio buttons when designing surveys.


> I can't think of any valid case where [no option] checked is part of a set of radio buttons. The user must be presented by a default

In a political vote, wouldn't that be untolerable bias?


I would never use a group of radio buttons in such a case, would you?

But if hard pressed and not allowed to design a better UI I would do the following options with radio buttons:

( * ) blank vote

( ) Option A (potentially in random order vs other non-blank options)

( ) Option B (potentially in random order vs other non-blank options)

( ) Option ... n


Why would you not use radio buttons? And what pattern would you use instead? I don’t get it …

Radio buttons are the correct metaphor for picking one option among a list of options. Why use something else? What use interface element do you think exists that works for this kind of interaction?

I’m honestly confused why you think radio buttons are the wrong type of interface element for this interaction. What‘s the reasoning as to why this seems so obvious to you? I’m honestly just trying to understand you.


Because voting is a multi-step process often involving more than one action. I have experienced all the below votes at governmental level, they are not hypothetical to me:

Sometimes the voter has the ability to add arbitrary options to the ballot.

Sometimes multiple values are allowed.

Sometimes there are positional votings.

Sometimes there is ranked-choice.

Sometimes you do not even want to submit the vote.

Looking only at "these are the options available, choose one and only one" is not a valid strategy for reaching the conclusion on what UI idiom to use.

I protest against the default assumption that radio buttons (no matter how much I like them) should be the default go-to for voting interfaces because of the context of voting is too complex.


That is such a weird perspective not at all relevant to this discussion.

Obviously all the examples you named are not a good fit for radio buttons. Except maybe the last one where you can just add an “invalid vote“ radio button choice.

But that doesn’t mean that for a fairly standard “pick one” vote radio buttons aren’t a good choice! You don’t have to be consistent within the concept of voting, you just have to be consistent for the one relevant use case!




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: