加载状态、错误提示等瞬时反馈若不进入播报区域会被完全跳过
别名: 瞬时反馈 · 加载播报 · 内联错误 · toast
概念解释
转圈消失了、红字闪了一下、toast 三秒后收走——看见的人靠那一小段时间完成了「正在保存 / 失败了」。阅读器若没在那一小段时间里接到文本，这次反馈对它就是零。瞬时状态播报（transient status announcement）指的是：加载、保存中、内联错误、超时提示这类很快被下一帧盖掉的反馈，必须进入播报区域（或把焦点带到错误上），否则会被完全跳过，不是「听得晚一点」。
它和「视图换了要通知」的差别是寿命。列表替换会留下来等人走；瞬时反馈不等人走，错过就没有第二份。
机制
瞬时反馈的设计目标是少占视觉注意力，所以寿命短、常不抢焦点。阅读器的采样却是离散的：焦点所在、虚拟光标所在、live 区域的突变。三者都不包含那句「保存中…」时，节点可以已经进树又被删掉，语音队列里从未出现过它。spinner 若只是 CSS 动画，连节点都没有。内联错误画在字段旁边但不进 aria-describedby、也不进 live、焦点仍留在提交按钮上，用户会以为提交没有反应，然后连点。
第二层是时序竞赛。从插入文本到阅读器开口有几十到几百毫秒；若节点在开口前被卸掉，有的引擎会取消这次播报。toast 的「三秒」对视觉够用，对排队在 polite 后面的语音可能不够。瞬时反馈因此必须在树上停留到被说出，或改成不那么瞬态的错误容器。
怎么研究
把保存做成 400ms 的视觉 spinner，一档只动画、一档把「保存中 / 已保存 / 失败」写入 status 区域并保持到说出之后。错误做成闪一下的红框 vs 写入字段的 describedby 并把焦点移回。遮屏提交，问「刚才发生了什么」。记录漏报、连点提交、以及错误文本是否能被再次找到。
自变量：反馈寿命、是否写入 live / describedby、是否移动焦点、polite 排队是否已有积压。 因变量：能否报告加载或错误、连点次数、错误在事后能否被重新读到。
边界
不确定时长的骨架屏如果只说一次「正在加载」然后沉默两分钟，用户会以为死机；需要周期性的仍在进行，但不能每秒报一次。焦点已经在该字段上、错误作为该字段名称或描述的一部分出现时，不必再 inflight 进全局 alert，否则会双念。验证码倒计时是瞬时数字流，进播报区会变成噪音，应改成可查询的剩余时间而不是每个数字都推。打印、下载开始若打开了系统对话框，系统自己会通知，页面再 toast 一次是重复。
怎么落地
- 加载与保存把短语写入一个稳定的 status 节点，等阅读器有机会说出后再清；不要只播动画。
- 字段错误写入该字段的描述，并把焦点送回第一条错误；不要只闪红框。
- toast 若必须用，复制同一句话进播报区，且在区内的停留长于视觉动画。
- 验证：关掉显示器提交一次成功、一次失败。听不到「保存中/失败」、或失败后无法再次读到原因，就是瞬时反馈只活在画面上。把网络调慢再试，确认短语没有在开口前被删掉。