label是屏幕阅读器识别表单控件用途的唯一可靠依据；缺label或for/id绑定错误，视障用户仅听到“编辑文本”而不知用途，因屏幕阅读器依赖严格字符匹配的for与id关联上下文。
label 是屏幕阅读器识别表单控件用途的唯一可靠依据，缺它或绑错，视障用户听到的就只是“编辑文本”“复选框”，完全不知道该填什么、选什么。
为什么 screen reader 读不出 input 的用途？
只写 <input type="email">，屏幕阅读器最多报“编辑文本”，不会说“邮箱地址”。它没上下文，就像给你一把钥匙却不告诉你锁在哪。
常见错误现象：
-
placeholder被当label用（输入时消失，且多数读屏根本不播报） - 用
<div> 或 <code><span></span>模拟 label（无语义、不传焦点、不触发状态切换） -
for值和id大小写/空格/下划线不一致（绑定静默失效，DevTools 看不出） -
for="userName"对应id="username"（大小写不一致） -
for="email "含尾部空格，而id="email"没有 - 循环渲染中用索引拼
id却忘了同步更新for，比如id="email-0"和for="email-1" - 自定义下拉必须透传焦点和键盘事件（如
ArrowDown、Enter）到它身上 - 禁用隐式嵌套写法：
<label>姓名<input name="name"></label>——中间插入注释、换行或动态节点极易导致 DOM 解析失败
for 和 id 必须严格字符级匹配
屏幕阅读器靠 DOM 中 label 的 for 属性与 input 的 id 做字符串级比对——大小写、连字符、下划线、首尾空格，全算在内。
常见错误：
select 下拉框的 label 关联为什么更敏感？
iOS VoiceOver 和部分 Windows 屏幕阅读器对 label 与 select 的 DOM 位置有隐含要求：两者必须紧邻，中间不能插 <p></p>、<div> 等块级元素。否则点击标签文本，焦点不会落到下拉框上。
<p>还要注意：</p>
<ul>
<li>别用纯空格或“请选择”占位；禁用 <code>display: none 或 visibility: hidden 隐藏原生 select
什么时候该用 aria-labelledby 而不是 label？
当表单控件需要复用页面中已有的可见文本作为标签时，aria-labelledby 是更合适的选择。比如搜索框旁已有 <h2 id="search-title">站内搜索</h2>，就不必再写一个独立 label。
关键点：
-
aria-labelledby指向的是页面中真实存在的、用户能看见的元素id，屏幕阅读器会朗读其文本内容 - 别同时用
aria-label和内部文本，会导致重复播报 - 也别指向不存在的
id，读屏软件会静默跳过 - 对格式要求、错误提示等辅助信息，优先用
aria-describedby关联<div id="hint">请输入 6–12 位密码</div>，它会在主标签后自动朗读
最容易被忽略的点是：label 不仅关乎“读得出来”，更决定“点得进去”。哪怕视觉样式完美，只要 for/id 匹配出一丝偏差，鼠标用户点标签失焦、键盘用户 Tab 进去没反应、屏幕阅读器报不出字段名——三者其实是同一问题的三种表现。
