表单可访问性根基在于正确使用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 是唯一被所有主流辅助技术一致识别的分组机制。

html-deploy

使用 htmlcode.fun 将 HTML 内容或文件部署到网页，适用于用户要求“部署到网页”“托管此 HTML”“生成此前端...的实时链接”等场景。

下载

• 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 的那部分真实用户。

前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！