表单可访问性根基在于正确使用label、fieldset、legend三类原生标签：label须用for与input的id显式绑定；fieldset必须包裹逻辑相关的成组控件，legend作为其首个子元素提供语义标题；name和type属性需准确设置以保障提交与辅助技术识别。
表单可访问性不是靠加一堆ARIA补丁堆出来的，而是从结构层就该用对 label、fieldset、legend 这三样原生标签。其他所有优化——实时校验、错误播报、键盘焦点——都建立在这个骨架之上；骨架塌了，再 fancy 的 JS 也救不回屏幕阅读器用户的填写体验。
label 必须显式绑定，不能只靠视觉对齐
很多页面“看着有 label”，但点击文字无法聚焦输入框，或 VoiceOver 完全读不出字段含义，根本原因是 label 和 input 没建立浏览器可识别的关联关系。
- 正确写法：给
input设唯一id，label用for属性精确指向它，比如<label for="email">邮箱</label><input type="email" id="email" name="email"> - 避免隐式包裹：像
<label>邮箱<input name="email"></label>在 DOM 动态更新、换行或注释插入时容易断开关联，iOS Safari 和部分旧版 Android TalkBack 不稳定支持 - 别用
aria-label或title替代label：它们不会触发点击聚焦，也不能被所有辅助技术解析为“可操作控件标签”
fieldset + legend 是分组逻辑的唯一可靠表达
当出现单选、复选、地址段、偏好设置等成组字段时，仅靠 CSS 排版或 div 包裹毫无语义价值。屏幕阅读器用户需要知道“这一堆是干什么的”，而 fieldset + legend 是唯一被所有主流辅助技术一致识别的分组机制。
-
legend必须存在且为纯文本（不推荐仅用图标），它是该组的“标题”，会被朗读两次：一次进入组时，一次离开组时 - 不要嵌套
fieldset：多层嵌套在 NVDA 和 JAWS 中可能跳过中间层级，导致上下文丢失 - 移动端尤其依赖这个结构：VoiceOver 在“组模式”下会把整组当一个单元滑动，没有
legend就等于没提供上下文
name 和 type 不只是提交和样式的事
name 决定后端能否收到数据，type 决定软键盘、校验行为、无障碍角色识别——这两者错配，直接导致“能看见但填不了”或“能填但交不上”。
立即学习“前端免费学习笔记（深入）”；
-
name必须存在且语义化：空name的input不会出现在FormData中；name="field_7"这类值让后端和测试都难维护 -
type="email"触发 iOS 键盘 @ 快捷键、Chrome 基础格式校验、以及辅助技术中“email 输入框”的角色识别；用type="text"+ JS 校验，这些能力全部丢失 -
type="number"的值仍是字符串，且允许粘贴e、-等非法字符；提交前必须手动转换，不能依赖valueAsNumber（IE 不支持，非法时返回NaN）
错误提示必须可感知、可定位、可理解
仅在 DOM 里放一段红色文字，不加任何 ARIA 关联，等于没提示。辅助技术用户既看不到颜色，也无法自动聚焦到出错字段。
- 用
aria-invalid="true"标记无效字段，配合aria-errormessage="error-id"显式关联错误文案元素 - 错误文案元素需设
id="error-id"，并放在对应input附近（DOM 顺序优先于视觉位置） - 提交失败后，必须调用
input.focus()聚焦第一个错误字段，并确保该字段在视口内；否则键盘用户得手动按几十次 Tab 才能找到问题点
最常被忽略的一点：所有这些结构优化，必须在无 JS 环境下仍能工作。一旦你把 label 绑定、分组逻辑、错误反馈都压给 JS 控制，就等于默认放弃了只用键盘、只用屏幕阅读器、或禁用 JS 的那部分真实用户。
