想象一栋没有电梯、也没有灯光的数字大楼，住着一位特别的访客——盲杖客。他看不清屏幕，全靠手里那根用 Tab 键做成的盲杖一步一探。每按一次 Tab，盲杖就轻轻敲到一样东西：可能是一扇门、一个按钮、一个输入框。如果大楼的管理者想让这位客人住得舒心，就得保证三件事：盲杖敲得到（可聚焦）、敲到的地方有反光标记（焦点可见）、门牌号不乱排（顺序合理）。而 AI 要做的事情，就是派出一支不知疲倦的“数字巡检员”队伍，每天沿着盲杖客的足迹走一遍，把挡路的杂物、坏掉的捷径、囚人的密室统统找出来，再开出整改通知书。这条“检查—发现问题—自动修复”的流水线，正是键盘导航与焦点管理 AI 检测的核心。

岗位关联

对 AI 从业者来说，A11y（无障碍）检测是前端工程化里高价值又稀缺的场景——掌握它，你就同时握住了“业务理解 + AI 工程 + 无障碍规范”三张入场券。

目录
  1. 可视化演示
  2. 键盘导航基础
  3. 焦点流分析检测
  4. Skip链接校验
  5. 模态焦点管理
  6. AI检测流水线
  7. 自动修复建议
  8. 工程落地实践
  9. AI 应用场景
  10. Python 演示
  11. 常见误区
  12. 面试题

可视化演示

演示AI检测键盘导航：焦点流分析、跳过链接校验与模态焦点管理。

本节配有交互动效（进入视口后自动加载，约 3KB）。

焦点流分析 Tab顺序 偏差 Tab→Focus 检测焦点流转顺序

键盘导航基础

很多大楼的一楼是一条长长的展示走廊，导航菜单密密麻麻排了几十个门。盲杖客若想走到最里面的大厅，靠盲杖一格一格敲过去得敲半天。于是大楼在入口右手边设了一部直达电梯，按钮上写着“跳过走廊，直达大厅”——这就是 Skip 链接的原型。在 Web 世界里，它是 DOM 中第一个可聚焦元素，通常视觉上隐藏，只在使用键盘聚焦时浮现，点击后把页面滚动或跳转到主内容区域。AI 要校验的，就是这部“电梯”到底能不能用。

校验分三步。第一步，链接必须存在，且出现在导航之前、最好位于 DOM 树最前面；第二步，链接的 href 必须指向一个真实存在的目标锚点，目标元素最好带 tabindex="-1" 以便接收焦点；第三步，链接本身必须可聚焦、且聚焦时可见——常见做法是用：focus-visible 配合 .sr-only 样式，平时裁切隐藏、聚焦时完整显示。AI 检测时依次检查这三个布尔条件，任何一个失败就记录问题。电梯验收完毕，巡检员接着要去看看楼里那些时不时弹出来的密室——模态对话框。这间密室有个毛病：盲杖客进去容易，出来难。

焦点流分析检测

大楼的物业巡检员决定跟着盲杖客走一遍全程。他手里拿着一份清单，每敲一下就在清单上画一个圈，最后把这张圈圈点点的手绘地图摊开，对照设计图纸：盲杖客有没有绕远路？有没有漏掉重要房间？有没有不小心敲开储藏室的门？这段旅程对应 AI 检测里的“焦点流分析”：自动化脚本模拟真实用户的 Tab 操作，从按下 Tab 键开始记录每一次焦点变化，得到一个按时间排列的焦点队列。这个队列就是盲杖客的行走轨迹，而设计图纸就是页面的视觉布局。把轨迹和图纸叠在一起，就能看出顺序是否一致。

常见的检测点有三个：一是顺序一致性——焦点队列的位置排序应当大致符合“从上到下、从左到右”的视觉阅读习惯，如果元素 A 在视觉上位于元素 B 的左上角，但 Tab 先到了 B 再到 A，就会造成跳跃；二是隐藏元素聚焦——CSS 里写 display:none 或 visibility:hidden 的元素如果带着 tabindex="0"，会被盲杖敲到，而用户看不见自己焦点在哪；三是 tabindex 正数滥用——tabindex=5、tabindex=9 这类正数会把元素强行提到 Tab 顺序最前面，打乱原有的自然流动，规范上推荐只用 0 和 -1。分数越高，盲杖客走得越顺。一旦分数偏低，巡检员就会在图纸上标出几个红圈，下一步该核查楼里最重要的快捷通道了。

