是否应始终选中单选组中的一个 HTML 单选按钮？
是否有任何标准（HTML、UI、可访问性等）规定应始终选择给定的一组单选按钮中的一个单选按钮？
我遇到了一项业务需求，要求我将一组中的两个单选按钮保留为未选中状态，然后使用逻辑强制用户选择一个按钮才能继续。
虽然我知道如何实现这一点，但感觉不对，我也这样暗示过，但我正在寻找更明确地规定这一点的指导方针，以便我可以将其纳入我们自己的标准中。
Are there any standards (HTML, UI, accessibility, and such like) that stipulate that one of the radio buttons in a given group of radio buttons should be selected at all times?
I have encountered a business requirement whereby I have been asked that both radio buttons in a group be left unchecked, and then to have logic forcing the user to select one before they can continue.
While I know how to achieve this, it felt wrong, and I intimated as such, but was looking for guidelines that stipulate this more explicitly so I can feed this into our own standards.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
我本来想说我过去读过雅各布·尼尔森的一些东西，但是哎呀，我发现了它：
附言。就我个人而言，我总是默认选择一个，所以对于选择框，但发生的情况是在法律条款和条件下，律师们很害怕，当然，你把猫喂给你的狗，你将永远害怕小猫：
http://www.useit.com/alertbox/20040927.html
I was going to say I read something in the past by Jakob Neilson, but heck, I found it:
PS. personally I ALWAYS have one selected by default, and so for select boxes, but what happens is in legal terms and conditions, lawyers are afraaaaid, of course, you feed the cat to your dog you will always be afraid of the kittens :
http://www.useit.com/alertbox/20040927.html
标准并不总是有意义
如果您遵循其他答案所述的标准（尼尔森所做的），则应始终选中一个单选按钮。
但如果您遵循常识并针对用例进行设计，那么答案是显然不是。天知道什么原因该标准完全忽略了一个非常流行的用例：
也许一个典型的例子是李克特量表 - 任何默认值都会吸引参与者：
现代语言示例
您会如何将以下问题翻译为接口：
该标准迫使你这样问：
因此没有人遵守它们
正是因为该标准没有考虑到这种情况（以及替代方案缺乏可用性，例如带有空白选项的组合框），所以没有浏览器遵守该标准 - 想象一下带有单选按钮的 Google 表单有默认值。
Standards don't always make sense
If you follow the standard (which is what Neilson does) that as other answers state - than one radio button should always be checked.
But if you follow common sense, and design for use cases than the answer is clearly not. For god knows what reason the standard completely neglects a very popular use case:
Perhaps a prime example for this is likert scales - any default will prime participants:
A modern language example
How would you translate to an interface the following question:
The standard forces you to ask it this way:
And so no one comply with them
It is exactly because the standard doesn't account for such cases (and the lack of usability in alternatives, like comboboxes with a blank option) that no browser comply with the standard - Imagine Google Forms with radio buttons having a default.
任何时候你重写默认的浏览器行为都会给用户带来不确定性。此外，平均而言，当有两个选项时，预先选择的选项正确的可能性为 50%。强迫用户选择它只会减慢他们的速度，因为他们假设他们要么是盲目的，要么是无能的。
我个人认为这个概念是侮辱性的——但我不是经理。
Anytime you're overriding a default browser behaviour you're creating uncertainty for the user. Furthermore, on average, when there are two options there is a 50% chance that the pre-selected one will be correct. Forcing the user to select it just slows them down on the assumption they're either blind or clueless.
I would personally find the concept insulting - but then I'm not a manager.
一个很好的例子是，当您拥有一家网上商店，并希望客户做出主动选择，而不是让某些订单通过时，客户只需单击“添加到购物车”而不选择任何尺寸，从而获得预先选择的尺寸。
我错了吗？
One good example is when you have a webshop and want the customer to make an active choice instead of letting some orders through where the customer just clicked on add to cart without choosing any size and therefore get the size that is pre selected.
Am I wrong?
是：http://www.w3.org/TR/html401/interact /forms.html#radio
该规范使用术语“用户代理”来表示通常所说的“浏览器”。 所以规范说，如果没有检查，浏览器将检查第一个。
更新： 请注意，我尝试过的 4 个浏览器实际上都没有这样做！< /em> 他们不检查第一个无线电，并且没有无线电作为
=on提供给服务器。一个好的 Web 框架应该进行服务器端检查（无论如何它都应该这样做，因为突然或伪造的 POST 可能会导致同样的情况）。Yes: http://www.w3.org/TR/html401/interact/forms.html#radio
The specification uses the term "user agent" for what is commonly known as "browser". So the specification says that if none is checked, the browser will check the first.
UPDATE: note that none of the 4 Browsers i tried actually does this! They dont check the first and none of the radios are given as
=onto the server. A good web framework should do the serverside-checking (it should do it anyway because an abrupted or forged POST could cause the same).