播报的紧急程度需要分级，非关键更新不应打断用户当前操作
别名: polite · assertive · 紧急程度 · 播报分级
概念解释
同样需要被听见的更新，不必同样立刻插进正在说的那句话。礼貌度（aria-live politeness）把推送分成档：off 不推，polite 等当前句子说完再念，assertive 清掉队列立刻念。role="status" 落在 polite 一侧，role="alert" 落在 assertive 一侧。分级问的是：这条事实值不值得打断用户正在听的操作说明、正在填的字段回读。非关键更新挤进 assertive，用户会丢了当前句，也丢了在表单里的位置。
这与「live 贴错容器」不同。容器可以对、属性可以合法，档位仍然选错。
机制
阅读器维护一条语音队列。polite 入队；assertive 把未说完的内容丢掉或挂起。人的工作记忆装不下「半句说明 + 一条角标 + 正在输入的标签」。打断的代价不是多听几个字，是当前任务的听觉上下文被切断，恢复要重新找焦点、重听标签。
第二层是「关键」的判据：若用户此刻不听见就会做错且无法轻易撤销，才配 assertive——支付失败、会话即将过期、焦点在别处时出现的提交错误。结果条数、草稿已保存、别人正在输入，晚一句不会造成不可逆损失，应排队。没有中间档可以表达「比较重要但不许打断」，硬塞进 assertive 是在用唯一的打断通道当音量旋钮。
怎么研究
让被试在阅读器里读一段操作说明或填多步表单，同时注入两类更新：关键（提交失败）与非关键（已保存、在线人数）。三档礼貌度交叉。因变量用「当前字段是否填错」「是否要求重听说明」「自报被打断的次数」，不要用满意度。NVDA 与 JAWS 对 polite 的排队延迟不同，同一脚本两边都要跑。
自变量：礼貌度、更新是否不可逆、用户是否正处在输入中。 因变量：任务错误、被刷新掉的语音、恢复位置所花按键。
边界
有的移动阅读器几乎不播 polite，作者为了「听见」把什么都升成 assertive，分级在那种环境里会塌成一档。用户可以把提示强度拧到最低，assertive 也会被吞，不能把产品正确性押在「alert 一定能打断」上。实时协作里「别人选中了格子」对操作者是关键、对旁观者不是，同一条更新的档位随角色变。语音正在念长描述时，连真正的 assertive 也会显得粗暴，需要把长描述做成可暂停，而不是把紧急消息降成 polite 混过去。
怎么落地
- 先列一张表：每类动态消息是 polite 还是 assertive，默认 polite；只有不可逆风险才进 assertive。
- 成功、保存、计数、在线状态用
status/polite；错误且焦点不在该字段上时才用alert。 - 不要用 assertive 当「确保能听见」的万能开关。
- 验证：戴耳机填完表单，期间让保存提示和一条真正的提交错误先后出现。保存提示插进正在读的标签，或错误被排到用户已经离开之后才念，都是档位错了。