tabindex 用于声明聚焦意图而非防聚焦；给非交互元素加 tabindex="0" 会制造无障碍陷阱，而 tabindex="-1" 配合 aria-hidden="true" 可安全阻断意外聚焦，优先使用原生可聚焦元素。
tabindex 不是用来“防聚焦”的，而是用来声明聚焦意图的。给非交互元素（比如纯 div、span、图标容器）加 tabindex="0"，反而会制造无障碍陷阱——它不是补漏，是挖坑。
为什么给非交互元素加 tabindex="0" 是错的
键盘用户 Tab 到一个没行为、没语义的 div 上，焦点停住但按 Enter/Space 无反应，屏幕阅读器读作“无名容器”或直接跳过上下文，用户立刻迷失。这不是“多一个入口”，是多一次无效停靠。
- 常见错误：给
<span class="icon-close"></span>加tabindex="0"，却没配role="button"和keydown监听，结果键盘用户卡在空图标上 - 更隐蔽的问题：多个同类装饰性
span都加了tabindex="0"，Tab 流被切成碎片，用户要按十几次才能到下一个真实控件 - React/Vue 中动态渲染时，这类“伪可聚焦”元素可能在 hydration 后顺序错乱，焦点跳转不可预测
tabindex="-1" 不是“隐藏开关”，但能阻断意外聚焦
如果某个非交互元素因 CSS 或 JS 临时出现在 DOM 中（比如动画中位移的遮罩层、未完成加载的占位符），又不能删掉它，tabindex="-1" 是唯一安全的“暂停键”——它让元素不进 Tab 流，也不影响子元素（只要子元素没被父级 aria-hidden 或 inert 拦截）。
html-to-pptx-converter
下载
使用 PptxGenJS 和 Python 解析，将结构化的 HTML/CSS 幻灯片内容转换为原生、可编辑的 PowerPoint（.pptx）演示文稿。
- 必须配合
aria-hidden="true"使用：仅设tabindex="-1"不足以让辅助技术忽略它；若该元素纯属视觉装饰，应同时加aria-hidden="true" - 别给整个
section或article加tabindex="-1"：这会连带屏蔽内部所有按钮、链接，除非你明确控制子树焦点（如模态框根容器） - 现代替代方案：支持
inert属性的浏览器（Chrome 105+、Firefox 117+）可直接用inert，比tabindex="-1"+aria-hidden更彻底
真正该聚焦的，永远优先用原生元素
想让用户能 Tab 到“关闭”操作？直接写 <button type="button" aria-label="关闭">×</button>。它自带 tabindex="0"、Enter/Space 触发、disabled 语义、role="button"，CSS 重置即可，无需任何额外 tabindex。
立即学习“前端免费学习笔记（深入）”；
- 原生
button、a[href]、input等，绝对不要手动加tabindex="0"或tabindex="-1"——冗余且可能干扰 SSR/hydration - 若因设计限制必须用
div，那它就不是“按钮”，而是“按钮的视觉外壳”；真正的可聚焦、可交互节点应是其内部的button或a - 所有“防止意外聚焦”的努力，本质是回归语义：不该聚焦的，就让它不可聚焦；该聚焦的，就用对的标签
最常被忽略的一点：tabindex 的存在本身，就是一种语义承诺。加了，就得兑现角色、行为和样式；不加，就别指望键盘用户能碰得到——这不是技术限制，是信息契约。