Focusable(e)=(e∈Einteractive)∨(tabindex(e)≥0)\displaystyle \text{Focusable}(e) = \big( e \in E_{\text{interactive}} \big) \lor \big( \text{tabindex}(e) \ge 0 \big)
这个公式是说：一个元素能被 Tab 盲杖敲到，要么它天生就是互动元素（链接、按钮、输入框），要么作者手动给它发了一块“门牌”（tabindex≥0）。
  1. 互动元素集合$E_{\text{interactive}}$ 表示浏览器内置可交互的标签集合，例如链接、按钮、表单控件，它们天生就在盲杖客的“可敲名单”里。
    Einteractive={a,button,input,select,textarea,… }\displaystyle E_{\text{interactive}} = \{\text{a}, \text{button}, \text{input}, \text{select}, \text{textarea}, \dots\}
  2. tabindex 升级$\text{tabindex}(e) \ge 0$ 表示作者主动给某个普通元素“发门牌”，让它也能被盲杖敲到。
    tabindex(e)≥0⇒e∈Ω\displaystyle \text{tabindex}(e) \ge 0 \Rightarrow e \in \Omega
  3. 或运算合并$\lor$ 把两个条件合并，任一成立，元素就进入键盘可达名单 $\Omega$。
    Ω={e∣e∈Einteractive∨tabindex(e)≥0}\displaystyle \Omega = \{ e \mid e \in E_{\text{interactive}} \lor \text{tabindex}(e) \ge 0 \}

Skip链接校验

盲杖客在大厅里走着走着，突然被请进一间密室——一个模态对话框弹了出来，要求他确认一项重要操作。密室的规矩是：门一关，外界的声音要隔离；盲杖客只能在密室里摸东西，不能摸到墙外去；等他谈完事出来，还得回到进门前站的那个位置。这间密室稍不留神就会变成“只能进不能出”的鬼打墙，让盲杖客在密室和走廊之间反复穿梭却永远碰不到出口。模态焦点管理是键盘导航中最容易翻车的一环，AI 检测时把这三条要求编成三盏红绿灯。

第一盏绿灯“初始焦点”：检测模态打开事件发生后，activeElement 是否落在模态内部；第二盏绿灯“焦点陷阱”：监听 Tab 与 Shift+Tab，如果当前焦点是模态的最后一个可聚焦元素，再按 Tab 就要被拦回第一个元素，背景内容还要加上 inert 或 aria-hidden 防止屏幕阅读器穿透；第三盏绿灯“焦点归还”：模态关闭后，activeElement 是否回到触发按钮。三盏灯全绿才算合格。密室检查完了，巡检员摸摸口袋里的笔记本，已经攒了好几处问题。他心想要是光靠人一层一层跑，这栋楼每季度都检查不完——不如训练一群机器人，把巡检经验全部交给它们。

ValidSkip(L)=(target(L)≠∅)∧(focusable(target(L)))∧(focusable(L))\displaystyle \text{ValidSkip}(L) = \big( \text{target}(L) \ne \varnothing \big) \land \big( \text{focusable}(\text{target}(L)) \big) \land \big( \text{focusable}(L) \big)
这个公式是 Skip 链接的“电梯验收标准”：目的地存在、目的地可聚焦、按钮本身可聚焦，三个条件缺一个，这趟直达电梯就不合格。
  1. 目标非空$\text{target}(L) \ne \varnothing$ 表示链接的锚点存在于页面中，不能是悬空的死链。
    target(L)≠∅\displaystyle \text{target}(L) \ne \varnothing
  2. 目标可聚焦$\text{focusable}(\text{target}(L))$ 表示跳转目的地能接收键盘焦点，否则盲杖客“跳”过去了却落在黑灯瞎火处。
    focusable(target(L))=true\displaystyle \text{focusable}(\text{target}(L)) = \text{true}
  3. 链接可聚焦$\text{focusable}(L)$ 表示电梯按钮本身要让盲杖客够得着。
    focusable(L)=true\displaystyle \text{focusable}(L) = \text{true}
  4. 与运算合并$\land$ 三个条件必须同时成立，电梯才算合格。
    ValidSkip(L)=true  ⟺  条件一∧条件二∧条件三\displaystyle \text{ValidSkip}(L) = \text{true} \iff \text{条件一} \land \text{条件二} \land \text{条件三}

模态焦点管理

