过于频繁的动态播报会造成信息过载，效果等同于噪音
别名: 播报过载 · live region noise · 进度播报
概念解释
每一条更新都可以是「该通知的事实」，合在一起仍能把语音通道堵死。播报过载（announcement flooding）指的是频率把通知变成噪音：进度每 1% 念一次、搜索建议每个按键念一遍、协作光标每次移动都报名字、行情每秒刷新。用户不是听不见，是无法从连续语音里再分出哪一句要据此行动。效果与没通知对称：通道被占满之后，真正关键的那句也被冲掉。
档位可以全是 polite，容器也可以很小。过载问的是单位时间内的条数，不是贴错属性。
机制
语音是时间里的单通道。一条短句占一两秒；每秒一条就没有空隙完成主任务的回读。阅读器对 live 的合并策略有限：有的把短间隔突变拼成一次，有的几乎条条都念。作者按「每次变化都诚实」去写，阅读器按「每次突变都是候选」去读，诚实变成连射。
第二层是掩蔽。队列有上限，新的 polite 会挤掉还没说的旧 polite；持续过载时，那条偶尔出现的错误会排不上或被下一条进度顶掉。过载因此不只是烦人，它会把分级体系打穿：assertive 的紧急句在连射里也只是多一声。用户的对策是把阅读器提示拧到最低，于是连合法通知也被关掉——产品用频率把自己的通道毁了。
怎么研究
同一任务（填写搜索框、看上传进度）跑三种频率：每个事件都念、按时间节流（例如 2 秒最多一次）、只念边界（开始/结束/失败）。记录主任务完成时间、漏掉的关键句、用户是否关掉阅读器提示。再加一档：过载进行中插入一条真正的错误，看它能否被报告。
自变量：事件频率、是否节流、是否只报边界、礼貌度。 因变量：关键句检出、任务时间、提示设置是否被用户调低、错误是否被进度淹没。
边界
短促的一次突发（五条相关通知在同一秒到达）和长时间的稳态过载机制不同：突发可以被合并成一句摘要；稳态必须改数据源。盲文点显器一次只能上很少字符，同样的频率在点显上比语音更不可用。用户把语速开到很高时，过载的可容忍条数上升，但不能按极速用户来设计默认。游戏、音乐类应用本身就在用声音，再叠加阅读器连射会和音效抢通道，需要产品级的「静音动态播报」。
怎么落地
- 进度类只报开始、里程碑（如 50%）和结束，不要每个百分点击发。
- 输入建议、字数、协作光标按时间窗合并，窗内只留最新一条。
- 过载期间的错误不要排在同一条 live 队列末尾，用独立的 assertive 区域，且该区域本身不得被进度写入。
- 验证：把上传或搜索开到会连续发事件的程度，戴耳机做完主任务。若中途无法回答「现在百分之几、有没有失败」，或不得不去关阅读器提示，就是频率已经等于噪音。把节流加上再跑一次，关键句应重新可被复述。