HTML tabindex键盘导航优化

使用tabindex="0"有几个关键原则：

• 只用于有明确交互意图的元素：比如可点击的卡片、折叠面板的标题、标签页的切换按钮。别给纯装饰性的图标（如）加，否则屏幕阅读器会反复朗读无意义的内容，徒增干扰。
• 必须配套键盘事件：光能聚焦还不够，必须为它实现Enter键和Space键的响应逻辑，否则键盘用户聚焦后却无法“点击”，体验就断了。
• 与role属性协同：role="button"只告诉辅助工具“这是什么”，并不附带聚焦能力。tabindex="0"和恰当的role通常需要成对出现，才能构成一个完整的、可访问的交互元素。

tabindex="-1"：脚本聚焦的专用通道

tabindex="-1"的作用非常明确：禁止用户通过Tab键直接访问这个元素，但允许JavaScript通过.focus()方法将焦点强制设置给它。这是实现某些交互模式的刚需。

它的典型应用场景包括：

• 模态对话框：弹窗打开时，需要立即将焦点锁定在弹窗内的第一个可操作元素（如“确认”按钮）上，这个元素就应该设置tabindex="-1"。
• 展开面板：当一个折叠区域展开时，焦点应该被移动到其内部的第一个可交互子项，而不是面板容器本身。
• 管理隐藏区域：这里有个常见的坑。仅用aria-hidden="true"隐藏的区域，其tabindex行为不受影响，如果元素本身可聚焦，仍可能意外被Tab到。稳妥的做法是同时设置tabindex="-1"。同样，用opacity: 0或绝对定位移出视口的元素，只要还在DOM中，就可能干扰Tab流，也需要用tabindex="-1"或更现代的inert属性来禁用。

绝对不要使用正数 tabindex

这是一个需要反复强调的禁忌。浏览器默认按照HTML源码的先后顺序来构建Tab导航流。一旦你插入了tabindex="1"、tabindex="2"这样的正数值，就会强行将这个元素提到Tab顺序的最前面，完全打乱原有的自然流。

这会导致什么后果呢？焦点会开始“跳跃”，变得完全不可预测。当页面内容动态更新、组件被多次挂载时，整个Tab流甚至会彻底失控。对于依赖屏幕阅读器和键盘导航的用户来说，他们理解页面结构的依据就是文档流，人为打乱顺序，等于剥夺了他们理解页面上下文的线索。

记住几个实践准则：

• 导航栏在源码里排第一，就让它第一个被Tab到；主内容区紧随其后，不要因为它视觉权重高就强行给它设tabindex="1"。
• 侧边栏、页脚这些结构性的次要区域，在源码中靠后，在Tab流里自然也靠后，这是最合理、最可预测的顺序。
• 在服务端渲染（SSR）加水合（Hydration）的场景下，正数tabindex极易与服务端生成的DOM顺序冲突，导致焦点错位，调试起来非常棘手。

禁用与隐藏状态下的焦点管理

很多可访问性Bug，都出在开发者以为设置了tabindex就万事大吉，却忽略了元素当前的实际状态——它到底是可用的还是被禁用的？是可见的还是隐藏的？

处理这些状态时，有几个细节需要注意：

• 禁用状态：原生的会自动脱离Tab流，不需要额外处理tabindex。
• 隐藏状态：通过display: none或visibility: hidden隐藏的元素，即使设置了tabindex="0"，也不会被Tab到。但如前所述，其他隐藏方式（如透明度、定位）则不一定。
• aria-hidden 的误区：aria-hidden="true"只影响辅助工具的读取，不影响浏览器的焦点行为。如果一个元素同时有aria-hidden="true"和tabindex="0"，它依然可以被Tab到，这就会产生矛盾。正确的做法是显式设置tabindex="-1"或直接移除tabindex。
• 考虑 inert 属性：对于现代浏览器（Chrome 105+、Firefox 111+），使用inert属性是更可靠的选择。它会递归地禁用整个元素子树的所有交互和焦点，比手动管理一堆tabindex="-1"要省心得多。

说到底，真正的难点不在于写对那行tabindex="0"或-1的代码，而在于在整个组件的生命周期里，持续地、正确地维护焦点逻辑：展开时焦点该去哪、关闭后焦点该回哪、出错时焦点该跳哪、移动端虚拟键盘弹出时如何保持焦点稳定……这些细节一旦出现疏漏，键盘用户的体验链条就会在最基础的一环断裂。可访问性不是一次性任务，而是一种需要贯穿始终的持续关注。