巡盲杖客在大厅里走着走着，突然被请进一间密室——一个模态对话框弹了出来，要求他确认一项重要操作。密室的规矩是：门一关，外界的声音要隔离；盲杖客只能在密室里摸东西，不能摸到墙外去；等他谈完事出来，还得回到进门前站的那个位置。这间密室稍不留神就会变成“只能进不能出”的鬼打墙，让盲杖客在密室和走廊之间反复穿梭却永远碰不到出口。模态焦点管理是键盘导航中最容易翻车的一环。模态框打开时，浏览器并不会自动把焦点送进密室，需要开发者手动把焦点放到模态容器或第一个可聚焦控件上。

第一盏绿灯“初始焦点”：检测模态打开事件发生后，activeElement 是否落在模态内部；第二盏绿灯“焦点陷阱”：监听 Tab 与 Shift+Tab，如果当前焦点是模态的最后一个可聚焦元素，再按 Tab 就要被拦回第一个元素，背景内容还要加上 inert 或 aria-hidden 防止屏幕阅读器穿透；第三盏绿灯“焦点归还”：模态关闭后，activeElement 是否回到触发按钮。三盏灯全绿才算合格。密室检查完了，巡检员摸摸口袋里的笔记本，已经攒了好几处问题。他心想要是光靠人一层一层跑，这栋楼每季度都检查不完——不如训练一群机器人，把巡检经验全部交给它们。

TrapOK(M)=in(M)∧loop(M)∧back(M)\displaystyle \text{TrapOK}(M) = \text{in}(M) \land \text{loop}(M) \land \text{back}(M)
这个公式是模态“密室安全三件套”：焦点进得去、在室内循环、出得来还能回原位。三个条件同时成立，盲杖客才不会被鬼打墙困住。
  1. 初始落点$\text{in}(M)$ 表示模态打开后焦点进入密室内部，而不是留在背景页面上。
    in(M)=activeElement∈M\displaystyle \text{in}(M) = \text{activeElement} \in M
  2. 内部循环$\text{loop}(M)$ 表示 Tab 键在模态内形成闭环，焦点不会私逃到背景。
    loop(M)=Tab 序列首尾相接∧背景不可聚焦\displaystyle \text{loop}(M) = \text{Tab 序列首尾相接} \land \text{背景不可聚焦}
  3. 焦点归还$\text{back}(M)$ 表示关闭模态后焦点回到之前的站立位置，通常是触发按钮。
    back(M)=focus(trigger)\displaystyle \text{back}(M) = \text{focus}(\text{trigger})
  4. 与运算合并$\land$ 三条同时成立，密室才算真正安全。
    TrapOK(M)=in(M)∧loop(M)∧back(M)\displaystyle \text{TrapOK}(M) = \text{in}(M) \land \text{loop}(M) \land \text{back}(M)

AI检测流水线

巡检员把十年来积累的巡检经验写成一本厚厚的操作手册，交给一支机器人巡检队：它们不需要一双人类的眼睛，只需要按固定流程——先拍户型图，再给每道门贴标签，最后对照手册里的规则和案例做出判断。这支队伍可以同时巡检一百栋楼，效率远超单个人类。这支机器人队伍就是 AI 检测流水线。它的第一步是“拍户型图”：用无头浏览器加载页面，提取完整的 DOM 元素拓扑，记录每个元素的位置、大小、层级关系；第二步是“贴标签”：给每个元素赋予特征向量，包括是否可聚焦、tabindex 值、角色 role、可见性、是否在模态内部等；第三步才是判断。

判断层采用“规则+模型”双引擎。启发式规则引擎适合确定性结论：比如“页面缺少 class 为 skip-link 的链接”“tabindex 为正数”“模态打开后 activeElement 仍留在背景”，这些规则可以用精确的 If-Then 表达。机器学习模型则负责更模糊的判定：元素特征向量经过逻辑回归或随机森林，输出“这个元素是否存在焦点风险”的概率。两条路径的结果再经过融合决策输出问题清单。AI 的优势在于把人工巡检时“扫一眼就发现不对劲”的直觉，变成了可以大规模复制的计算。机器人巡检队效率虽高，但不能只报警不修楼。它们每发现一个问题，还要随手开出一张整改通知书——下一节就讲通知书是怎么生成的。

