能，但不能通过Tab键到达；tabindex="-1"允许脚本调用.focus()却排除在默认Tab顺序外，适用于模态框关闭按钮等需程序聚焦但不参与自然导航的场景。

tabindex 为负数时元素能被聚焦吗

能，但不能通过 Tab 键到达。这是最常被误解的一点：tabindex="-1" 的作用是“允许脚本调用 .focus()，但排除在默认 Tab 顺序之外”。比如模态框打开后自动聚焦到关闭按钮，又不想让用户按 Tab 就跳进去——这时候就用 -1。

常见错误现象：给按钮加了 tabindex="-1"，再用键盘 Tab 测试，发现完全跳过它，以为“失效”了；其实只是设计如此。

• 只在需要程序控制聚焦（如 element.focus()）但不参与自然导航流时用 -1
• tabindex="0" 是最安全的“加入默认顺序”方式，兼容性好，语义清晰
• 避免 tabindex="1" 或更高正数——会打乱 DOM 顺序，导致不可预测的焦点跳跃

原生可聚焦元素为什么有时不响应 Tab 键

因为它们被禁用了，或者父容器截断了焦点流。像 button、a[href]、input 这些原生可聚焦元素，默认有 tabindex=0，但一旦设置 disabled（如 <button disabled></button>），就会彻底退出焦点管理，连 .focus() 都无效。

另一个典型场景是 overflow: hidden + tabindex="0" 的子元素：滚动容器没设 tabindex，内部元素即使可聚焦，Tab 到它时页面可能不滚动，导致焦点“消失”在视口外。

立即学习“前端免费学习笔记（深入）”；

HTML Text Extract

从HTML页面（URL、文件或标准输入）中提取主体内容文本，去除导航、页脚、广告和模板文本。可直接传递给readability_check或其他文本工具。

下载

• disabled 状态下元素既不能鼠标点击，也不能被键盘聚焦
• 用 aria-disabled="true" 替代 disabled 可保留聚焦能力，适合需要键盘操作但逻辑禁用的场景
• 滚动容器若含可聚焦子项，建议自身也设 tabindex="0"，确保 Tab 过程中能滚动到位

如何让自定义组件（div）正确进入 Tab 顺序

加 tabindex="0" 是起点，但不够。光能聚焦不代表可交互——你得同时处理键盘事件，尤其是 Enter 和 Space，否则屏幕阅读器用户和键盘用户会卡住。

比如一个用 <div role="button"> 模拟的按钮，只加 <code>tabindex="0"，按空格没反应，就是半残废。

• 必须配 role 属性（如 role="button"、role="checkbox"）来声明语义
• 监听 keydown，对 Enter 和 Space 做相同触发（注意 Space 要 preventDefault()，否则会触发滚动）
• 加上 aria-pressed 或 aria-checked 等状态属性，让辅助技术感知当前状态

移动端 Safari 对 tabindex 的特殊限制

它默认只允许原生可聚焦元素获得焦点，除非用户主动点击过页面（即触发过“输入上下文”）。这意味着：纯靠 JS 设置 tabindex="0" 的 div，在未触屏前调用 .focus() 会被静默忽略。

这不是 bug，是 Safari 的主动保护策略。绕过方式有限，且都有代价。

• 首次加载后，引导用户轻点一下任意可聚焦区域（哪怕是个透明 input），之后 .focus() 才生效
• 用 contenteditable="true" 临时激活上下文（不推荐，副作用大）
• 更稳妥的做法：避免依赖自动聚焦，改用视觉提示 + 显式操作引导（如“点击此处开始”）

真正麻烦的不是怎么加 tabindex，而是不同浏览器对“谁该被聚焦”“什么时候能聚焦”的隐式规则不一致。尤其在混合使用 role、aria-* 和原生属性时，一个没对齐，焦点就悄无声息地掉进黑洞里。