Toast需用aria-live控制屏幕阅读器朗读，而非CSS或DOM操作；推荐role="status" aria-live="polite"作为默认配置，仅紧急场景用role="alert" aria-live="assertive"；textContent比innerHTML更安全；销毁前须确保朗读已触发。
用 aria-live 控制 Toast 是否被读、何时读
Toast 不是自动被屏幕阅读器感知的——哪怕它在视觉上弹出来了。关键开关是 aria-live，不是 CSS 显示/隐藏，也不是 JS 插入 DOM 的动作本身。
常见错误：只加 role="alert" 却漏掉 aria-live，结果读屏软件完全跳过；或者统一写 aria-live="assertive"，导致“复制成功”也打断用户正在听的长段落。
-
aria-live="polite"：适合状态类 Toast（如“已保存”“加载中”），等用户停顿再读，不打断操作流 -
aria-live="assertive"：仅用于真正需立即响应的场景（如“网络断开，请重试”），会中断当前播报 - 别设
aria-live="off"或不设——等于关闭可访问性通道
为什么 role="status" 比 role="alert" 更常用
多数 Toast 并非紧急错误，而是操作确认或中间状态。用 role="alert" 会触发 aria-live="assertive" 默认行为，容易造成干扰。
更稳妥的做法是显式组合：role="status" aria-live="polite"。这样既明确语义（非中断性状态更新），又避免依赖隐式规则。
立即学习“前端免费学习笔记（深入）”；
-
role="status"+aria-live="polite"：推荐作为默认配置 -
role="alert"+aria-live="assertive"：仅当用户必须立刻处理时才用 - 不要混搭，比如
role="alert" aria-live="polite"——语义冲突，部分读屏器行为不可靠
动态更新时，textContent 比 innerHTML 更安全
频繁替换 Toast 内容时，直接改 innerHTML 容易残留旧节点或触发 XSS 风险；而 textContent 能确保纯文本、无结构、无副作用。
尤其当 Toast 里含图标（<svg>）时，别把整个 HTML 字符串塞进去——先清空再注入，或改用带 aria-label 的内联 SVG，再用 textContent 更新文字部分。
- 正确做法：
toastEl.textContent = "上传完成"; - 错误做法：
toastEl.innerHTML = "<span>上传完成</span>";（可能引入未过滤内容） - 若必须保留 HTML 结构，先
toastEl.innerHTML = ""清空，再注入已转义的安全字符串
销毁 Toast 前必须保证朗读已触发
Toast 消失太快，屏幕阅读器可能根本没来得及读——尤其在 aria-live="polite" 下，它要等用户暂停输入或浏览完当前句才开始播报。
单纯靠 setTimeout(() => el.remove(), 3000) 不可靠：动画还没播完、读屏还没启动、甚至用户正聚焦在别处，都可能导致消息“发了但没读”。
- 保底策略：销毁延迟至少 4000ms（比默认 3000ms 多留 1s）
- 进阶做法：监听
animationend后再延后 500ms 移除，给读屏留缓冲 - 最保险：Toast 元素上加
aria-busy="true"，内容更新后设为false，配合aria-live触发时机
可访问性最难的不是“怎么让 Toast 出来”，而是“怎么让它被听见”。很多团队只测视觉动效，却忘了读屏用户根本看不到动画曲线——他们只依赖 DOM 变化和 ARIA 信号。一旦这两者不同步，提示就等于没发。
