键盘焦点测试必须纯键盘操作并配合开发者工具验证，需检查焦点顺序是否符合DOM结构、可聚焦元素是否缺失tabindex或被禁用、滚动容器是否可聚焦、模态框焦点捕获与回退是否正确，以及视觉反馈是否完备。
能直接测，但必须用纯键盘操作、禁用鼠标，并配合开发者工具验证——光按 Tab 键不等于测出了焦点顺序，很多“跳过”其实是视觉错觉或可聚焦性缺失。
用纯键盘从头开始走一遍 Tab 流
打开页面后，先按 Tab 键，观察焦点是否落在预期的第一个可操作元素上（通常是 Logo 旁的导航链接、搜索框或主按钮）。之后持续按 Tab，注意以下几点：
- 焦点是否按 DOM 顺序前进，而不是按视觉布局（比如 Flex 排列的右上角按钮是否在左下角按钮之前被聚焦）
- 是否跳过某些明显可点击的
div或span—— 这往往不是 bug，而是它们没加tabindex="0"，或加了但没配role和事件监听 - 遇到
input、button、a[href]等原生可聚焦元素时，是否正常进入；若跳过，检查是否被disabled、aria-disabled="true"或父级inert拦截 - 按
Shift + Tab能否反向走，且路径完全对称
为什么焦点“消失”在滚动容器里
常见于卡片列表、侧边栏或模态框内部：焦点移到最后一个可见项后继续 Tab，页面没滚动，焦点像“不见了”。这不是焦点丢失，而是容器本身不可聚焦，导致浏览器无法自动滚动到下一个可聚焦子项。
- 给滚动容器（如
div class="list-container"）加上tabindex="0"，让它也能进 Tab 流，从而触发滚动行为 - 确保子项有
tabindex="0"或原生可聚焦属性，且没被display: none、visibility: hidden或opacity: 0（后者不影响聚焦）遮蔽 - 移动端 Safari 下，首次
Tab可能跳不过动态插入的div，需用户先点一下页面激活输入上下文
用 DevTools 快速验证可聚焦性
别只靠眼睛看焦点框有没有出现——outline: none 或 :focus-visible 样式缺失会让焦点“隐身”，但元素可能早已获得焦点。打开 Chrome / Edge 的 Elements 面板，选中目标元素，在右侧 Accessibility 标签页里确认：
立即学习“前端免费学习笔记（深入）”；
-
Focusable: true—— 表示该元素当前可被聚焦（tabindex有效、未被禁用、CSS 未隐藏） -
Focused: true—— 当前确实获得了焦点（可配合键盘操作实时观察） - 若显示
Focusable: false，优先排查：disabled属性、aria-hidden="true"、父级inert、或display: none - 检查
Computed面板中outline是否为none且未提供:focus-visible替代样式
模态框和弹窗最容易漏掉的两个动作
焦点跳出弹窗、关闭后焦点没回退，是键盘测试失败最典型的场景。这两个动作必须手动验证：
- 打开模态框后，焦点是否立刻落到第一个可聚焦子元素（如
button或input），而不是停留在触发按钮上 —— 若没发生，说明缺少element.focus()调用，或目标元素没设tabindex="-1"（非原生元素） - 按
Escape关闭弹窗后，焦点是否回到最初触发它的元素（比如“编辑”按钮）—— 若没回退，说明没缓存document.activeElement或没在关闭逻辑里调用.focus() - 在弹窗内连续按
Tab，焦点到达最后一个元素后再按一次，是否被拦截并跳回第一个？这是“焦点环（focus trap）”的核心逻辑，需 JS 主动监听keydown并event.preventDefault()
真正难的不是让某个元素能被 Tab 到，而是保证整个路径中每个环节都满足可聚焦性、语义、事件响应和视觉反馈四者同步——缺一不可。尤其当组件动态渲染、路由切换或 CSS 布局复杂时，DOM 顺序和视觉顺序的偏差会立刻暴露出来。
