如何通过document.activeElement高效追踪网页焦点元素，提升无障碍访问体验？

本文共计945个文字，预计阅读时间需要4分钟。

页面刚加载时，所有元素都消失或隐藏，或被卷入视窗之外。

实操建议：

• 不要直接对 document.activeElement 调用 .focus() 或读取 .aria-label，先做存在性判断：

  const el = document.activeElement;<br>if (el && el !== document.body && el !== document.documentElement) {<br> // 安全操作<br>}

• 监听 focusin 事件比轮询更可靠，尤其在单页应用中，路由切换后焦点可能未及时更新
• 若使用 Web Components，需注意 shadowRoot 边界：默认情况下 document.activeElement 不会穿透到 open shadow root 内部，得用 shadowRoot.activeElement

在 React 中安全读取 activeElement 并避免 useEffect 依赖错乱

React 函数组件内直接读 document.activeElement 没问题，但若放进 useEffect 且依赖了某个 ref 或 state，容易因渲染时机导致读到旧值或触发不必要的重运行。

实操建议：

• 用 useRef 缓存上一次焦点元素，仅在 focusin 事件中更新，避免每次渲染都查 DOM：

  const lastFocusedRef = useRef(document.activeElement);<br>useEffect(() => {<br> const handleFocusIn = (e) => {<br> lastFocusedRef.current = e.target;<br> };<br> document.addEventListener('focusin', handleFocusIn);<br> return () => document.removeEventListener('focusin', handleFocusIn);<br>}, []);

• 避免把 document.activeElement 放进 useEffect 依赖数组——它不是响应式值，且频繁变化会导致无限循环
• 服务端渲染（SSR）下首次执行时 document 不存在，必须加 typeof document !== 'undefined' 守卫

focusin vs focusout：为什么不用 focus/blur

focus 和 blur 事件不冒泡，而 focusin 和 focusout 会。这意味着你可以在 document 或某个容器上统一监听，无需为每个可聚焦元素单独绑定。

实操建议：

• 无障碍优化中常需「当焦点进入模态框时限制 tab 键范围」，用 focusin 监听最外层容器即可捕获所有内部焦点变化
• focusin 在目标元素获得焦点前触发，适合做焦点拦截（比如阻止焦点离开弹窗）；focusout 在焦点离开前触发，适合清理状态
• 注意 Safari 对 focusin 的兼容性：iOS 15.4+ 才完整支持，旧版需 fallback 到捕获阶段的 focus 事件

无障碍场景下判断「真正可访问的焦点元素」

document.activeElement 可能返回一个 input 或 button，但它未必对屏幕阅读器有效——比如缺少 aria-label、被 aria-hidden="true" 包裹、或父级有 inert 属性。

实操建议：

• 结合 el.matches(':focusable')（非标准但现代浏览器支持）或手动检查：el.tabIndex >= 0 || el.tagName === 'A' || el.tagName === 'BUTTON' 等
• 用 window.getComputedStyle(el).visibility !== 'hidden' && window.getComputedStyle(el).display !== 'none' 排除视觉隐藏但 DOM 仍在的元素
• 最关键是检查 el.getAttribute('aria-hidden') !== 'true' 且其任意父级也不含 aria-hidden="true"，否则 NVDA/JAWS 会跳过它

真实项目里，焦点管理最难的不是获取元素，而是确认它此刻是否「对辅助技术可见且可操作」——这需要组合 DOM 状态、样式、ARIA 属性三者判断，漏掉任一环都可能导致屏幕阅读器用户迷失。