C6.05.1Tab order matches reading order设计研究
Tab 顺序应与视觉阅读顺序一致
别名: 焦点顺序 · tabindex · 阅读顺序
概念解释
键盘用户用 Tab（和 Shift+Tab）在可聚焦控件之间移动时，走过的序列应当与眼睛在屏幕上的阅读顺序一致：通常是从左到右、从上到下，在从右到左的文稿里则跟随该文稿。若视觉上的下一步是右侧的按钮，而 Tab 却跳到了下方或上一个卡片里的控件，空间地图和焦点地图就拆成了两张。
机制
焦点序列默认跟文档树的顺序走，视觉顺序却由布局决定。浮动、绝对定位、Flex / Grid 的 order、以及把 DOM 写在页脚却画在页头的做法，都会让两套顺序分叉。人为指定的正 tabindex 还会把控件从自然序列里抽出来，插到一轮“先走一遍所有正值”的队列里，分叉更难预测。人在扫视时已经对下一处控件建立了预期位置；焦点若落到视野外或视觉上的上一处，就要重新搜索“焦点现在在哪”，键盘路径的时间优势被找焦点的时间吃掉。一致不是审美，而是让空间预期继续能预测下一跳。
怎么研究
让键盘用户完成填表、对话框确认和多栏工具栏任务，记录每一跳焦点落点与其自报的“下一个该是哪”。自变量包括 DOM 顺序与视觉顺序是否对齐、是否使用正 tabindex、栏数和阅读方向；因变量包括迷失次数、完成时间、以及焦点落在视口外的次数。只检查“所有控件都能 Tab 到”会把顺序错误写成通过。需要一张视觉序号图和一张 Tab 序号图对照。
边界
表格、spreadsheet 式控件内部常用方向键走单元格，Tab 可能被改成“跳到下一字段”或“离开表格”；那是控件内部的导航约定，不能拿来要求整页也按网格走。动态插入的控件（校验失败后出现的字段）会暂时打乱既有序列，需要决定插在视觉对应位置还是序列末尾。从右到左界面的“阅读顺序”本身就与 LTR 相反，用 LTR 的左到右去验收会判错。
怎么落地
- 按视觉阅读顺序排列 DOM，避免用 CSS order 或绝对定位把可聚焦控件在视觉上搬到与树顺序不同的地方。
- 不要用正 tabindex 重排整页；需要调整时改 DOM，而不是插入一张第二序列。
- 验收时把每一跳标在截图上，对照设计稿的阅读顺序；出现跳到上一张卡片、跳过一整列或焦点跑出视口，即判为顺序失败。