想象你是一栋“数字大楼”的总管。大楼里的住客形形色色：有人坐轮椅、有人视力模糊、有人上了年纪手指不太灵活。如果大门只有台阶、电梯按钮小得看不清、通知只用纯英文播报，你就会流失一大部分访客——网站也是如此。无障碍，英文写作 Accessibility，缩写为 A11y，正是给数字产品装上“坡道、扶手与大字标识”的工程。 A11y 测试自动化，就是给这座大楼配备一支“永不疲倦的安检巡逻队”；而 CI（持续集成）集成，则是把安检闸机装进每一次“装修改造”的施工流程——随便改动哪面墙，都必须先过安检才能交付使用。近来，AI 又给巡逻队装上了“会看、会想、会写整改单”的智能大脑：能模拟色盲住户的视角，能自动生成图片文字描述，还能把一堆问题清单整理成可执行的维修任务。这篇文章，我们就从给数字大楼搭建这套智能安检体系说起。

岗位关联

掌握 A11y 测试自动化与 CI 集成，能让你在真实工程中持续保障产品的无障碍质量，也让你在“AI 辅助前端”的团队里拥有可落地的核心竞争力。

目录
  1. 可视化演示
  2. A11y基础认知：数字大楼的宜居标准
  3. 自动化测试工具：巡检工具箱
  4. 测试规则体系：安检清单上的关键项
  5. CI流水线集成：每次改造后的强制验收
  6. 分层测试策略：多道安检防线
  7. AI增强赋能：会思考的智能巡检
  8. 排障与优化：让安检系统自己不堵车
  9. AI 应用场景
  10. Python 演示
  11. 常见误区
  12. 面试题

可视化演示

演示axe-core无障碍检测流程、CI/CD流水线集成架构及违规严重度分级与AI修复建议，直观展示A11y自动化测试原理。

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

axe-core检测流程 DOM遍历匹配WCAG规则集自动检测 30%规则可自动检测其余需人工审核 violations=axe-core(DOM,rules) axe-core引擎遍历DOM节点匹配WCAG规则生成违规报告

A11y基础认知：数字大楼的宜居标准

一段合格的物业公约，既要管得住乱堆杂物，也要保证轮椅能进电梯。A11y 的世界同样如此——它首先是一套“宜居标准”：任何用户，无论视力、听力、行动力或认知能力如何，都应该能顺畅地使用网站。WCAG（Web 内容无障碍指南）就是这份标准，由 W3C 发布，全球通行。它把“宜居”拆成了四个大字：可感知、可操作、可理解、健壮性——简称 POUR。比如“可感知”要求图片有文字替代、视频有字幕；“可操作”要求所有功能都能用键盘走通；“健壮性”则要求代码能被屏幕阅读器等辅助技术正确解析。

为什么要由 WCAG 牵头定义这些标准？因为只有先定出“合格线”，后面所有的自动巡检工具才有检查依据。这条合格线的数学基础之一，是对颜色的量化：WCAG 用“相对亮度”描述一个颜色到底有多亮。相对亮度不是简单地取 RGB 的平均值，而是模拟人眼对三种颜色的敏感度差异——就像物业规定楼道灯光要达到多少流明，不能只看灯泡瓦数。

有了亮度的量化标尺，数字大楼的“灯光检查”才算有据可依。但标准再完善，靠人工一条条核对也太慢——这就要请出自动化巡检队伍了。

