<input type="radio"> 是单选评价场景首选,需确保 name 相同、id 与 label[for] 匹配或嵌套使用,配合 value 语义化取值,并通过 aria-label 或 aria-labelledby 补全无障碍支持。
<input type="radio"> 实现单选评价标签评价场景下最常用的是 1–5 星或「非常不满意」到「非常满意」的单选,<input type="radio"> 是语义正确、无障碍友好、无需 JS 就能提交的首选方案。
关键不是“怎么加标签”,而是“怎么让标签可点击且绑定准确”——很多人漏掉 for 和 id 的配对,导致点击文字没反应。
<input> 必须有唯一 id,对应 <label> 的 for 属性<input> 包在 <label> 里也行(此时不用 for/id),但要注意样式继承和焦点行为name 相同,否则浏览器当多个独立单选组处理value 存语义值(如 "5" 或 "very-satisfied"),后端/JS 更好解析<label> <input type="radio" name="rating" value="5" id="rate5"> ⭐⭐⭐⭐⭐ 非常满意</label><label for="rate4"><input type="radio" name="rating" value="4" id="rate4"> ⭐⭐⭐⭐ 满意</label>
<select> 做快捷评价标签<select> 看似简单,但在评价场景下有硬伤:移动端唤起下拉菜单打断操作流,视觉反馈弱,无法并排展示图标或文字描述,且默认样式难统一。
更实际的问题是:用户扫一眼要 3 步(点开 → 找选项 → 点击),而 radio 组点一次就完成;而且 <select> 的 value 和显示文本强耦合,改文案就得动代码逻辑。
立即学习“前端免费学习笔记(深入)”;
<input type="radio"> + CSS 排版明显更直接<select> 适合选项多(如 10+ 种反馈原因)、空间受限的后台表单<select> 的键盘导航体验远不如 radio 组稳定aria-label 和 aria-labelledby 怎么补全无障碍支持纯图标(如只放 ★)或缩略文字(如只写「差」「优」)时,屏幕阅读器会读不出完整语义。光靠 CSS 隐藏文字不行,得用 ARIA 明确补全。
aria-label="请对本次服务打分",适用于无可见标题的嵌入式场景<h3>您的满意度?</h3>),优先用 aria-labelledby="title-id" 关联,比 aria-label 更利于上下文理解aria-label,除非图标与文字不一致(比如显示「?」但语义是「5 分」)aria-hidden="true":隐藏了图标,但没补替代文本,等于直接砍掉信息用 Flex/Grid 排成横排很常见,但几个细节一错,用户点不准、焦点跳失、甚至触屏误触:
label 或包裹容器有足够点击热区(最小 44×44px),尤其在移动端input[type="radio"] 直接设 display: none 后只靠伪元素模拟——这样会切断原生 focus/checked 状态链,键盘 Tab 会跳过:focus-visible 而非 :focus 控制焦点样式,避免鼠标点击时出现多余轮廓线transform-origin: center,否则动画偏移导致视觉错位真正麻烦的从来不是“怎么让它看起来像评价标签”,而是“怎么让它在任意设备、任意交互方式下都可靠响应”。很多所谓‘快捷实现’,上线后才发现盲人用户无法操作,或 iOS Safari 上点击失效——问题往往出在 label 绑定或 focus 状态管理上。