aria-invalid必须加在表单控件本身（如input、select、textarea）上；取值为"false"、"true"、"grammar"、"spelling"，常规验证仅用前两者；需配合aria-describedby指向错误消息id才能完整传达错误原因。
aria-invalid 应该加在哪个元素上
必须加在触发验证的表单控件本身，比如 <input>、<select></select> 或 <textarea></textarea>，而不是它的 label、包装 div 或错误提示容器。加错位置会导致屏幕阅读器无法关联到具体出错字段。
常见错误：把 aria-invalid="true" 放在 <div class="error">邮箱格式不正确</div> 上——这毫无语义作用，AT（辅助技术）根本不会读它和输入框的关系。
- 正确：
<input type="email" aria-invalid="true" aria-describedby="email-error"><div id="email-error">邮箱格式不正确</div> - 错误：
<div aria-invalid="true"><input type="email"></div> - 错误：
<div id="email-error" aria-invalid="true">邮箱格式不正确</div>
aria-invalid 的取值有哪些，分别代表什么
aria-invalid 是布尔型 ARIA 属性，但实际支持 4 种字符串值："false"、"true"、"grammar"、"spelling"。浏览器只认字符串，不能写成布尔字面量 true 或 false。
绝大多数表单验证场景只需用 "true" 或 "false"；"grammar" 和 "spelling" 主要用于富文本编辑器中由拼写/语法检查引擎标记的错误，普通表单不用。
-
aria-invalid="true"：字段内容未通过业务规则校验（如必填、邮箱格式、密码强度） -
aria-invalid="false"：字段当前通过验证（注意：不是移除属性，而是显式设为"false"，否则 AT 可能沿用旧状态） - 不要写
aria-invalid（无值）或aria-invalid=""，行为不可靠
为什么必须配合 aria-describedby 才算完整
aria-invalid="true" 本身只告诉 AT「这个字段错了」，但不说明「哪里错、为什么错」。用户仍需手动探索附近内容才能理解错误原因——这对视障用户是严重障碍。
必须用 aria-describedby 指向具体的错误消息元素 ID，让 AT 自动朗读该消息。且错误消息元素需满足：存在、可见（或至少 aria-hidden="false"）、文本内容明确。
- 错误消息元素应有唯一 ID，并与
aria-describedby值严格匹配（大小写敏感） - 避免用 CSS
display: none或visibility: hidden隐藏错误消息——AT 会跳过它们；改用opacity: 0; position: absolute; clip: rect(1px, 1px, 1px, 1px);等可访问隐藏方式 - 若错误消息动态生成，确保 ID 在插入 DOM 后立即可用，不要等动画结束才挂载
JavaScript 动态更新时容易忽略的细节
前端验证常在用户失焦（blur）或提交时设置 aria-invalid，但很多人忘了同步处理两种状态切换的边界情况。
- 清空输入后未重置：用户删掉错误内容，但
aria-invalid="true"还挂着，AT 仍报错——应在每次校验后**显式写入**"true"或"false" - 异步验证未等待完成：例如邮箱唯一性校验走 API，
aria-invalid在请求发出时就设为"true"，但实际可能无冲突——应只在确认失败后设置，成功时设为"false" - 多个验证规则共存时，不要简单覆盖：比如先校验非空（失败 →
aria-invalid="true"），再校验邮箱格式（成功），但用户又删了内容——需重新评估所有规则，再决定最终值
最稳妥的做法是封装一个 setFieldValidity(field, isValid, errorMessage) 函数，统一管理属性、描述关系和视觉反馈，避免状态散落在各处。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