L=0.2126×Rlinear+0.7152×Glinear+0.0722×BlinearL = 0.2126 \times R_{linear} + 0.7152 \times G_{linear} + 0.0722 \times B_{linear}
人眼对绿色最敏感、蓝色最迟钝，所以绿色通道的权重最高；这条公式把任意颜色压缩成 0 到 1 之间的一个亮度值，是后面对比度检查的基石。
  1. 线性化处理先把 sRGB 的颜色分量从“显示编码”还原为“物理光强”，否则直接加权会失真。
    clinear={c12.92,c≤0.04045(c+0.0551.055)2.4,c>0.04045c_{linear} = \begin{cases} \dfrac{c}{12.92}, & c \le 0.04045 \\ \left(\dfrac{c+0.055}{1.055}\right)^{2.4}, & c > 0.04045 \end{cases}
  2. 三通道加权将线性化的 R、G、B 按人眼敏感度加权求和，得到单一亮度值。
    L=0.2126×Rlinear+0.7152×Glinear+0.0722×BlinearL = 0.2126 \times R_{linear} + 0.7152 \times G_{linear} + 0.0722 \times B_{linear}
  3. 亮度取值域L 落在 0 到 1 之间，纯黑为 0，纯白为 1，作为后续对比度比值的输入。
    0≤L≤10 \le L \le 1

自动化测试工具：巡检工具箱

物业给巡逻队配什么装备，决定了检查效率。A11y 自动化生态里也有四件常用工具。第一件是 axe-core：它像一个“规则引擎大脑”，被注入浏览器后，会自动遍历页面 DOM，对照 WCAG 规则产出结构化 JSON 报告，是目前多数扫描工具的底层核心。第二件是 Lighthouse，Chrome 团队出品的“全身体检仪”，除了无障碍还会评估性能、SEO 等，给页面打一个综合分。第三件是 Pa11y，轻量级哨兵，走命令行，适合小项目或快速反馈。第四件是 jest-axe，它把 axe-core 嵌进 Jest 测试框架，让你在组件测试里直接断言“这个组件无障碍达标”。

工具虽多，覆盖却有限。WCAG 2.x 有成百条成功标准，其中能被工具自动判定的只是一部分，其余需要人工或 AI 配合。我们用“规则覆盖率”来量化工具能扛多少活：

工具箱备齐后，巡逻队需要一份“重点检查清单”。清单上最醒目的一项，就是文字与背景的颜色对比度。

Crules=NautoNwcag×100%C_{rules} = \dfrac{N_{auto}}{N_{wcag}} \times 100\%
这个比例通常只有三到五成——自动工具擅长检查“颜色有没有对比度、按钮有没有名字”，不擅长判断“用户的真实体验顺不顺”。
  1. 分子定义N_auto 表示自动化工具能稳定、无歧义检查的规则条目数，如对比度阈值、alt 缺失。
    Nauto=可自动判定的 WCAG 成功标准条数N_{auto} = \text{可自动判定的 WCAG 成功标准条数}
  2. 分母定义N_wcag 表示 WCAG 2.x 中所有成功标准的总数，它是人工与自动共同面对的完整清单。
    Nwcag=WCAG 2.x 成功标准总条数N_{wcag} = \text{WCAG 2.x 成功标准总条数}
  3. 覆盖率意义C_rules 落在约 30%-50%，提醒我们自动扫描只是第一道防线，需要分层策略兜底。
    30%≤Crules≤50%30\% \le C_{rules} \le 50\%

测试规则体系：安检清单上的关键项

安检清单上密密麻麻写满了检查项，但排在最前面的永远是那几个高危项。第一，颜色对比度：灰底灰字对视力不佳的住客就是隐形文字。第二，ARIA 属性校验：ARIA 是给屏幕阅读器看的“附加说明标签”，写错或滥用反而会让读屏软件更糊涂。第三，可访问名称：每个按钮、链接、图片都必须有一个“名牌”，读完就知道它干嘛用。第四，错误分级：扫描结果按 critical、serious、moderate、minor 分四档，critical 先修，minor 排期。

颜色对比度是整个清单里最有数学味的规则。WCAG 规定，正文文字与背景的对比度至少达到 4.5:1（AA 级），大号文字可以放宽到 3:1，高要求（AAA 级）则是 7:1。这个比值不是简单“谁亮谁暗”的减法，而是用前文算出的相对亮度做除法：

清单写好了，巡逻队正式上岗。可单靠“手动呼叫巡逻队”不行，真正让安检制度落地的是把它装进 CI 流水线——让每一次代码改动都自动过闸。

C=Llight+0.05Ldark+0.05C = \dfrac{L_{light} + 0.05}{L_{dark} + 0.05}
公式里加的 0.05 相当于“环境杂光”，避免纯黑背景导致分母为零；比值越大，文字越容易辨认。4.5:1 是硬杠杠，低于它 CI 闸机就要亮红灯。
  1. 亮度取大取小L_light 取两个颜色中相对亮度较大的，L_dark 取较小的，保证比值不小于 1。
    Llight=max⁡(L1,L2),Ldark=min⁡(L1,L2)L_{light} = \max(L_1, L_2), \quad L_{dark} = \min(L_1, L_2)
  2. 加 0.05 修正模拟真实屏幕的残余环境光，同时防止除以零引发计算异常。
    Ldark+0.05>0L_{dark} + 0.05 > 0
  3. 比值范围C 的理论范围是 1 到 21（纯黑对纯白），实际判定只需与阈值比较。
    1≤C≤211 \le C \le 21
  4. 阈值判定正文需要 C ≥ 4.5 才算通过 AA 级，这也是 CI 门禁里最常见的默认参数。
    C≥4.5C \ge 4.5

CI流水线集成：每次改造后的强制验收

大楼有自己的装修制度：任何改造动工前，工程队必须先在闸机前排队。CI 里的 A11y 测试就是这个闸机。以 GitHub Actions 为例：开发者提交 Pull Request 后，流水线自动拉取代码、安装依赖、运行 axe 扫描、生成报告并上传工件。扫描分数低于阈值，流水线立即失败，PR 上出现一个刺眼的红叉——没人能绕过它合并代码。

闸机背后是一套“质量门禁”规则。我们把扫描到的所有规则视为一次加权评分：critical 级别的违规权重更高，一道严重违规足以让总分跌破阈值。公式如下：

除了硬性门禁，还有“基线对比”：把本次得分与上次基线比，允许小范围浮动，防止动态内容的偶发抖动引发误报。可一旦有了门禁，问题又来了——全站几万个页面每次全量扫，速度慢得让人想拆闸机。

Q=∑i=1nwisi∑i=1nwi≥TgateQ = \dfrac{\sum_{i=1}^{n} w_i s_i}{\sum_{i=1}^{n} w_i} \ge T_{gate}
简单说：每个页面按规则逐项打分（过=100，不过=0），再按严重级别加权平均，最后和“门槛分”比较。门槛一卡，劣质改造就别想混进住区。
  1. 单项得分s_i 是第 i 条规则的得分，通过取 100，不通过取 0，违规级别越高此项越致命。
    si={100,规则  i  通过0,规则  i  违规s_i = \begin{cases} 100, & \text{规则} \; i \; \text{通过} \\ 0, & \text{规则} \; i \; \text{违规} \end{cases}
  2. 权重加权w_i 是第 i 条规则的权重，critical 最高，minor 最低，体现“严重问题一票否决”。
    wcritical>wserious>wmoderate>wminorw_{critical} > w_{serious} > w_{moderate} > w_{minor}
  3. 归一化平均分子是加权总分，分母是权重总和，Q 落在 0-100 区间，便于统一设阈值。
    0≤Q≤1000 \le Q \le 100
  4. 门禁判定T_gate 一般设为 90 或 95，低于阈值流水线失败，配合 GitHub 的 branch protection 阻断合并。
    Q<Tgate⇒流水线失败Q < T_{gate} \Rightarrow \text{流水线失败}

分层测试策略：多道安检防线

小区绝不会只在大门设一个保安。A11y 测试同样讲究分层设防。第一层是“编码时静态检查”：eslint-plugin-jsx-a11y 在你敲代码的瞬间就提示“图片缺 alt、按钮没名字”，把低级错误扼杀在襁褓。第二层是“组件测试”：jest-axe 在渲染组件时断言 expect(...).toBeAccessible()，保证每个独立部件合格。第三层是“端到端扫描”：Lighthouse CI 或 Pa11y 在真实浏览器里对整页做全身体检，抓住组件拼装后才出现的组合问题。第四层是“人工复核”：自动化测不了的焦点顺序、屏幕阅读器真实体验，交给专人抽样审计。

四道防线各有检出率，组合起来威力惊人。如果每层自动化检测只能抓出 70% 的问题，单独靠一层就有三成漏网；但四层独立捕捉后，全部漏掉的概率会急剧下降。这正是“多道安检”的数学底气：

防线虽密，但“按图索骥”的自动工具终究看不穿所有障眼法。这时 AI 登场，给安检体系装上了一颗会思考的智能大脑。

Ctotal=1−∏i=1k(1−Ci)C_{total} = 1 - \prod_{i=1}^{k} (1 - C_i)
每层漏检率相乘，整体漏检率就趋近于零。比如 4 层各 70% 检出率，最终综合检出率约 99.2%。
  1. 单层漏检率(1 - C_i) 表示第 i 层防线漏掉问题的比例，比如检出率 70% 就意味着漏掉 30%。
    1−Ci=第  i  层漏检率1 - C_i = \text{第} \; i \; \text{层漏检率}
  2. 乘积为全漏概率各层独立时，问题同时被所有层漏掉的概率等于逐层漏检率的连乘。
    ∏i=1k(1−Ci)\prod_{i=1}^{k} (1 - C_i)
  3. 整体检出率用 1 减去全漏概率，得到至少被一层抓住的概率 C_total。
    Ctotal=1−∏i=1k(1−Ci)⏟全漏概率C_{total} = 1 - \underbrace{\prod_{i=1}^{k} (1 - C_i)}_{\text{全漏概率}}
  4. 数值直觉四层各 70% 时，1 - 0.3^4 = 0.9919，约等于 99.2%。
    1−0.34=0.99191 - 0.3^4 = 0.9919

AI增强赋能：会思考的智能巡检

传统巡逻队只能照本宣科，智能巡检却会“换位思考”。视觉 AI 模型能直接模拟色盲或低视力用户看到页面的样子，截图中大片灰扑扑的按钮立刻现形——这在纯 DOM 扫描里根本发现不了。大模型（LLM）则能读懂 axe 输出的 JSON 报告，直接生成修复建议：补一个 alt 属性、改一处 ARIA 角色，甚至给出整段替换代码。图像描述模型则帮巡逻队“代写名牌”：自动为没有 alt 的图片生成一句话描述。缺陷聚类脚本更像一个聪明的档案管理员，把几百条相似违规归并成几类，工程师改一处模板就能修复一片。

AI 的产出当然不能盲目全收。业内常用“修复采纳率”来度量 AI 建议质量——工程师采纳了多少条 AI 的建议：

AI 让巡检大队变得聪明了，但在真实工程里，安检设备也会遭遇自己的“堵车”和“狼来了”。

A=NacceptedNsuggested×100%A = \dfrac{N_{accepted}}{N_{suggested}} \times 100\%
采纳率超过 50%，说明 AI 建议基本靠谱，可以直接批处理；低于 30%，说明需要调 prompt 或换更专业的模型。
  1. 建议总数N_suggested 是 AI 在一轮扫描后生成的全部修复建议条数。
    Nsuggested=AI 生成的建议总数N_{suggested} = \text{AI 生成的建议总数}
  2. 采纳总数N_accepted 是开发者实际接受并合入代码的建议条数。
    Naccepted=人工采纳的建议条数N_{accepted} = \text{人工采纳的建议条数}
  3. 采纳率计算两者之比乘以 100%，得到 0 到 100 的百分比，用于量化 AI 质量。
    0%≤A≤100%0\% \le A \le 100\%

排障与优化：让安检系统自己不堵车

再好的安检系统，跑得慢、误报多，也会被工程团队嫌弃。第一个坎是“运行耗时”：大型站点几百个页面，每次 PR 全量扫描动辄几分钟，开发者等得不耐烦就偷偷绕行。对策是增量扫描——只测本次变更涉及的页面。加速比一目了然：

第二个坎是“误报治理”。动态页面内容频繁变化，基线分数经常上下抖动，容易导致“狼来了”。对策是引入容忍带和白名单：允许分数在 ±2 分内波动，确认为误报的规则在配置中注明理由并豁免。第三个坎是“责任落地”：扫描发现的违规要自动创建 GitHub Issue，@到组件负责人，并同步到团队看板。最后用趋势图持续跟踪：每两周看一次无障碍分数曲线，上升要庆祝，下降要复盘。

Sincr=NpagesNchangedS_{incr} = \dfrac{N_{pages}}{N_{changed}}
100 个页面只改了 2 个，加速比就是 50 倍。再配合 CI 矩阵并行分片，把全量扫描拆成多个 job 同时跑，总时长可压到 1 分钟内。
  1. 页面总数N_pages 是站点需要纳入 A11y 巡检的总页面数。
    Npages=站点总页面数N_{pages} = \text{站点总页面数}
  2. 变更页面数N_changed 是本次提交实际影响到的页面数，通常远小于总数。
    Nchanged=本次变更涉及的页面数N_{changed} = \text{本次变更涉及的页面数}
  3. 加速比两者相除得到增量扫描相对全量扫描的提速倍数。
    Sincr=NpagesNchangedS_{incr} = \dfrac{N_{pages}}{N_{changed}}

AI 应用场景

设计系统组件的 A11y 质量门禁

阶段：CI 集成 / 质量保障

解决的问题：中后台设计系统组件库动辄上百个组件，一次按钮配色调整就可能让对比度跌破 4.5:1。传统人工抽查既慢又漏，问题往往上线后由真实用户投诉才发现。

具体案例：某电商团队在每个组件的 Demo 页接入 axe-core 扫描，PR 触发 GitHub Actions。某次按钮组件把文字色从 #333333 改成 #777777，CI 门禁立刻变红；AI 助手读取对比度报告，自动推荐 #595959 作为可替换色值，并附带一行修复代码。开发一键合入，问题在合并前就被化解。

大型内容站点的视力障碍巡检

阶段：持续监控 / AI 视觉增强

解决的问题：资讯类站点每天新增成千上万张配图，纯 DOM 扫描无法判断“图里有没有文字、文字和背景混不混”。传统做法只能人工抽查，覆盖面不足 1%。

具体案例：某新闻网站用 Lighthouse CI 每周对全站抽样页面跑一遍无障碍体检，同时引入视觉 AI 滤镜模拟色盲和低视力模糊视角，捕捉多处“视觉上几乎隐形”的按钮。随后图像描述模型自动为缺失 alt 的配图生成一句话说明，并批量创建 Issue 分配给相关编辑。

高流量表单页的无障碍保障

阶段：开发期 / AI 辅助代码评审

解决的问题：表单校验错误提示如果只靠红框表达，色弱用户根本无法感知。传统 ESLint 规则检查不出这种“语义缺失”，因为错误提示的关联方式是运行时的。

具体案例：某金融平台注册页接入 LLM 代码评审助手。AI 阅读前端源码后提示：“金额输入框的校验错误仅用颜色表现，需补充 aria-describedby 关联错误文案，并设置 aria-live 区域让读屏软件自动播报。” 开发者点击采纳，提交的代码自动附带修改 diff，表单可访问性一次性达标。

Python 演示

python101 行
import refrom html.parser import HTMLParser  class A11yParser(HTMLParser):    """解析HTML并收集需要检查的元素"""     def __init__(self):        super().__init__()        self.imgs = []        self.buttons = []        self.links = []        self.inputs = []        self._current = None     def handle_starttag(self, tag, attrs):        item = dict(attrs)        if tag == "img":            self.imgs.append(item)        elif tag == "button":            self.buttons.append(item)        elif tag == "a":            self.links.append(item)        elif tag == "input":            self.inputs.append(item)     def handle_data(self, data):        text = data.strip()        if text:            self._current = text  def relative_luminance(hex_color):    """把#RRGGBB转成WCAG相对亮度L"""    hex_color = hex_color.lstrip("#")    rgb = [int(hex_color[i:i + 2], 16) / 255.0 for i in (0, 2, 4)]    linear = []    for c in rgb:        if c <= 0.04045:            linear.append(c / 12.92)        else:            linear.append(((c + 0.055) / 1.055) ** 2.4)    return 0.2126 * linear[0] + 0.7152 * linear[1] + 0.0722 * linear[2]  def contrast_ratio(c1, c2):    """计算两个颜色的对比度"""    l1, l2 = relative_luminance(c1), relative_luminance(c2)    if l1 < l2:        l1, l2 = l2, l1    return (l1 + 0.05) / (l2 + 0.05)  def scan_html(html, text_color="#333333", bg_color="#FFFFFF"):    """对HTML片段做基础A11y扫描, 返回违规列表"""    parser = A11yParser()    parser.feed(html)    violations = []    for img in parser.imgs:        if not img.get("alt"):            violations.append("img缺少alt属性: src=" + str(img.get("src", "")))    for btn in parser.buttons:        if not btn.get("aria-label"):            violations.append("button缺少aria-label或文本内容")    for link in parser.links:        if not link.get("aria-label"):            violations.append("a标签缺少aria-label")    for inp in parser.inputs:        if not inp.get("aria-label") and not inp.get("id"):            violations.append("input缺少可访问名称")    ratio = contrast_ratio(text_color, bg_color)    if ratio < 4.5:        violations.append("文字对比度不足: %.2f:1 < 4.5:1" % ratio)    return violations, ratio  def main():    html = """    <img src="banner.png">    <button aria-label="提交">提交</button>    <a href="/help">帮助中心</a>    <input id="email" aria-label="邮箱">    """    violations, ratio = scan_html(html, text_color="#777777", bg_color="#FFFFFF")    total_checks = 5    non_contrast = [v for v in violations if "对比度" not in v]    passed = total_checks - len(non_contrast)    if ratio < 4.5:        passed -= 1    score = max(0, round(passed / total_checks * 100))    print("扫描完成 对比度=%.2f:1 得分=%d" % (ratio, score))    for v in violations:        print("  [拦截]", v)    threshold = 80    passed_ci = score >= threshold    print("CI门禁: ", "通过(PASS)" if passed_ci else "未通过(FAIL) - 阻止合并")    return 0 if passed_ci else 1  if __name__ == "__main__":    raise SystemExit(main())
目的：用 Python 模拟一个极简 A11y 扫描器，检查 HTML 里 img/button/a/input 的可访问名称，并用 WCAG 公式计算文字对比度，最后按 80 分阈值模拟 CI 门禁判定。
  1. parser.feed(html)把 HTML 字符串喂给解析器，触发 handle_starttag 逐个收集可疑元素。
  2. if not img.get("alt"):图片没有 alt 属性即视为违规，这是可感知原则里最基础的检查。
  3. l1, l2 = relative_luminance(c1), relative_luminance(c2)先将两个十六进制颜色分别换算成相对亮度。
  4. return (l1 + 0.05) / (l2 + 0.05)这就是正文里的对比度公式，先保证 L1 是较亮的那个再相除。
  5. passed = total_checks - len(non_contrast)用总检查项减去违规项得到通过数，得出本次扫描得分。
  6. passed_ci = score >= threshold得分不低于 80 分门禁才放行，对应 CI 集成里的质量闸机。

常见误区

误区我以为 CI 里跑完 axe 扫描，报告全绿，网站就完全符合 WCAG 了，可以放心上线。

正解自动化工具只能覆盖约三到五成的 WCAG 成功标准。对比度、alt 缺失、ARIA 写法这类“规则明确”的能查；但键盘焦点顺序、读屏软件的真实朗读体验、认知障碍用户的理解难度，机器几乎测不准。全绿只代表“自动可查的部分合格”，如同安检机查得出刀具，查不出乘客的紧张情绪。

为何常见：因为工具报告看起来非常权威，红绿对错一目了然，容易让人误以为它就是全部标准。

误区全站几百个页面，每次提交都扫描要好几分钟，CI 被拖垮，干脆只在发版前手动跑一次。

正解慢的根源是“全量扫描”，解法是增量扫描、并行分片、只跑关键路径。把扫描从“低频发版抽查”改成“每次提交自动挡”，修复成本从上线后的紧急返工降为合并前的五分钟改动，性价比完全不同。这就像大楼不能因为安检排队久就撤掉闸机，而是要把闸机设计成多条通道并行。

为何常见：初见工具时直接全量接入，没有做分层和增量设计，体验过一次“等半天”就留下了坏印象。

误区遇到按钮没名字、图片没文字，我第一反应就是加一个 aria-label，觉得万能补丁。

正解ARIA 是给辅助技术的“补充说明”，不是无脑贴膏药。aria-hidden="true" 放在可聚焦元素上会直接让读屏用户迷失；role 乱写会覆盖原生语义，比如把 <button> 改成 role="link" 反而让快捷键行为错乱。正确的优先级永远是“原生语义优先”：能用 <button>、<label> 就不用 ARIA 硬凑，ARIA 只用来补原生标签表达不了的信息。

为何常见：ARIA 属性看起来就是“加上就懂了”的魔法属性，教程里大量成功案例让初学者误以为它是保险杠。

误区大模型自动生成的图片描述那么通顺，直接填进 alt 属性不就行了？省得人工写。

正解AI 图像描述可能不准确、忽略关键信息，甚至延续训练数据里的偏见。比如一张“车祸现场警示图”被浪漫化描述成“夕阳下的街道”，视障用户会被误导。金融、医疗等严肃场景必须人工校对；一般场景也应把 AI 描述作为初稿，由人工确认后再上线。

为何常见：因为大模型生成文本太流畅，流畅性会制造“正确感”，让人放松了事实核查。

误区自动化报告显示所有文字对比度都 ≥ 4.5:1，我就认为色弱用户也能看清。

正解4.5:1 计算的是“亮度差”，没有覆盖“色相差”。红绿色弱用户可能无法区分同样亮度的红与绿，即使亮度对比达标，表单的“通过/失败”两个状态依然分不清。所以颜色不能作为唯一信息载体，必须配合图标、文字或下划线等辅助标识。

为何常见：因为对比度是少数能用公式算的规则，工具一测就出数字，让人误以为“数字达标=视觉安全”。

面试题

Q1. A11y 这个缩写中，数字 11 代表什么？

单选题 · easy

  • A.首尾字母夹着 11 个字母← 正确答案
  • B.WCAG 中 11 项核心检查
  • C.11 种主流辅助技术
  • D.对比度 11:1 的超级阈值

答案：A。Accessibility 的首字母 a 与尾字母 y 之间正好隔着 11 个字母，所以简写为 A11y。B、C、D 都是编造的“看似合理”的数字，记住“11 = 字母数”就永远不会错。

Q2. WCAG 四大原则 POUR 中，P 代表什么？

单选题 · easy

  • A.Perceivable 可感知← 正确答案
  • B.Protective 防护性
  • C.Personalized 个性化
  • D.Procedural 流程化

答案：A。POUR 分别是可感知、可操作、可理解、健壮性。可感知强调信息能通过多种感官获取，比如图片要 alt、视频要字幕。其他三个选项只是以 P 开头的干扰词，与内容无障碍无关。

Q3. 文字对比度达到 WCAG AA 级至少需要多大比例？

单选题 · easy

  • A.需要达到 3 比 1
  • B.需要达到 4.5 比 1← 正确答案
  • C.需要达到 7 比 1
  • D.需要达到 10 比 1

答案：B。正文默认要求 4.5:1（AA 级）；大号文字（18pt 以上）放宽到 3:1；7:1 是 AAA 级。记住“正文起步 4.5”就够用，3:1 是大字的特权，7:1 是更高追求。

Q4. axe-core 在前端 A11y 体系中的主要作用是什么？

单选题 · mid

  • A.浏览器性能分析
  • B.无障碍规则扫描← 正确答案
  • C.网络请求拦截
  • D.前端构建打包

答案：B。axe-core 是 Deque 公司开源的规则引擎，会遍历 DOM 对照 WCAG 规则输出违规 JSON。性能分析是 Lighthouse 附带的能力，网络拦截是抓包工具的活，打包是 webpack 的职责，三者都不属于 axe-core 的核心定位。

Q5. CI 中质量门禁（Quality Gate）未通过时会发生什么？

单选题 · mid

  • A.跳过部署直接合并
  • B.发出警告后部署放行
  • C.流水线失败并拦截合并← 正确答案
  • D.自动修复所有缺陷

答案：C。质量门禁的本质是“硬性闸机”：评分低于阈值，job 返回非零退出码，流水线标红。配合分支保护规则后，PR 无法合并。跳过部署、警告放行违背门禁初衷；自动修复是 AI 增强的方向，不是门禁本身的默认行为。

Q6. jest-axe 最适合放在 A11y 测试分层中的哪一层？

单选题 · mid

  • A.组件测试层← 正确答案
  • B.端到端测试层
  • C.人工审计环节
  • D.数据存储层

答案：A。jest-axe 把 axe-core 封装成 Jest 自定义匹配器，让你在渲染组件后直接写 expect(container).toBeAccessible()。它天然属于组件测试层；端到端层用 Pa11y 或 Lighthouse CI，人工审计测的是自动化盲区。

Q7. 增量扫描相比全量扫描的加速比如何计算？

单选题 · hard

  • A.页面总数除以变更页面数← 正确答案
  • B.变更页面数除以页面总数
  • C.测试用例总数除以变更数
  • D.扫描耗时乘以页面数量

答案：A。只测变更页面时，加速比 = 总页面数 ÷ 变更页面数。比如 100 页的站点本次改了 2 页，加速比就是 50 倍。选项 B 是倒数，方向反了；C、D 与加速比定义无关。

Q8. 以下哪些属于常见的 A11y 自动化测试工具？

多选题 · mid

  • A.axe-core 规则引擎← 正确答案
  • B.Lighthouse 评分工具← 正确答案
  • C.Docker 容器引擎
  • D.Pa11y 命令行工具← 正确答案

答案：ABD。axe-core、Lighthouse、Pa11y 都直接服务于 A11y 扫描。Docker 是容器化部署工具，虽然可以在容器里跑 A11y 测试，但它本身不是无障碍测试工具，所以不选。

Q9. 自动化 A11y 扫描通常难以检测哪些问题？

多选题 · hard

  • A.键盘焦点顺序合理性← 正确答案
  • B.图片语义描述的准确性← 正确答案
  • C.文字背景颜色对比度
  • D.屏幕阅读器真实体验← 正确答案

答案：ABD。对比度是公式可计算的，工具能精确判定，属于自动化强项。焦点顺序需要人工走 Tab 验证；语义描述准确性依赖上下文理解；读屏体验是动态朗读过程，三者机器都难以可靠评估，需要人工复核或 AI 辅助。

Q10. 关于 AI 增强 A11y 测试，下列说法哪些是正确的？

多选题 · extreme

  • A.视觉 AI 可模拟色盲视角← 正确答案
  • B.大模型能生成修复代码← 正确答案
  • C.AI 生成的 alt 永远准确
  • D.缺陷聚类减少人工审阅← 正确答案

答案：ABD。视觉 AI 可以套用色盲滤镜做截图分析，LLM 能根据 axe 报告输出修复建议，聚类能把相似问题归并从而减少人工审阅量。C 错在“永远”——AI 生成的 alt 可能不准确甚至带偏见，必须人工校对。