P(issue∣e)=σ(w⋅ϕ(e)+b)\displaystyle P(\text{issue} \mid e) = \sigma\big( \mathbf{w} \cdot \boldsymbol{\phi}(e) + b \big)
这个公式是“风险打分机”：把元素的特征（位置、可聚焦性、角色等）加权求和，再用 sigmoid 压成 0~1 的概率，超过阈值就报问题。
  1. 特征向量$\boldsymbol{\phi}(e)$ 是元素 e 的特征编码，比如可聚焦性、可见性、是否在模态内、tabindex 数值等。
    ϕ(e)=(ϕ1(e),ϕ2(e),…,ϕk(e))\displaystyle \boldsymbol{\phi}(e) = \big( \phi_1(e), \phi_2(e), \dots, \phi_k(e) \big)
  2. 线性打分$\mathbf{w} \cdot \boldsymbol{\phi}(e) + b$ 用权重向量与特征做内积，再加偏置 b，相当于给元素按经验印象打分。
    score(e)=w⋅ϕ(e)+b\displaystyle \text{score}(e) = \mathbf{w} \cdot \boldsymbol{\phi}(e) + b
  3. Sigmoid 压缩$\sigma(\cdot)$ 把任意实数得分压到 0 到 1 区间，成为该元素存在无障碍问题的概率。
    σ(z)=11+e−z\displaystyle \sigma(z) = \frac{1}{1 + e^{-z}}
  4. 条件概率$P(\text{issue} \mid e)$ 表示给定元素 e 的条件下，问题发生的概率。
    P(issue∣e)∈[0,1]\displaystyle P(\text{issue} \mid e) \in [0, 1]

自动修复建议

巡检机器人发现电梯按钮坏了，不会只嘟一声报个警，而是直接掏出工具箱，贴出一张整改单：“问题：直达电梯按钮缺失；原因：导航前没有放置 Skip 链接；建议：在导航前安装一个带 skip-link 样式的链接，指向 main 区域。”整改单写得明明白白，装修师傅照着做就行。自动修复建议生成的思路与此一致：AI 先根据问题类型定位根因，再在修复模板库中匹配对应的修复方案，最后结合页面上下文填充具体参数，生成可直接应用的补丁代码。比如“缺少 Skip 链接”匹配的模板就是一段带 class 的 a 标签与配套 CSS；“模态缺少焦点陷阱”匹配的模板则是一个 focus 守卫函数和 inert 属性。

生成建议并不等于盲目输出代码，还需要做优先级排序。一个检测问题清单可能同时包含：模态焦点陷阱、Skip 链接缺失、隐藏元素可聚焦、tabindex=5 滥用。修复时按“严重程度、影响用户量、修复成本”三个维度加权排序：影响屏幕阅读器和键盘用户核心流程的模态陷阱排最前，只影响视觉的样式问题殿后。工程上还可以把修复方案转成 codemod 脚本，在 CI 里一键自动修。整改单越写越顺手，巡检机器人已经在好几栋楼里上岗了。但物业经理提出了新要求：光会巡检不够，得把整套流程装进每天的日常安检里，让每一处装修都逃不过它的眼睛。

Priority(f)=α⋅Sev(f)+β⋅Impact(f)−γ⋅Effort(f)\displaystyle \text{Priority}(f) = \alpha \cdot \text{Sev}(f) + \beta \cdot \text{Impact}(f) - \gamma \cdot \text{Effort}(f)
这个公式是“整改排序器”：问题越严重、影响的人越多，越要优先修；但如果修起来特别费劲，就得掂量一下投入产出比。
  1. 严重度$\text{Sev}(f)$ 表示问题 f 阻碍使用的程度，模态陷阱致命、顺序微调轻微。
    Sev(f)∈[0,1]\displaystyle \text{Sev}(f) \in [0, 1]
  2. 影响面$\text{Impact}(f)$ 表示受影响用户的占比或频次，用 0 到 1 的系数衡量。
    Impact(f)∈[0,1]\displaystyle \text{Impact}(f) \in [0, 1]
  3. 修复成本$\text{Effort}(f)$ 表示人力工时或代码改动量。
    Effort(f)∈[0,1]\displaystyle \text{Effort}(f) \in [0, 1]
  4. 线性加权$\alpha$、$\beta$、$\gamma$ 是权重，成本项取负号，成本越高优先级越低。
    Priority(f)=α⋅Sev(f)+β⋅Impact(f)−γ⋅Effort(f)\displaystyle \text{Priority}(f) = \alpha \cdot \text{Sev}(f) + \beta \cdot \text{Impact}(f) - \gamma \cdot \text{Effort}(f)

工程落地实践

