查询页 Tab 顺序跳到屏幕角落，怎样核对 tabindex 与 DOM 顺序

先让 DOM 顺序对应阅读与操作顺序，常规控件使用原生焦点能力或 tabindex=0。正数 tabindex 会插到普通顺序之前；-1 通常只适合程序主动移焦，不应把它误解成“彻底无法聚焦”。

先列顺序，再拿键盘验证

示例DOM依次是A、B、C、D，B的tabindex为2，C为1，D为-1。页面初次Tab会先到C，再到B，再到A，和视觉排布完全不同。脚本逐次读取activeElement而不是只截图焦点环，避免样式把焦点环隐藏后误判输入没有进入控件。修复将B和C回到0，随后从A开始应按DOM次序进入B与C。

不要靠连续编号补布局问题

把全页按钮标成1、2、3看似能强制顺序，后续插入弹层、工具条或新卡片时却要重排所有编号，而且正数会优先于普通控件。更稳妥的做法是让DOM结构本来就符合任务流程，再用CSS呈现布局。若CSS把阅读顺序彻底反转，键盘与视觉仍会不一致，应先讨论结构而不是继续增加tabindex补丁。

把可聚焦和顺序可达分开

脚本最后通过focus主动聚焦D，证明-1没有禁止程序聚焦。这个能力常用于将焦点送到弹窗标题、错误摘要或新加载区域，但不应拿它让所有动作按钮退出Tab序列。disabled、hidden、inert等状态也会影响可达性，实际页面要把这些条件同次记录，不能只看一个属性就断言键盘能否访问。

边界与交付记录

本地自动化验证的是这一份HTML在Chromium里的焦点次序，没有测试读屏导航、物理辅助开关或目标终端键盘。项目应按进入首页、打开详情、关闭详情三条任务检查正向Tab和Shift+Tab，保存每步id及可见焦点。若浏览器设置或操作系统对原生控件焦点有差异，应在指定版本上复核，而不是把本例序列当所有平台的唯一结果。

把不可见焦点作为独立失败

顺序正确但没有可见焦点仍会让维护人员迷失。应在目标样式下检查focus-visible或其他清楚提示，不要仅为了截图干净全局outline:none。附件用activeElement断言顺序，没有自动评分焦点对比度。若页面采用网格视觉布局，另存一张编号示意图，比较Tab轨迹是否跟随合理任务顺序，尤其检查右侧浮动按钮是否被DOM放在页面最前面。

下载并复现

下载原创HTML夹具、独立验证程序、本次执行记录和依赖与运行说明，放在同一目录。安装Playwright 1.58.0及其Chromium后运行 python verify.py；程序使用两个随机本地端口，自动关闭浏览器与服务，不请求外网或业务接口。

本次实际环境为Python 3.12.4、Playwright 1.58.0、Chromium 145.0.7632.6。Playwright浏览器鼠标/键盘与页面API实跑；无实体硬件或业务控制。断言已通过；完整事件和数值保留在执行记录，不能把它改名后当目标展项测量。

自动化只检查焦点、控件行为和可查询语义，没有实际运行屏幕阅读器，也没有招募参与者。朗读顺序、触摸辅助技术和目标终端可用性需要另外验证。

继续核查与一级出处

基础背景见中控触摸界面（UI）设计规范。页面顺序导航与标签组内部的单入口导航应分别设计，可继续用展品分类标签每次要按十次 Tab，怎样验证 roving tabindex 的入口取证；相关工程入口在专题与产品对接说明。

• tabindex与顺序焦点导航：2026-10-24已联网读取一级来源；WHATWG HTML Living Standard，读取页标记2026-10-22更新。