动态列表加载时屏幕阅读器没反应，主因是缺失aria-live或配置错误；须在初始HTML中为最小父容器设aria-live="polite"/"assertive"，配合role="status"/"alert"、aria-busy及焦点管理。
动态列表加载时屏幕阅读器没反应？先检查 aria-live
动态插入内容（比如搜索结果、无限滚动列表）后屏幕阅读器沉默，大概率是缺 aria-live 或用法不对。它不是“加了就朗读”，而是要匹配内容更新的语义强度和节奏。
常见错误现象：用户提交搜索后页面刷新了列表，但屏幕阅读器没提示“找到 12 条结果”；加载中只显示转圈图标，键盘用户不知道状态变化。
-
aria-live="polite"最常用：等当前语音说完再播报，适合搜索结果、评论追加等非中断性更新 -
aria-live="assertive"少用：立即打断当前朗读，仅用于错误提示、登录成功这类强通知 - 别给整个列表容器设
aria-live，而应设在**承载新内容的最小父节点**上（如<div id="list-results">），否则可能重复播报旧项 - 避免在
aria-live区域内混用aria-hidden="true"子元素——它会干扰播报范围
无限滚动列表怎么让屏幕阅读器知道“正在加载更多”
滚动触底自动加载时，若只靠视觉 loading 指示器，屏幕阅读器用户完全感知不到状态。必须把“加载中”变成可访问的语义节点。
使用场景：新闻流、商品瀑布流、聊天记录加载更多。
立即学习“前端免费学习笔记（深入）”；
- 在列表末尾插入一个
<div role="status" aria-live="polite">正在加载更多内容…</div>，加载完成立刻移除或替换为新条目 - 不要用
display: none或visibility: hidden隐藏加载提示——它们会让该节点彻底退出可访问性树 - 如果加载失败，把该节点内容改为
加载失败，请点击重试并加role="alert"，确保被立即识别为错误 - 避免用
tabindex="-1"+focus()强行聚焦加载提示——它不属于导航流，且会打断用户当前操作
动态插入的列表项缺少语义？用 DocumentFragment + 正确 heading 结构
JS 直接 innerHTML 插入一堆 <p> 或无序 <li>，会导致大纲断裂、标题层级错乱、屏幕阅读器无法识别区块边界。
性能与可访问性影响：DOM 节点无结构，辅助技术需反复回溯推导上下文，响应延迟明显；SEO 也弱化内容权重分配。
- 每次插入新区块，优先用
DocumentFragment构建，包裹在<section>内，并带合法<h2>或<h3>（取决于上下文层级） - 避免跳级写 heading：比如主列表用
<h2>，新增项不能直接塞<h4>，应统一用<h3>或由<section>重置为<h2> - 对纯文本列表项（如标签云、搜索建议），用
<ul><li>而非<div>堆砌——前者自带列表语义，支持屏幕阅读器快捷键（如 NVDA 的 L 键） - 如果新增项含交互控件（如“删除”按钮），确保每个
<li>有唯一 ID，并用aria-labelledby关联其描述性文本
加载后焦点没管理好？别默认 focus 到列表顶部
动态加载完新内容，直接 element.focus() 到列表容器，往往让用户迷失：“我刚才在看第 5 条，怎么跳回开头了？” 焦点管理必须尊重用户意图。
容易踩的坑：在无限滚动中每次加载都 focus 到新插入的第一项；模态框关闭后 focus 回到 <body> 而非触发按钮。
- 加载新内容后，**不主动转移焦点**是安全默认——除非用户明确执行了“搜索”“筛选”等动作
- 若必须引导焦点（如搜索后跳转到结果区），用
tabindex="-1"+focus()定位到结果容器，并配合aria-label="共找到 8 条匹配结果，按 Tab 键开始浏览" - 避免对整个列表设
tabindex="0"：它会让键盘用户被迫按十几次 Tab 才能离开，破坏导航效率 - 记住：原生可聚焦元素（
<a>,<button>,<input>）天然进入 Tab 流，无需额外加tabindex