物业公司决定把巡检机器人编入标准安检流程：每天清晨先沿既定路线巡检一遍，装修队每签一处工地，机器人就进场复查、在门口贴上“无障碍检查通过/未通过”的贴纸；一旦某栋楼返工，还要在物业台账上记一笔，防止下次再犯。工程落地就是把 AI 检测器从一次性脚本变成持续运转的体检系统。最常见的形态是 CI/CD 集成：开发者提交代码后，流水线自动安装依赖、启动无头浏览器、运行 AI 检测、把问题以注释形式贴在 PR 对应代码行上。检测器还可以做成浏览器扩展，让 QA 在页面上实时录制焦点路径、查看焦点流报告。

三种形态共享同一个检测内核，只是触发方式不同。要保证检测效果持续稳定，必须引入回归测试与快照机制：每发现一个真实问题，就把它的页面片段和焦点路径固化成测试用例，纳入用例库；每次改动检测器后运行全量用例，防止修复了 A 问题却漏掉了 B 问题。团队协作层面，可以给检测器配置问题分级与自动指派：P0 问题直接阻断合并，P1 问题提醒修复，P2 问题记录到技术债。检测通过率可以量化成团队的健康度指标。到这一步，盲杖客的数字大楼终于有了全天候的护航。楼里的规矩、巡检的方法、机器人的经验、整改的流程，全都环环相扣。理解这条链路，再回看每一行 HTML 与 CSS，你会发现自己正在为那些看不见屏幕的用户，修一条真正畅通无阻的路。

Q=Ttotal−TfailTtotal\displaystyle Q = \frac{T_{\text{total}} - T_{\text{fail}}}{T_{\text{total}}}
这个公式是“大楼健康度”：一次巡检中通过检查的条目数占总检查条目的比例，越接近 1 说明这栋楼对盲杖客越友好。
  1. 总检查项$T_{\text{total}}$ 表示一次巡检中全部检测条目的数量，比如可聚焦节点数、模态数量、链接校验数。
    Ttotal=所有检测条目的总数\displaystyle T_{\text{total}} = \text{所有检测条目的总数}
  2. 失败项$T_{\text{fail}}$ 表示未通过检测的条目数量，比如 12 条里有 3 条红灯，失败项就是 3。
    Tfail=未通过检测的条目数\displaystyle T_{\text{fail}} = \text{未通过检测的条目数}
  3. 健康度$Q$ 是 0 到 1 之间的通过率，1 代表这栋楼今天完全无障碍，0 代表处处是坑。
    Q∈[0,1]\displaystyle Q \in [0, 1]

AI 应用场景

PR 自动无障碍评审

阶段：开发与代码审查阶段

解决的问题：前端团队代码评审时，键盘导航问题靠人眼很难发现。AI 检测器在 PR 提交后自动跑一遍“盲杖客模拟”，把焦点路径问题、Skip 链接缺陷、模态陷阱直接标注到代码行，评审者不用再手动 Tab 一个页面。

具体案例：某 SaaS 企业设计系统组件库，在 CI 中接入 A11y 检测器后，3 个月内拦截了 47 次焦点陷阱回归；一次日期选择器重构中，检测器在 PR 阶段发现弹层关闭后焦点未归还，自动建议在关闭回调中调用 trigger.focus()。

组件库综合体检报告

阶段：组件开发与发布阶段

解决的问题：组件库组件多、版本快，键盘行为回归难以全量人工验证。AI 把每个组件源码渲染成快照，跑一遍焦点流打分，生成“无障碍体检报告”。

具体案例：某开源组件库在发布前用 AI 对 Tabs、Dialog、Select 等 24 个组件做焦点巡检，发现 Tabs 组件按方向键切换时焦点丢失，检测器定位到缺少 roving tabindex 模式，自动生成修复补丁，发布后组件无障碍评分从 72 分升到 95 分。

QA 现场巡检与还原

阶段：测试与用户反馈阶段

解决的问题：QA 测试键盘导航时，纯手工录制 Tab 路径效率低且容易漏。浏览器扩展录制焦点轨迹 + AI 判定，快速生成可视化报告。

具体案例：QA 工程师在目标页面打开扩展，按下录制键后连按 10 次 Tab，扩展自动画出焦点轨迹并高亮两处乱序问题，一键导出 Markdown 报告给开发，问题定位时间从 40 分钟降到 3 分钟。

Python 演示

