tabindex="-1" 是让元素可聚焦但不进入自然 tab 顺序的唯一合规做法，支持通过 javascript 调用 focus() 获取焦点以监听键盘事件，需配合明确交互上下文和可访问性属性（如 aria-hidden、aria-label）使用。
tabindex="-1" 是让元素可聚焦但不进入自然 tab 顺序
想监听键盘事件又不让元素出现在 tab 流中，tabindex="-1" 是唯一合规做法。它不会改变 DOM 顺序，也不会被屏幕阅读器自动朗读（除非显式加 aria-hidden="false"），但能让元素通过 element.focus() 获得焦点，从而响应 keydown、keyup 等事件。
常见错误是设成 tabindex="0"——这会让元素进入 tab 流，破坏原有导航逻辑；或者设成 tabindex="999"——数值越大越靠后，但依然会进 tab 流，且容易被误认为“高优先级”而引发可访问性问题。
-
tabindex="-1"元素默认不可通过 Tab 键到达，但可通过 JS 主动调用.focus()聚焦 - 必须确保该元素有明确的交互上下文（比如模态框关闭按钮、快捷键触发区），否则键盘用户无法感知其存在
- 若元素本身不可见或
display: none，即使设置了tabindex="-1"，也无法接收键盘事件
监听前必须先让元素获得焦点（哪怕只是临时）
DOM 元素只有在聚焦状态下才会触发 keydown 等原生键盘事件。所以光写 element.addEventListener('keydown', handler) 不够——如果元素没焦点，事件根本不会冒泡到它身上（除非监听全局 document，但那不是“元素级监听”）。
典型场景：一个悬浮工具栏按钮，支持按 Esc 关闭，但它默认不聚焦。你需要在它显示时立刻 focus()，否则用户按 Esc 没反应。
const toolbar = document.getElementById('toolbar');
toolbar.tabIndex = -1;
toolbar.addEventListener('keydown', (e) => {
if (e.key === 'Escape') {
toolbar.hidden = true;
}
});
// 显示时立即聚焦，让用户能直接按键操作
toolbar.hidden = false;
toolbar.focus(); // 关键一步
用 focusable + aria-hidden 配合避免可访问性陷阱
仅设 tabindex="-1" 不足以保证无障碍体验。如果该元素不是主动交互入口（比如纯视觉快捷键区），需配合 aria-hidden="true" 告知辅助技术忽略它；但如果它是功能入口（如“按 Enter 打开菜单”），则应保留 aria-hidden="false" 并提供 aria-label。
-
aria-hidden="true"会屏蔽整个子树，即使子元素有tabindex="0"也无效 - 不要给
tabindex="-1"元素加role="button"却不处理Enter/Space，这违反 ARIA 实践 - 移动端 Safari 对
tabindex="-1"元素的focus()支持不稳定，建议加outline: none后手动管理视觉焦点样式
替代方案：监听 document 但过滤目标元素
当“无焦点元素键盘监听”只是表象需求，实际要的是“某区域快捷键”，更健壮的做法是监听 document，再用 e.target 或 event.composedPath() 判断是否在目标容器内：
document.addEventListener('keydown', (e) => {
if (!e.target.closest('#my-panel')) return;
if (e.key === 'ArrowUp') {
// 只在 #my-panel 内部按键时生效
}
});
这种方式绕过聚焦限制，适合快捷键全局注册，但要注意：不能替代真正的焦点管理——比如需要支持 Tab 导航到其中控件时，仍得用 tabindex 和 proper focus flow。
真正难的不是加 tabindex，而是判断这个元素“该不该有焦点”、以及“什么时候该拿到焦点”。很多 bug 来自忘记在状态变更后重置焦点，比如弹窗关闭后没把焦点还给触发按钮。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
