autofocus 失效因仅支持原生可聚焦元素且受浏览器策略限制；focus() 无播报需补全可访问名称和时机；焦点陷阱需手动管理 tab 流；视觉隐藏应避免 display/visibility，改用绝对定位裁剪。
autofocus 属性为什么没生效
页面加载后屏幕阅读器没聚焦到目标元素，大概率是 autofocus 被忽略或失效了。它只对原生可聚焦元素有效，且浏览器策略越来越严格。
-
autofocus仅支持<input>、<textarea></textarea>、<select></select>、<button></button>和带tabindex="0"的元素；<div> 或 <code><span></span>直接加autofocus无效 - 同一页面多个
autofocus时，多数浏览器只响应第一个，其余被静默丢弃 - SPA 路由跳转后，
autofocus不会自动重触发——它只在初始 HTML 解析阶段起作用 - 某些浏览器（如 Safari）在非用户手势触发的上下文中（如 iframe、后台标签页）会禁用
autofocus - 确保元素有明确的可访问名称：用
aria-label、aria-labelledby或原生<label for="id"></label>关联，否则屏幕阅读器可能只读“空白”或“按钮” - 避免在 DOM 尚未挂载完成时调用：React/Vue 中不要在
useEffect或mounted的同步回调里直接.focus()，改用requestAnimationFrame或setTimeout(() => el.focus(), 0)（后者兼容性略差） - 若目标是容器（如弹窗根节点），需先设
tabindex="-1"再.focus()，否则无法获得焦点；但注意：仅tabindex="-1"的元素不会出现在 Tab 流中 - 部分屏幕阅读器（尤其旧版 TalkBack）对非表单元素的
focus()不主动播报，必须配合aria-live="polite"区域触发通知 - 缓存弹窗内所有可聚焦元素：
const focusables = modal.querySelectorAll('button, input, select, textarea, [tabindex="0"]') - 监听弹窗容器的
keydown，仅拦截Tab键（不拦Shift+Tab以外的键，否则影响屏幕阅读器快捷键） - 当焦点在最后一个元素且按下
Tab时：event.preventDefault(); focusables[0].focus()；在第一个元素且按下Shift+Tab时：event.preventDefault(); focusables[focusables.length - 1].focus() - 别用
inert属性依赖——Chrome 107+ 支持，但 Safari 和旧版 Android WebView 不支持，需降级为aria-hidden="true"+ 手动移除tabindex -
display: none和visibility: hidden都会让元素彻底退出可访问树，aria-hidden="false"也无法恢复 - 真正安全的“视觉隐藏但可读”方案是：
position: absolute; clip: rect(0 0 0 0); clip-path: inset(100%); width: 1px; height: 1px; overflow: hidden; - 用
aria-hidden="true"时，务必确认父容器没有aria-live或焦点管理逻辑依赖该子元素；误用会导致屏幕阅读器静默丢失关键状态变更 - 装饰性图标必须用
alt=""或aria-hidden="true"，否则 TalkBack 可能读出“image”或空字符串，造成干扰
focus() 调用后屏幕阅读器没朗读
JavaScript 手动调用 element.focus() 成功了，但 TalkBack 或 NVDA 没播报，说明焦点虽已转移，但语义信息缺失或时机不对。
如何让键盘 Tab 不跳出弹窗边界
用户按 Tab 键从弹窗最后一个可聚焦项移出，焦点落到背景内容上，破坏焦点陷阱逻辑，也打断屏幕阅读器上下文。
隐藏内容但保持屏幕阅读器可读的陷阱
用 CSS 隐藏元素（如 display: none 或 visibility: hidden）常导致屏幕阅读器完全跳过，但有时你只想视觉隐藏、语义保留。
复杂点在于：焦点管理不是单点技术，而是 DOM 状态、可访问性属性、事件时机和屏幕阅读器行为的交叠区。最容易被忽略的是——你以为用户在“看”，其实他们是在“听+导航”，而你的 focus() 调用只是链条中的一环，缺了语义、时机或上下文，整条链就断了。
