tabindex="1"不会让元素“第一个被tab到”，而是将所有正整数tabindex元素前置并按数值升序排列，导致焦点流错乱、wcag违规；正确做法是仅用tabindex="0"或"-1"。
tabindex="1"不会让元素“第一个被Tab到”，只会制造焦点流断层
浏览器对正整数 tabindex 的处理逻辑是：所有正数值（tabindex="1"、tabindex="2"、tabindex="50"）统一前置到整个 Tab 流最前面，再按数值升序排列；同值时回退到 DOM 顺序。结果不是“你排第几就第几个被聚焦”，而是“所有正数挤在开头，原生可聚焦元素（如 button、input）全被推到后面”。用户一进页面，Tab 键先落到页脚的“导出”按钮或弹窗里的“取消”按钮，主编辑区和导航栏反而要按十几下才出现——键盘用户瞬间丢失上下文。
多个组件复用时，正数 tabindex 让焦点顺序不可预测
当同一份组件代码被多次插入（比如 React 中 map 渲染多个卡片），每个都带 tabindex="1"，浏览器只取 DOM 中第一个生效，其余忽略；但 SSR 渲染时服务端生成的 DOM 顺序可能和客户端 hydration 后不一致，触发 React 警告甚至焦点跳转错位。更糟的是，CSS order 或 grid-template-areas 改变了视觉位置，但正数 tabindex 不会跟着变——屏幕阅读器仍按“正数升序 → DOM 顺序”走，而用户眼睛盯着右上角的标题，耳朵却听到左下角的按钮描述。
WCAG 明确禁止正整数 tabindex，它破坏的是语义结构而非仅导航体验
屏幕阅读器依赖文档流理解逻辑关系，tabindex="1" 强行把一个页脚操作按钮提到最前，等于告诉辅助技术：“这是页面起点”，但它既不是入口，也不承载首屏关键信息。这种人为插队造成认知断层，属于 WCAG 2.4.3（Focus Order）直接违反项。真实修复方式只有两种：tabindex="0"（让非原生元素可聚焦，且严格按 DOM 顺序进入流），或 tabindex="-1"（仅用于 JS 主动聚焦，不参与 Tab 流）。所有正数必须删除，不能“设了再说”。
视觉顺序与 DOM 顺序不一致时，正数 tabindex 是掩耳盗铃
有人用 float: right 把按钮视觉上推到右侧，又给它加 tabindex="1" 试图“匹配视觉”，结果是双重割裂：屏幕阅读器按 DOM 读出“按钮”时，用户眼睛还在找左边的表单标题；而 Tab 键确实先聚焦它，但后续焦点却按 DOM 继续往下，跳过中间所有内容。正确做法是改用 display: flex + justify-content: flex-end，保持 HTML 顺序不变——这样焦点流、朗读流、视觉流三者始终同步。正数 tabindex 解决不了布局问题，只掩盖了 HTML 结构缺陷。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
