前端开发者必知HTML表单交互状态语义化维护

表单交互状态的语义化维护，核心在于让每一个状态变化（例如聚焦、禁用、验证失败）都通过原生 HTML 属性来清晰表达，而不是仅仅依赖 CSS 类或 JS 变量“模拟”出状态。许多项目会使用 class="is-focused" 来模拟聚焦状态，但屏幕阅读器和浏览器的原生表单逻辑只认可 focused 的 DOM 状态或 disabled 这样的属性。一旦 JavaScript 失效或辅助技术绕过了样式层，这些“伪状态”就会彻底失效。这就像给车装了炫酷的引擎盖装饰，但发动机本身是坏的——关键时刻根本跑不起来。

那么，具体的规则是什么呢？继续往下看。

focus / disabled / required 这些属性必须真实存在

• disabled 必须是布尔属性——可以写成 disabled 或 disabled="disabled"，但绝对不能使用 disabled="false"；只有移除该属性才能真正表示启用
• required 同理，它不依赖 aria-required="true" ——后者只是冗余补充，不能取代原生属性
• 用户点击 input 时触发的 :focus 是浏览器原生的行为，CSS 中不要用 .focused 覆盖它，除非你同时用 JavaScript 同步设置/清除 tabindex 并监听 focusin/focusout 事件

简而言之，能用原生属性解决的就不要折腾额外技巧。

验证失败时优先用 validity API + aria-invalid

手动在 input 上添加 class="error" 并弹出提示框，对键盘用户和屏幕阅读器来说几乎没什么效果。真正起作用的是浏览器内置的 validity 对象以及配套的 ARIA 属性。

• 调用 reportValidity() 触发原生校验气泡，比自己编写提示信息更一致可靠
• 校验失败后，必须同步设置 aria-invalid="true"，否则屏幕阅读器不会播报错误
• 错误文案要通过 aria-describedby 关联到具体的 input，且对应的元素 id 必须存在、非空且唯一
• 不要只修改样式（比如红色边框），aria-invalid 和 aria-describedby 缺一不可

这里有一个关键点：样式只是“看起来像”，而属性才是“实际上就是”。

readonly 和 disabled 的语义差异不能混用

两者视觉效果可能相似，但语义和行为完全不同：前者仍然可以聚焦、复制文本、提交值；后者则完全被表单忽略、无法聚焦、不参与序列化。

• 密码确认字段临时锁定？使用 readonly 加上附加说明文案，而不是 disabled ——否则提交时该字段的值会变为空
• 灰色下拉框如果只是暂时不可选，但需要保留当前选中值并参与提交，那么必须用 readonly（select 不支持 readonly，需要换一种思路：通过 pointer-events: none 样式，保留 value，并显式设置 aria-disabled="true"）
• disabled 的控件不会出现在 FormData 或 form.elements 中，这是硬性规则，不是可以配置的选项

最容易忽略的点：状态变更必须原子化同步。例如禁用一个按钮时，关联的 input 是否也同步设置为 disabled？所有 aria- 属性与 DOM 属性是否严格一致？只要缺少一个属性，就会断掉一条辅助技术的路径。这就像搭积木，少一块，整个结构就不稳定。