python98 行
"""键盘导航与焦点管理AI检测演示. 用正则扫描HTML片段, 抽取可聚焦节点,检查Skip链接, 模态框与tabindex滥用,输出可读的检测结论与修复建议."""import re HTML = """<body>  <a class="skip-link" href="#main">跳到正文</a>  <nav>    <a href="/a">链接A</a>    <a href="/b">链接B</a>    <a href="/z" tabindex="2">链接C</a>  </nav>  <div role="dialog" id="dlg">    <button id="ok">确定</button>    <button id="cancel">取消</button>  </div>  <main id="main" tabindex="-1">    <a href="/c">链接D</a>  </main></body>""" FOCUSABLE_TAGS = {"a", "button", "input", "select", "textarea"}  class A11yAuditor:    """一个极简的键盘导航无障碍审计器."""     def __init__(self, html):        self.html = html        self.nodes = []        self.issues = []     def scan(self):        pattern = r"<(\w+)([^>]*)>"        for match in re.finditer(pattern, self.html):            tag = match.group(1).lower()            attr_text = match.group(2)            attrs = dict(re.findall(r'([\w-]+)="([^"]*)"', attr_text))            has_href = "href" in attrs            has_tabindex = "tabindex" in attrs            if tag in FOCUSABLE_TAGS or has_tabindex:                self.nodes.append({                    "tag": tag,                    "id": attrs.get("id", ""),                    "cls": attrs.get("class", ""),                    "href": attrs.get("href", ""),                    "tabindex": int(attrs.get("tabindex", "0")) if has_tabindex else 0,                    "role": attrs.get("role", ""),                    "order": len(self.nodes),                })     def audit(self):        self.scan()        skips = [n for n in self.nodes if "skip" in n["cls"]]        if not skips:            self.issues.append("[skip] 缺少Skip链接: 请在导航前添加直达正文的链接")        else:            target_id = skips[0]["href"].lstrip("#")            targets = [n for n in self.nodes if n["id"] == target_id]            if targets and targets[0]["tabindex"] >= -1:                self.issues.append("[skip] Skip链接有效, 目标#%s可聚焦" % target_id)            else:                self.issues.append("[skip] Skip链接目标#%s缺失或不可聚焦" % target_id)        dialogs = [n for n in self.nodes if n["role"] == "dialog"]        for dialog in dialogs:            self.issues.append(                "[modal] 模态#%s需实现焦点陷阱与焦点归还" % dialog["id"]            )        for node in self.nodes:            if node["tabindex"] > 0:                self.issues.append(                    "[order] %s#%s使用了tabindex=%d, 建议改为0以免打乱Tab顺序"                    % (node["tag"], node["id"], node["tabindex"])                )     def report(self):        print("扫描到%d个可聚焦节点:" % len(self.nodes))        for node in self.nodes:            print("  <%s id=%s tabindex=%d role=%s>" % (                node["tag"], node["id"], node["tabindex"], node["role"]))        print("\n检测结论:")        for issue in self.issues:            print("  -", issue)        if not self.issues:            print("  - 未发现键盘导航问题")     def run(self):        self.audit()        self.report()  if __name__ == "__main__":    A11yAuditor(HTML).run()
目的：用纯标准库实现一个极简键盘导航审计器，扫描 HTML 片段并输出 Skip 链接、模态与 tabindex 三类问题，是 AI 检测流水线的规则引擎雏形。
  1. FOCUSABLE_TAGS = {"a", "button", "input", "select", "textarea"}定下本层“默认可敲到的门”清单，相当于盲杖客的基础手绘地图。
  2. attrs = dict(re.findall(r'([\w-]+)="([^"]*)"', attr_text))用正则把标签属性拆成字典，相当于给每扇门贴上标签。
  3. "order": len(self.nodes)用当前列表长度记录 DOM 出现顺序，Tab 的自然顺序就是它。
  4. if "skip" in n["cls"]:通过 class 识别 Skip 链接，对应“直达电梯”按钮。
  5. target_id = skips[0]["href"].lstrip("#")取出电梯目的地锚点 id, 去掉 # 前缀。
  6. if targets and targets[0]["tabindex"] >= -1:校验目的地能否接收焦点，相当于确认电梯能停靠在真实楼层。
  7. if node["tabindex"] > 0:tabindex 正数是顺序污染的元凶，检测器会建议改成 0。
  8. A11yAuditor(HTML).run()主入口，一条命令跑完整个审计流程，输出整改清单。

常见误区

