aria-live容器必须在页面初始HTML中声明，不能动态添加；需配合aria-atomic="true"和sr-only类，通过textContent更新内容触发屏幕阅读器播报。
aria-live 必须在页面加载时就存在
表单提交成功后只用 innerHTML 插入提示文字，屏幕阅读器大概率不会朗读——因为 aria-live 属性必须在 DOM 初始渲染时就挂载，后期 JS 动态添加该属性（比如 el.setAttribute('aria-live', 'polite')）会被 NVDA、JAWS、VoiceOver 等主流读屏软件忽略。
正确做法是把容器直接写进 HTML 模板顶部，例如：
<!-- 必须在初始 HTML 中声明，不能靠 JS 创建 --> <div id="form-feedback" aria-live="polite" aria-atomic="true" class="sr-only"></div>
.sr-only 类需确保视觉隐藏但保留可读性（不能用 display: none 或 visibility: hidden）；aria-atomic="true" 保证整段消息被完整播报，避免只读出部分更新。
不要用 display: none / block 切换提示区域
常见错误：给一个 div 设 display: none，提交成功后切为 block 并填入文字。这种 DOM 不变、仅样式切换的方式，读屏器完全感知不到内容变化。
立即学习“前端免费学习笔记（深入）”；
必须依赖 aria-live 容器的文本内容变更来触发播报。实操要点包括：
- 初始 HTML 中该容器内必须为空（或仅含空格），不能预填“提交成功”之类文字
- JS 更新时只改
textContent或innerText，不要用innerHTML = ""清空再重写——清空操作会移除aria-live属性，后续插入内容不再触发播报 - 若需支持多条连续提示（如“保存中→已保存→网络异常”），每次更新前先清空内容再写入新文案，而非追加
polite 和 assertive 的选择取决于语义强度
成功提示绝大多数场景用 aria-live="polite" 就够了。它等用户当前朗读自然结束再播报，不打断操作流。只有极少数情况需要 assertive：
- 表单提交失败且需立即中断用户（如“银行卡号校验失败，请重试”）
- 涉及安全或数据丢失风险的操作结果（如“撤销操作不可恢复”）
滥用 assertive 会导致频繁插话，反而降低可访问性。注意：role="status" 通常配 polite，role="alert" 才配 assertive，二者语义绑定，别混搭。
焦点管理与 JS 状态同步容易被忽略
成功提示本身不是焦点目标，但用户可能刚提交完表单，正等待反馈。此时若页面无焦点移动，仅靠 aria-live 是唯一通路——这也是为什么它不能靠 JS 动态创建。
更关键的是：如果表单提交后 JS 修改了其他元素状态（比如禁用提交按钮、重置输入框），这些变更也必须同步 ARIA 属性：
- 按钮设
disabled后，确保aria-disabled="true"也存在（原生disabled已足够，但自定义控件必须手动同步） - 输入框清空后，若之前有
aria-invalid="true"，要一并设回"false" - 避免在同一个元素上同时写
aria-live和aria-hidden="true"——后者会强制屏蔽前者
最常被跳过的动作是：提示文案更新后没检查容器是否仍保有 aria-live 属性。DOM 替换、框架 re-render、甚至某些 CSS 动画过渡都可能导致该属性意外丢失。
