如何编写语义正确且可访问的 HTML 表单？

简化版

可访问表单要让每个控件拥有可感知的名称，优先用 <label for>；相关控件用 <fieldset> 和 <legend> 分组，错误信息与帮助文本通过 aria-describedby 关联，并使用正确的 type、name、autocomplete。键盘顺序、焦点反馈、错误状态和提交后的焦点管理也必须完整。

详细版

占位符不能替代 label，因为输入后会消失、对比度常较低，读屏器处理也不稳定。原生表单元素已经具备键盘行为、角色和状态，应优先使用；只有原生语义不足时才补充 ARIA。

校验失败时不能只把边框变红。应同时提供文字说明，将错误与控件关联，必要时设置 aria-invalid="true"，提交后把焦点移到错误摘要或首个无效字段。动态提示可谨慎使用 live region，避免每次输入都打断读屏用户。

正确的表单还会改善移动端键盘、自动填充、密码管理器和服务端数据解析，因此可访问性不是额外装饰，而是健壮交互的基础。

完整版教学

一、可访问名称是控件的身份证

读屏器聚焦输入框时，需要读出“电子邮箱，编辑框，必填”等信息。最可靠的方法是用 label[for] 指向控件 id，点击文字也会扩大激活区域，对触屏和运动障碍用户都更友好。

<label for="email">电子邮箱</label>
<input id="email" name="email" type="email" autocomplete="email" required>

若文字与输入框之间只有视觉位置关系，辅助技术并不知道它们属于一组。一个 20px 高的复选框配上可点击 label 后，整行 44px 高区域都可点击，命中面积可能增加一倍以上。

二、placeholder 不能承担标签职责

占位符适合给格式示例，如 name@example.com，不适合放字段名称。用户开始输入后提示消失，回头检查长表单时无法确认字段含义；某些浏览器的 placeholder 颜色也可能达不到足够对比度。

文本类型	是否持续可见	是否形成可靠名称	合适内容
`<label>`	是	是	字段名称
`placeholder`	否	否	简短格式示例
帮助文本	是	需关联	限制和解释
错误文本	出错时	需关联	问题与修复方式

浮动标签只有在视觉上始终保留名称、代码里仍使用真实 label 时才可靠。单靠 CSS 让 placeholder 移动，仍可能在自动填充或空值状态下产生歧义。

三、分组与说明要建立程序化关系

一组单选按钮共享同一问题，使用 <fieldset> 和 <legend> 能让读屏器在每个选项旁重复组名。帮助信息则通过 aria-describedby 指向一个或多个元素 ID，使说明在控件名称之后被读出。

<fieldset>
  <legend>接收通知的方式</legend>
  <label><input type="radio" name="channel" value="sms"> 短信</label>
  <label><input type="radio" name="channel" value="email"> 邮件</label>
</fieldset>
<p id="password-help">至少 12 位，包含数字和字母。</p>
<input type="password" aria-describedby="password-help">

name 相同让浏览器保证单选互斥，legend 负责组语义，CSS 只负责外观。用普通 div 模拟时，这些行为都要手工重建，成本和出错率显著增加。

四、正确类型会带来真实的平台能力

type="email"、tel、number、date 不只是样式差异，它们影响移动键盘、内置校验和辅助技术角色。autocomplete 使用标准令牌还能帮助浏览器和密码管理器准确填充姓名、地址和一次性验证码。

<input name="phone" type="tel" inputmode="numeric" autocomplete="tel">
<input name="otp" inputmode="numeric" autocomplete="one-time-code">

一个用户填写 8 个字段，每个手输约 6s，总计近 48s；自动填充可能把过程缩到数秒。不要为了统一外观把所有字段都降级成 type="text"，也不要对普通姓名字段滥用 autocomplete="off"。

五、错误反馈必须同时可见、可读、可定位

只使用红色违反“不能只靠颜色传递信息”的原则，也无法告诉用户如何修复。错误文本应明确说“邮箱缺少 @”，而不是笼统说“格式错误”，并通过描述关系连接到字段。

<label for="mail">邮箱</label>
<input id="mail" aria-invalid="true" aria-describedby="mail-error">
<p id="mail-error" role="alert">请输入包含 @ 的完整邮箱地址。</p>

提交含 3 个错误的表单时，可以在顶部生成错误摘要，将焦点移到摘要，再提供跳转到各字段的链接。对每次按键都使用 role="alert" 会造成连续播报，应在失焦或提交校验后再宣布重要变化。

六、键盘与焦点管理决定表单能否完成

原生控件按 DOM 顺序进入 Tab 序列，视觉顺序应与 DOM 顺序一致。不要用正数 tabindex 人工排队，它会制造两个互相冲突的顺序；自定义焦点样式也不能简单写 outline: none 后什么都不补。

:focus-visible {
  outline: 3px solid #2563eb;
  outline-offset: 3px;
}

若轮廓宽 3px、偏移 3px，焦点边界会在控件外形成清晰的 6px 视觉带，不遮住文字。弹窗表单还需要打开时设置初始焦点、关闭后归还触发按钮，并限制焦点不逃出模态区域。

心法：先用原生 HTML 获得语义和键盘行为，再用 CSS 美化，最后只用 ARIA 补原生表达不了的信息。

七、常见误区与追问

误区：有 placeholder 就不需要 label。 placeholder 会消失，不能稳定承担可访问名称。
误区：加上 aria-label 就比原生 label 更专业。 可见 label 同时服务视觉、语音和点击区域，应优先使用。
误区：错误边框变红已经足够。 颜色不能说明原因，也不能保证色觉障碍和读屏用户感知。
追问：必填项怎样表达？ 使用原生 required，视觉上补充一致标识；复杂组件再考虑 aria-required。
追问：禁用与只读有什么区别？ disabled 通常不可聚焦且不参与提交，readonly 可聚焦并通常会随表单提交。
追问：什么时候用 aria-live？ 用于提交结果、异步状态等重要动态消息，避免高频、冗余播报。

八、加强记忆

检查表单可以沿着用户完成任务的路径走一遍：看见字段时有持续标签，聚焦时读得出名称和说明，输入时获得合适键盘与自动填充，出错时既看到原因又能被读屏器关联，提交失败后能立刻定位，成功后收到明确反馈。原生 label、fieldset、正确的 type 和 required 是地基，ARIA 只负责补关系与动态状态；一旦反过来用 ARIA 模拟全部原生能力，复杂度会迅速上升。

简化版

详细版