tabindex="0"在所有现代浏览器及ie11中均支持聚焦，但需元素已渲染、未被隐藏或禁用；其与tabindex="-1"核心区别在于是否参与tab导航流，且必须配合role和aria属性才能具备可访问语义。

tabindex="0" 在 <div> 上能让它在所有现代浏览器中可聚焦，但有明确前提：元素必须已渲染、未被 <code>display: none 或 visibility: hidden 隐藏，且未被 disabled（该属性对 <div> 无效，但常误用于父容器）或 <code>pointer-events: none 干扰。

哪些浏览器支持 tabindex="0" 的聚焦行为

Chrome、Firefox、Safari、Edge（基于 Chromium 和旧版 EdgeHTML）全部支持。IE11 也支持，但存在两个关键限制：

• focus() 方法调用后，焦点可能不触发 focusin 事件（只触发 focus），需改用 focusin + focusout 监听冒泡事件
• 若 <div tabindex="0"> 父级设置了 <code>overflow: hidden 且当前不在视口内，部分 IE11 场景下 focus() 不会自动滚动到元素位置

  为什么有时加了 tabindex="0" 还是不能 Tab 到

  常见原因不是浏览器兼容性问题，而是 DOM 状态或样式干扰：

  

  Codearts代码智能体

  一款AI开发辅助工具，主要用于华为云Codearts平台推出的AI编码智能体，适合需要提升相关任务效率的用户。

  下载
  • 元素尚未插入文档（比如 React 中 useEffect 未等 DOM 挂载就调用 .focus()）
  • 父容器有 inert 属性（即使浏览器支持，也会阻断所有焦点）
  • CSS 中设置了 outline: none 且没提供替代焦点指示（视觉上“看不见”焦点，但实际已聚焦）
  • 页面有其他脚本监听 keydown 并调用了 e.preventDefault()，意外拦截了 Tab 导航

  tabindex="0" 和 tabindex="-1" 的实际区别

  二者都让 <div> 可通过 JS 聚焦（<code>.focus()），但导航行为不同：

  • tabindex="0"：参与 Tab 键顺序，按 DOM 位置插入标准流，屏幕阅读器可读取（前提是配 role 和 aria- 属性）
  • tabindex="-1"：不参与 Tab 流，只能靠 JS 主动聚焦；适合模态框关闭按钮、临时弹出菜单项等“非线性操作入口”
  • 错误用法：tabindex="1" 或更高正数——会打乱自然阅读顺序，且一旦漏设，原生可聚焦元素（如 <button></button>）会被排到最后

  最易被忽略的点：加了 tabindex="0" 只是“能聚焦”，不代表它具备语义。没配 role="button" 和 aria-label，屏幕阅读器只会读“可聚焦元素”，用户完全不知道这是干啥的。