无障碍错误提示表单报错要让键盘和读屏都能跟上一、错误提示不能只变红表单错误提示常见做法是输入框变红下面出现一行文字。视觉用户能看到但键盘用户和读屏用户未必能及时知道发生了什么。无障碍表单需要把错误状态、错误文案和焦点关系连起来。错误提示的目标是让用户知道哪个字段错了、为什么错、怎么修正。颜色只是辅助不是完整反馈。二、错误状态要有语义关联flowchart TD A[用户提交表单] -- B[校验失败] B -- C[字段标记 aria-invalid] C -- D[错误文案关联] D -- E[焦点移动或摘要提示]字段有错误时可以设置aria-invalidtrue并用aria-describedby关联错误文本。这样读屏用户聚焦到字段时能听到错误说明。如果表单较长提交失败后可以把焦点移动到错误摘要或者移动到第一个错误字段。关键是不要让用户自己猜哪里出了问题。三、代码要建立关联input idemail aria-invalidtrue aria-describedbyemail-error / p idemail-error请输入有效的邮箱地址。/p错误文案要具体。不要只写“格式错误”应说明需要什么格式。若有多个规则优先提示当前最需要修正的一条避免一次性丢出太多信息。function getFirstError(errors: Recordstring, string) { return Object.keys(errors)[0] ?? null }提交后定位第一个错误字段是很实用的体验优化。键盘用户不用从页面顶部重新寻找。四、动态错误要避免打扰过度实时校验要谨慎。用户刚输入一个字符就反复报错会造成干扰。可以在字段 blur 后显示错误或提交后统一显示。对读屏用户过于频繁的 live region 更新也会打断输入。错误摘要适合复杂表单。顶部列出所有错误并提供跳转链接。每个链接跳到对应字段字段本身仍保留具体错误文案。摘要和字段级错误要互相配合。错误提示还要处理异步校验。用户名占用、验证码错误、接口超时等问题可能在用户离开字段后才返回。此时要确认字段值是否已经变化避免把旧请求的错误显示到新输入上。多字段关联错误也要设计。比如密码和确认密码不一致开始时间不能晚于结束时间。这类错误不能只挂在某一个字段上应在相关字段附近提供说明并让焦点路径合理。颜色对比仍然是底线。错误文本、错误边框和提示图标都要满足对比度要求。只用红色边框没有文本说明也不适合色觉差异用户。最后表单错误要进入自动化测试。提交空表单、输入非法格式、异步校验失败、键盘跳转到错误项都应覆盖。无障碍不是发布前手工点几下而是可回归的质量要求。错误提示还要支持摘要和字段双向联动。用户点击摘要中的错误项应跳到对应字段字段修正后摘要里的错误也要同步消失。否则摘要会变成过期信息。移动端输入也要注意。键盘弹起后错误提示可能被遮挡。页面应滚动到字段附近并保留足够空间显示说明。只在桌面端测试表单错误很容易漏掉这个问题。最后错误文案要避免技术内部词。不要把接口错误码直接暴露给用户而要转换成可操作说明。日志里保留错误码界面上告诉用户怎么修正。错误状态清除也要及时避免用户修正后仍被旧提示误导。五、总结无障碍表单错误提示要使用语义状态、错误文案关联、焦点管理和适度的动态反馈。颜色变化不能作为唯一提示。表单报错不是提醒页面自己“变红了”而是帮助所有用户快速理解问题并完成修正。