表单交互状态的语义化维护要求所有状态（如聚焦、禁用、验证失败）必须通过原生 HTML 属性（如 disabled、required、aria-invalid）真实表达，而非仅依赖 CSS 类或 JS 变量；disabled 和 required 必须为布尔属性，移除才代表启用；验证失败需结合 validity API、aria-invalid 和 aria-describedby 确保可访问性；readonly 与 disabled 语义不同，不可混用；状态变更须原子化同步，确保 DOM 属性与 ARIA 属性严格一致。

表单交互状态的语义化维护，核心是让每个状态变化（如聚焦、禁用、验证失败）都通过原生 HTML 属性表达，而不是仅靠 CSS 类或 JS 变量“假装”有状态。

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

很多项目用 class="is-focused" 模拟聚焦态，但屏幕阅读器和浏览器原生表单逻辑只认 focused 的 DOM 状态或 disabled 属性。一旦 JS 失效或辅助技术绕过样式，这些“伪状态”就完全失效。

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

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

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

anything-to-html

将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。

下载

• 调用 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 属性严格一致。差一个属性，就断掉一条辅助技术路径。