H3.11.1proactive screen reader error announcement设计研究
错误信息出现时需要主动播报给屏幕阅读器用户
别名: 错误播报 · live region error · 主动朗读
概念解释
错误若只画在屏幕上，屏幕阅读器用户的焦点可能还在别处，这条红字对他们等于不存在。主动播报指错误进入界面时，辅助技术要在不靠用户自己碰到该节点的情况下把消息读出来。这条只管「要开口」，不管颜色够不够、时机会不会打断输入、句子要具体到什么程度。
机制
视觉用户靠突变（变红、出现横条）捕获注意；屏幕阅读器走的是焦点和线性浏览，突变默认不进那条通道。人提交后仍停在按钮上，错误写在字段下或页顶，若不进入实时区域或焦点不移过去，朗读内容还是按钮本身，「失败」从未发生。主动播报把错误当成状态变化送进辅助技术，恢复流程才对这条通道开始。没有这一送，三要素写得再完整也只存在于视觉层。
怎么研究
用屏幕阅读器走提交失败任务，比较：只改视觉、焦点移到错误、用实时区域播报。
自变量：错误出现后焦点是否移动、是否有状态消息被辅助技术接收。 因变量：用户是否知道发生了失败、发现第一条错误的时间、是否以为提交成功。
被试若是视觉阅读器用户，会「看见」错误而听不见问题。主样本应是日常使用屏幕阅读器的人，任务里不要把错误写进实验说明。
边界
已经把焦点移到首个错误字段且该字段的错误被作为名称或描述读出时，可以不再额外播报一遍，避免双通道抢话。静默、自动恢复且无用户后果的失败不应播报。一次性的确认成功反馈也走状态消息，但不要和错误共用同一紧急程度，否则成功和失败听起来一样响。
怎么落地
- 提交失败时要么把焦点移到第一条错误并保证它被读出，要么把摘要送进状态消息；两条至少做一条。
- 动态插入的错误节点要能被辅助技术在当前焦点下接收，而不是只存在于未走过的 DOM 里。
- 用真实屏幕阅读器走一遍主失败路径，不要只靠自动检查「有没有标记」。
- 验证：闭上屏幕，只听。提交失败后若下一句仍是按钮名或一片安静，播报就没有发生。