最常见原因是只改视觉状态而未设置aria-invalid属性；必须用JavaScript显式设为字符串"true"/"false"，并配合aria-describedby指向可访问的错误提示元素。
aria-invalid 为什么没被读屏软件读出来
最常见原因是只改了视觉状态（比如加 class 或显示红字），但没动 aria-invalid 属性本身。读屏软件（NVDA、VoiceOver、JAWS）只认这个属性，不认 CSS 类、data- 属性或自定义事件。
它必须是真实 DOM 属性，且值只能是字符串 "true" 或 "false" —— 写成布尔 true、数字 1，或留空，都会让读屏软件忽略。
- 校验失败时：必须执行
input.setAttribute('aria-invalid', 'true') - 校验通过时：必须执行
input.setAttribute('aria-invalid', 'false')（不能用removeAttribute，否则某些读屏会当成“未定义状态”，不播报） - 如果用了
setCustomValidity，它不会自动同步aria-invalid，得手动补上
怎么让读屏软件连错误原因一起读出来
单独设 aria-invalid="true"，读屏最多报“编辑框 无效”，不会说“邮箱格式不对”。要让它连着读，必须配对使用 aria-describedby 指向错误提示元素的 id，且该元素需可访问。
- 错误提示元素（如
<div id="email-error"></div>）不能是display: none或visibility: hidden，否则读屏直接跳过 - 推荐加
role="alert"或aria-live="assertive"，确保动态插入时能主动播报 -
aria-describedby的值必须和提示元素的id完全一致（大小写、拼写、有无前缀都不能错） - 不要用
aria-errormessage替代——它在旧版 JAWS 和部分移动 VoiceOver 中支持不稳定，aria-describedby兼容性更稳
blur 或 input 事件里更新状态容易踩什么坑
实时校验常绑在 blur 或 input 上，但状态更新节奏一乱，读屏就会漏报或误报。
立即学习“前端免费学习笔记（深入）”；
- 在
input事件里频繁插入/删除提示元素，DOM 变动太猛，读屏可能卡住或跳过；建议复用同一个提示元素，只改textContent和显隐 class - 校验异步（如用户名唯一性检查），不能在请求发出去就设
aria-invalid="true"，得等响应回来再判断并更新 - 表单重置（
<button type="reset"></button>）不会触发change或input，必须手动监听reset事件，并重置aria-invalid和提示内容 - 如果用了
requestAnimationFrame延迟聚焦或更新 DOM，aria-invalid必须在同一次帧内设置，否则读屏可能读到中间态
原生校验（required / type="email"）后怎么同步 aria-invalid
浏览器原生验证不会自动设 aria-invalid，哪怕 :invalid 伪类生效了，读屏也完全不知道。
- 提交时拦截
submit事件后，对每个字段调用input.checkValidity()，它会触发:invalid样式，同时返回布尔值供你判断 - 根据返回值，手动设
input.setAttribute('aria-invalid', checkValidity() ? 'false' : 'true') - 别依赖
form.checkValidity()—— 它只返回整体结果，不更新单个 input 的伪类或 ARIA 属性 - 用户修改后，要再次调用
checkValidity()并同步更新，不能靠“输入后自动清掉”这种假设
真正难的不是加属性，而是让所有状态（视觉、DOM、ARIA、焦点、读屏播报）始终同频。哪怕 aria-invalid 写对了，只要 aria-describedby 指向的元素被 CSS 隐藏、ID 不匹配、或没加 role="alert"，读屏就只会报“无效”，然后沉默。
