aria-live 元素必须在初始 HTML 中写死，因读屏器仅在元素首次挂载时解析该属性；JS 动态创建并设置 aria-live 会被忽略；需用 textContent 更新内容，避免 innerHTML；polite 适用于过渡状态，assertive 仅用于需立即响应的错误。
页面加载状态提示必须在 HTML 初始结构中就存在，且不能依赖 JS 动态创建 aria-live 元素——否则 NVDA、VoiceOver 等主流读屏器根本不会监听它。
为什么 aria-live 必须写死在初始 HTML 里
屏幕阅读器只在元素首次挂载 DOM 时解析其 aria-live 属性。如果用 JS 创建一个 div 再 setAttribute('aria-live', 'polite')，绝大多数读屏器（包括 JAWS 2025+、NVDA 2026.1）会直接忽略该区域。
- 服务端渲染或静态 HTML 模板中，
<div id="loading-status" aria-live="polite" role="status" class="sr-only"></div>必须出现在<body>开头，紧邻<header>或跳转链接之后 - 不要用
document.createElement('div')+appendChild()初始化——哪怕加了aria-live，也大概率失效 -
class="sr-only"必须是视觉隐藏但读屏可见的样式（不能是display: none或visibility: hidden）
textContent 是唯一安全的更新方式
用 innerHTML = "加载中..." 替换整个内容，可能触发 DOM 重绘并中断读屏播报；而 textContent 只变更文本节点，兼容性更稳。
- 正确：
document.getElementById('loading-status').textContent = '正在提交表单...'; - 错误：
el.innerHTML = '<span>加载完成</span>';—— 标签会被剥离，且部分读屏器不识别变化 - 若需富文本（如带 icon 的提示），改用
el.append(...)插入已存在的 DOM 节点，而非拼接字符串
aria-live="polite" vs aria-live="assertive" 的实际分界
别把“加载中”设成 assertive——它会强行打断用户当前操作，反而造成干扰。真正需要 assertive 的，只有用户必须立即响应的错误，比如密码格式错误、网络断连等。
立即学习“前端免费学习笔记（深入）”；
-
polite：适合所有过渡性状态，如“加载中”“保存中”“正在验证邮箱”，读屏器会在用户暂停操作后播报 -
assertive：仅用于中断型反馈，且应配合role="alert"（不是role="status"） - 避免连续快速更新同一
aria-live区域——读屏器可能丢弃中间消息，只读最后一条
JS 加载失败时的兜底方案
如果 JS 完全不可用（禁用、超时、CDN 故障），纯 HTML 的加载提示就彻底失效。此时需靠语义化降级保障基础可访问性。
- 表单提交时，保留原生
<form action="/submit" method="POST">，让页面跳转本身成为“加载中”的视觉与语义信号 - 用
<progress>元素替代 div 模拟进度条，它自带语义和读屏支持（无需额外 ARIA） - 禁用按钮时，用
<button disabled>提交</button>，而非仅靠 CSS 灰掉 +aria-disabled="true"——前者浏览器自动处理焦点与读屏行为
最常被忽略的一点：加载提示容器自身不能有初始文本内容。如果 HTML 里写的是 <div aria-live="polite">准备就绪</div>，那“准备就绪”几乎不会被读出来——读屏器只对后续的 DOM 变化敏感，不是对初始值敏感。
