双重验证≠鼠标点+键盘按，必须分离测试：鼠标仅验视觉反馈，键盘须从新标签页开始全程禁鼠，检查Tab流、Enter/Space响应、焦点归属及动态内容可访问性。
不能只用鼠标点一遍再键盘按一遍就叫“双重验证”——鼠标操作会污染焦点状态，键盘测试必须从干净标签页开始，且验证点完全不同。
为什么鼠标+键盘一起测反而会漏掉关键问题
鼠标点击后，Chrome 会激活输入上下文，Safari 可能缓存 activeElement；此时再按 Tab，路径已不是用户首次访问的真实流。更危险的是：鼠标能点的元素，键盘可能根本 Tab 不到（比如没 tabindex="0" 的 div），但你根本不会意识到它不可达。
- 纯键盘测试必须从新标签页打开 → 立即按
Tab→ 全程禁用鼠标 - 鼠标验证只用于确认视觉反馈是否匹配（比如焦点落在按钮上时，
:focus-visible是否生效） - 若鼠标点某处能触发行为，但键盘 Tab 到同一位置却无响应，说明它缺
role、缺keydown监听，或被aria-hidden="true"意外拦截
DevTools 里怎么看“真可聚焦”，而不是“看起来有 outline”
视觉上的焦点框（outline）可能只是 CSS 假象；真正可聚焦，得看可访问性树里的两个布尔值。
- 打开 Elements 面板，选中目标元素 → 右侧切换到 Accessibility 标签页
- 重点看：
Focusable: true（能进 Tab 流）和Focused: true（此刻确实获得了焦点） - 若
Focusable: false，优先排查：disabled属性、父级inert、display: none、或aria-hidden="true" -
outline: none不等于不可聚焦——但若没补:focus-visible，键盘用户就真的“看不见焦点在哪”
键盘验证必须检查 Enter/Space 是否真触发，而不是只看 click
键盘用户不“点击”，他们按 Enter 或 Space。只监听 click 事件，等于对键盘用户关闭入口。
立即学习“前端免费学习笔记（深入）”；
- 自定义按钮（如
div role="button"）必须监听keydown，不是keyup - 判断条件用
event.key === 'Enter'或event.key === ' '（注意是空格字符） - 按
Space时务必调e.preventDefault()，否则页面会向下滚动一屏 - 原生
button自动支持这两个键；加了tabindex="0"的div若没处理，屏幕阅读器会报“不可操作”
鼠标验证要盯住“焦点归属”而非“能不能点”
鼠标点开下拉菜单后，焦点是否还在触发器上？模态框关闭后，焦点有没有回到“编辑”按钮？这些才是鼠标操作暴露的深层问题。
- 模态框打开后，立即对第一个可操作项调
.focus()；若目标是div role="button"，它必须带tabindex="-1" - 关闭弹层时，焦点应回退到触发它的元素——不能靠
document.activeElement临时记录，因为鼠标点击后它可能已被重置 - 滚动容器（如卡片列表）若鼠标滚到底部再点“加载更多”，键盘用户 Tab 到末尾却卡住，说明容器缺
tabindex="0"，无法触发自动滚动
最常被忽略的点：动态插入的内容（如表单错误提示、搜索建议）在键盘用户眼里是“静默”的——NVDA 不会主动读，除非你加 role="alert" 或 aria-live="polite"，且该元素必须在 DOM 中可见、未被 aria-hidden="true" 掩盖。