误区我以为 tabindex="-1" 会让元素彻底跟键盘绝缘，所以在做模态框时根本不敢用它，结果焦点没法送到模态容器里，一打开模态屏幕阅读器还在读背景内容。

正解tabindex=“-1“ 确实把元素从 Tab 的自然流转中移除，但它仍然可以通过脚本调用 focus() 聚焦。这正是模态框需要的：打开模态时用 JavaScript 把焦点放进内部容器，同时又不让这个容器出现在用户的 Tab 路径上。同理，跳转锚点、错误提示框也常用 tabindex=”-1“ 接收焦点。它是”可编程聚焦但不出现在 Tab 队列“的开关，而不是”永远不可聚焦”的封印。

为何常见：把 tabindex=“-1“ 等同于”不可聚焦”，是因为大家只观察到 Tab 键不会停在它上面，却忽略了脚本聚焦这条通道。

误区我给所有按钮都写了：focus { outline: 2px solid blue }，自认为焦点可见性已经做得很好了，但产品经理说鼠标点击时也出现蓝框很丑。

正解真正符合规范的是：focus-visible 而不是：focus。:focus-visible 只在键盘等非指针设备操作时显示焦点环，鼠标点击不会触发，视觉效果干净；而：focus 不区分输入来源，鼠标点一下也描一圈蓝边，反而让大多数用户觉得多余。用：focus-visible 才能兼顾键盘用户与鼠标用户，这也是现代浏览器和组件库的默认推荐。

为何常见：开发者习惯用：focus 解决问题，市面上许多旧教程也只提：focus，没有跟上 CSS 选择器的新能力。

误区我以为模态框只要打开时把焦点送进去、在里面困住就万事大吉，关闭后焦点留在模态的最后一个按钮上也没在意。结果键盘用户继续 Tab 时，焦点从页面底部莫名其妙地冒出来了。

正解焦点归还是模态管理的第三根支柱。模态关闭后，焦点应该交还给打开模态的触发元素，这样键盘用户的“位置感”才连续。否则用户会迷失在页面底部，还要手动 Tab 一大段才能回到刚才的语境。AI 检测器会把“activeElement 是否回到触发按钮”作为一条硬性规则，失分就会亮红灯。

为何常见：大家更关注打开模态时“能不能进去”，忽略了关闭后“从哪继续”，因为开发时用鼠标点开点关，鼠标自己会回到页面原来的位置，掩盖了焦点丢失问题。

误区既然 AI 检测器能扫出焦点陷阱、Skip 链接缺失，那是不是只要 CI 通过就代表产品完全无障碍了？我可以把人工测试全砍掉。

正解AI 擅长确定性规则类问题，比如 tabindex 正数、Skip 链接目标失效、模态打开后 activeElement 不合法；但“这个焦点顺序在具体业务场景中是否真的让用户困惑”这类语义判断，AI 仍做不到 100%。正确姿势是 AI 做全量初筛，人工做抽样深审，AI 负责抓常见病，人类负责疑难杂症。把 AI 检测当成高效的过滤器，而不是终极裁判。

为何常见：看到检测器能自动跑路径、自动标红，容易高估其能力边界，误以为“可自动化”等同于“完全可替代”。

面试题

Q1. Tab 键在网页上的默认移动顺序由什么决定？

单选题 · easy

  • A.DOM 树中的出现顺序← 正确答案
  • B.视觉上的从上到下
  • C.CSS 的 z-index 层级
  • D.页面资源加载时间

答案：A。Tab 的自然顺序严格遵循 DOM 树的出现顺序，就像盲杖客按门牌号从 1 号摸到 N 号，而不是按楼层高低走。视觉顺序和 z-index 都不会改变默认 Tab 序，加载时间更是无关因素。

Q2. 要让元素既能被脚本聚焦、又不进入 Tab 顺序，应设置：

单选题 · easy

  • A.tabindex="0"
  • B.tabindex="-1"← 正确答案
  • C.tabindex="1"
  • D.disabled 属性

答案：B。tabindex=“-1“ 相当于给元素发了一张”工作人员通行证“：脚本可以 focus() 它，但盲杖客的 Tab 路径上不会出现它。tabindex=”0” 会加入 Tab 顺序，正数会打乱顺序，disabled 则完全禁用。

Q3. :focus-visible 与：focus 的核心区别是：

单选题 · mid

  • A.只在键盘操作时生效← 正确答案
  • B.只对鼠标点击生效
  • C.会改变元素布局
  • D.只能用于表单控件

答案：A。:focus-visible 是“键盘用户专用”的焦点环，鼠标点击时不会出现难看描边；:focus 则不分来源。好比大楼的反光地贴只在盲杖客经过时亮起，普通客人走路不会看到一堆发光砖。

Q4. 模态焦点管理必须满足哪些条件？

多选题 · mid

  • A.打开时焦点移入模态← 正确答案
  • B.Tab 键在模态内循环← 正确答案
  • C.背景内容仍可被 Tab 访问
  • D.关闭后焦点归还触发元素← 正确答案

答案：ABD。模态管理的三根支柱是“进得去、困得住、回得来”：打开时焦点要移入模态，Tab 要在模态内循环，关闭后焦点要回到触发按钮。背景内容必须用 inert 或 aria-hidden 隔离，不能再被 Tab 访问，所以 C 是错误描述。

Q5. Skip 链接的核心用途是：

单选题 · mid

  • A.显著提升搜索引擎排名
  • B.跳过重复导航直达正文← 正确答案
  • C.加快页面资源加载速度
  • D.重新排列 Tab 焦点顺序

答案：B。Skip 链接是给键盘用户的“直达电梯”，放在 DOM 最前面，让他们一步跳过长长的导航菜单、直接进入主内容区。它不改变 Tab 顺序，也不影响加载速度和 SEO 排名，核心价值只有无障碍。

Q6. 关于 AI 检测键盘导航问题，以下说法正确的是：

多选题 · hard

  • A.可自动提取 DOM 元素拓扑特征← 正确答案
  • B.启发式规则可检测 Skip 链接缺失← 正确答案
  • C.AI 能完美理解所有视觉语义
  • D.逻辑回归可判定元素焦点风险← 正确答案

答案：ABD。AI 流水线先用无头浏览器提取 DOM 拓扑，再用规则引擎处理 Skip 链接缺失等确定性结论，用逻辑回归输出焦点风险概率。但“完美理解视觉语义”是夸大其词，AI 擅长确定性规则和概率打分的组合，无法取代人类的语义判断。

Q7. 一个元素设置了 display:none 且 tabindex="0"，浏览器会：

单选题 · hard

  • A.键盘仍能聚焦并自动显示
  • B.忽略该元素，不进入 Tab 顺序← 正确答案
  • C.抛出解析错误导致页面崩溃
  • D.元素会自动变为可见状态

答案：B。display:none 的元素已经从渲染树中彻底移除，浏览器不会让隐形的门出现在盲杖客的路径里，所以 tabindex 会被忽略、不进入 Tab 顺序。AI 检测时不会把它标记为焦点陷阱，但会检查“隐藏元素是否残留 tabindex”这类潜在混淆。

Q8. 单页面应用中，用户关闭模态框后，焦点应归还给：

单选题 · mid

  • A.模态框的最后一个按钮
  • B.打开模态时所在的触发元素← 正确答案
  • C.页面最顶部的导航链接
  • D.页面第一个输入框

答案：B。焦点归还要“从哪里来到哪里去”，回到触发元素才能让盲杖客的位置感连续。如果焦点留在模态内部或跳到页面顶部，用户会像被瞬间传送到陌生楼层，需要重新摸索才能回到刚才的语境。

Q9. 以下哪些元素默认可以被 Tab 聚焦？

多选题 · easy

  • A.带 href 的 a 链接← 正确答案
  • B.button 按钮标签← 正确答案
  • C.普通 div 容器
  • D.input 输入框← 正确答案

答案：ABD。带 href 的链接、button、input 都是浏览器内置的互动元素，天生就在 Tab 名单里。普通 div 没有任何交互语义，默认不可聚焦，需要开发者手动添加 tabindex 才能进入盲杖客的路径。

Q10. 一个元素用 position:fixed 视觉上置于页面最前方，但被放在 DOM 树最后面，AI 检测焦点流时会判定为：

单选题 · extreme

  • A.检测判定完全无问题
  • B.顺序与视觉不一致造成跳跃← 正确答案
  • C.该元素永远不可聚焦
  • D.导致渲染引擎直接崩溃

答案：B。Tab 顺序只认 DOM 顺序，不认视觉位置。这个元素视觉在最前、DOM 却在最后，盲杖客要摸完整个页面才会敲到它，与视觉认知严重错位。AI 的焦点流分析会把“视觉坐标与 DOM 序不一致”标记为顺序跳跃，建议调整 DOM 位置或改用合理的 tabindex 策略。