企业官网建设流程全解析

做了多年测试开发，我越来越觉得无障碍测试是自动化体系里最难啃的一块。功能回归有接口测试、UI自动化兜底，性能有压测平台，唯独无障碍，很多团队到现在还停留在"发版前找几个屏幕阅读器手动过一遍"的阶段——费时费力，还特别看测试人员对读屏软件熟不熟练。我做的这个项目，就是尝试用AI构建一个能模拟视障用户交互意图的验证工具，把无障碍测试从"人肉巡检"变成可复现、可量化、可回归的自动化环节。这篇文章会把这个工具的完整设计思路、核心模块、实操过程和踩坑记录都摊开来讲，最适合正在做无障碍适配、想给测试体系补上这块短板的测试开发和前端团队参考。

1. 项目背景与设计思路

1.1 为什么传统自动化测试测不出视障用户的问题

先澄清一个很多人没意识到的认知偏差：传统UI自动化（哪怕是现在的AI自动化测试）默认交互方式都是"鼠标点击 + 屏幕视觉反馈"。脚本模拟的是明眼用户的行为路径：看到按钮、定位坐标、点击、断言页面变化。但视障用户完全不是这个操作逻辑。

屏幕阅读器用户的操作核心是焦点（focus）和读屏报读。用户按Tab键逐个移动焦点，听读屏软件报出当前聚焦控件的名称、角色、状态，然后按Enter或者空格激活。整个过程里没有"看到"这个概念，任何依赖视觉位置的自动化断言在这里都不成立。再加上地理语义很重要——用户在按Tab时感知的是"焦点顺序是否符合预期"，而不是"屏幕上元素有没有对齐"。

所以传统的click(x, y)式的自动化，本质上是在测试一个视障用户根本不会使用的交互路径。这个错位导致了一个很典型的现象：无障碍适配问题在功能测试里完全测不出来，等到真上了读屏软件人工过一遍，才发现焦点顺序乱得像一团麻、一堆按钮没有可访问名称、弹窗关不掉。我决定做这个工具，核心出发点就是解决传统自动化与视障交互方式之间的这个结构性错位。

1.2 核心思路：把"交互意图"变成可模拟、可断言的验证目标

这个项目叫"视障用户交互意图的模拟验证工具"。拆解开就是三个关键词：交互意图、模拟、验证。交互意图指的是用户通过键盘和读屏操作想要触达的业务目标，比如"提交当前表单"、"返回上一级"、"在搜索结果中打开第二项"。模拟是指让AI按视障用户的交互方式——Tab流、箭头导航、组合快捷键——去执行操作，而不是按坐标点击。验证是指在执行过程中和结束后，对无障碍树、焦点序列、读屏语义做结构化断言。

这个思路最简单粗暴的版本，其实是一套"无障碍回归脚本"：定义好交互意图对应的操作序列，然后用自动化按Tab、按Enter，跑完做断言。但这样有两个很现实的问题。第一，每个页面流程的交互序列得人工梳理，工作量大。第二，读屏用户的真实行为是有探索性的，用户可能按上箭头而不是Tab，可能直接点击屏幕上的元素，这套"死脚本"没法覆盖。所以这个项目引入了AI：用真实视障用户的操作数据训练一个意图识别模型，让自动化具备"根据页面状态动态选择下一步操作"的能力。这个能力，才是让无障碍测试从"脚本巡检"走向"行为模拟"的关键。

2. 无障碍测试的核心概念与技术底座

2.1 POUR原则和几个绕不开的无障碍知识点

进入实现之前，先把底层规范过一遍。无障碍测试的黄金标准是WCAG 2.2，里面内容很多，但对于自动化验证来说最核心的是POUR四项原则（可感知、可操作、可理解、健壮）。每一项落到技术上都有对应的检查点。例如：

• 可感知：所有功能有文本替代（alt、aria-label），对比度达标。
• 可操作：所有操作可用键盘完成，焦点顺序合理，焦点可见。
• 可理解：组件状态有明确语义提示（比如"已展开/已折叠"），报错信息文本可读。
• 健壮：无障碍树中控件的角色、属性、值能被辅助技术正确解析。

这里有个关键概念叫"无障碍树"（Accessibility Tree）。它不是DOM，而是浏览器根据DOM和ARIA属性加工后、把页面语义暴露给辅助技术的精简树。普通开发者看到的是div套div，读屏用户听到的是"导航栏"、"按钮"、"展开/折叠状态"。这两个树经常不一致，而无障碍测试本质上是验证无障碍树是否符合预期。

另外一个必须理解的是ARIA的"五大概述"：角色、属性、状态、焦点管理、键盘交互。role表示控件类型，aria-expanded表示展开状态，tabindex决定焦点可达性，而键盘交互规定了一个组件应该响应哪些按键事件。这套语义是AI模型识别交互意图的原料，也是断言引擎判断页面是否合规的依据。想把这个工具做出来，这些概念是绕不开的。

2.2 读屏软件下真实交互的三种形态

要模拟视障用户的交互，就得先搞清楚视障用户到底怎么操作软件。根据我的观察，读屏用户的操作方式大体分为三类。

第一类是纯键盘导航，也是最常见、最容易模拟的形态。用户通过Tab、Shift+Tab在可聚焦元素间移动，用方向键在列表、菜单、单选组内部切换，用Enter或空格激活控件。这套操作在PC端的NVDA和VoiceOver下高度一致，适合作为模拟执行的基线。

第二类是触屏手势与焦点滑动。在移动端，TalkBack和VoiceOver的默认触摸模式是"触摸并滑动"：用户滑动手指从屏幕顶部向下移动，焦点会跟着手指位置跳到触摸到的每个可聚焦元素，听到报读后再双指双击（或单指双击）激活。这种模式下的交互意图不完全等同于键盘顺序，因为它和屏幕上的实际排列位置强相关。

第三类是快速启动与搜索命令。比如在NVDA里按Insert+F7调出"元素列表"，按B跳转按钮、按H跳转标题，或者通过"浏览模式"快速定位。这种交互其实暴露了一个常被忽略的需求：页面的标题、按钮文本、链接文本必须是清晰、有层次、有意义的，否则读屏用户连"空降"都没有目标。

工具要把这三种形态都覆盖才有说服力。纯键盘导航容易模拟，触屏手势需要对接移动端自动化框架的坐标滑动能力，而快速跳转命令则需要模拟虚拟浏览器的按键事件。这个项目的1.0版本核心覆盖第一种，第二种和第三种作为扩展模块逐步接入。

2.3 从DOM到无障碍树：模拟器读取的是什么数据

实现模拟之前，必须先解决"数据源"的问题。自动化脚本要验证无障碍语义，靠普通的DOM查询是不行的。比如一个div设置了role="button"，在DOM里看它还是div，但在无障碍树里它已经是一个按钮了。所以工具的基础能力是提取页面的无障碍树。

桌面端我推荐用Chrome DevTools Protocol（CDP）里Accessibility域的能力，或者直接用Playwright自带的page.accessibility快照接口。移动端在Android上可以通过UiAutomator的无障碍节点树拿到，iOS上可以用XCUITest的snapshot接口。这些接口返回的数据结构里包含每个节点的role、name、description、focusable、focus状态、是否在可点击列表里等关键属性。

提取到无障碍树之后，我还会做一步数据清洗：过滤掉不可见的节点（display:none、aria-hidden=true、off-screen）、把内嵌文本节点折叠成控件的可访问名称、标记focusable和tabIndex，最后生成一个带层级结构的JSON。这个清洗后的无障碍树，就是后续AI模型做意图预测和执行器做焦点导航的统一数据源。要注意的是，不同浏览器、不同版本的CDP返回字段并不完全一致，所以封装数据适配层会成为第一个容易踩坑的点。

3. 工具整体架构与关键模块实现

3.1 技术栈选型与理由

先交代技术选型。项目使用Python + Playwright，理由有三个层面。

第一，Playwright对跨浏览器和移动端的支持更现代，尤其是它通过CDP对标签页、无障碍树、输入事件有细粒度控制，这正好是焦点导航模拟需要的底层能力。

第二，Playwright的移动模拟能处理触屏手势和虚拟焦点，为后续覆盖TalkBack/VoiceOver场景留好了扩展空间。相比Selenium还必须借助第三方库才能做到这些，Playwright在反馈生成速度和可靠性上也更胜一筹。

第三，模型侧需要底层控制力强的AI框架，Python生态最方便。意图识别模块先用PyTorch训练一个轻量级序列分类器，也可以对接大模型API做语义理解，这种混合方案在Python里都能平滑实现。

3.2 模块一：无障碍树采集与处理

这个模块承担的是"底层世界的信息输入"。

代码上核心逻辑不复杂，但细节很多。我用page.accessibility的snapshot()方法拿到原始树，然后写一个递归处理器，遍历所有节点并做三件事：按可见性过滤、按语义属性补全（角色映射、可访问名称拼接）、生成节点ID并维护父子关系。处理之后的无障碍树会提交给一个全局状态管理器，后面的意图模型和执行器都从这个状态管理器读数据。

真实实践里有个问题必须提：CDP的Accessibility tree并不是总返回完整的全量树，而是带有懒展开语义的"稀疏树"，某些节点在未被聚焦或展开时属性可能不完整。所以我在代码里设定了一个"最小完整节点"的判断逻辑：如果当前快照中可聚焦节点的角色、名称都不全，就要用DOM查询做一次兜底补齐。算是一个很实用的小坑后处理。

import json from playwright.sync_api import sync_playwright class AccessibilityTreeExtractor: def __init__(self, page): self.page = page def get_clean_tree(self): raw = self.page.accessibility.snapshot() cleaned = self._clean_node(raw) return cleaned def _clean_node(self, node): result = { "node_id": node.get("nodeId"), "role": node.get("role", {}).get("value", "generic") if isinstance(node.get("role"), dict) else node.get("role", "generic"), "name": node.get("name", {}).get("value", "") if isinstance(node.get("name"), dict) else node.get("name", ""), "focusable": node.get("properties", {}).get("focusable", False), "disabled": node.get("properties", {}).get("disabled", False), "hidden": node.get("hidden", False), "children": [] } if result["hidden"]: return None for child in node.get("children", []): cleaned_child = self._clean_node(child) if cleaned_child: result["children"].append(cleaned_child) return result

这段代码虽然简单，但它是整个AI模拟验证工具的“地面测绘”，没有一份干净、完整、语义正确的无障碍树，后面所有意图理解都是空中楼阁。我建议任何想做类似项目的团队，第一个迭代周期就死磕这个模块，把它做到稳定再往下走。

3.3 模块二：AI交互意图识别

这是整个工具里最"AI"的部分，也是区分"脚本巡检"和"行为模拟"的分水岭。

我设计的意图识别模块放弃了一上来就上大模型的捷径（虽然效果惊艳，但成本和延迟都很高），而是采用"特征提取 + 轻量级Transformer + 规则兜底"的混合方案。核心输入包括三类信号：当前焦点节点的无障碍属性、前序操作历史（最近5步的焦点变化和激活事件）、页面级的上下文特征（比如当前处在一个表单容器内）。输出是一个意图标签，例如next_focus、activate_current、search_jump、switch_browsing_mode、scroll_panel等。

训练数据从哪来？这是很多团队做AI测试时最头疼的问题。我的做法分两步。第一步是采集真实视障用户的操作日志，通过安装一段监控脚本记录用户在当前产品中的键盘事件、焦点变化、页面URL变化，脱敏后形成一个序列数据集。第二步是标注：让熟悉无障碍的测试同事对一段操作序列标注"这段操作用户想干什么"，一条序列可能标注多个意图，因为它可能对应一个较长的目标流程。这个过程产出的数据量不需要特别大，我实测下来，三千条左右高质量的序列就能让模型有可用的效果。

模型结构我用了轻量级的双向Transformer序列编码器，输入序列长度截取20步，每步的特征拼成一个embedding向量后过两层自注意力，最后接一个全连接层输出意图概率分布。推理延迟在CPU上大约50毫秒一次，完全够自动化测试使用。实际跑不动的环节反而不是模型推理，而是读屏软件启动和页面加载，这两块单次可能要好几秒。

import torch import torch.nn as nn class IntentionModel(nn.Module): def __init__(self, feat_dim, hidden_dim, num_intents, max_len=20, nhead=4, num_layers=2): super().__init__() self.input_fc = nn.Linear(feat_dim, hidden_dim) self.pos_encoding = nn.Parameter(torch.randn(1, max_len, hidden_dim)) encoder_layer = nn.TransformerEncoderLayer(d_model=hidden_dim, nhead=nhead, batch_first=True) self.encoder = nn.TransformerEncoder(encoder_layer, num_layers=num_layers) self.classifier = nn.Linear(hidden_dim, num_intents) def forward(self, x, mask): x = self.input_fc(x) x = x + self.pos_encoding[:, :x.size(1), :] x = self.encoder(x, src_key_padding_mask=mask) # 只取最后一个有效位置的向量去做分类 last_vec = x[torch.arange(x.size(0)), x.size(1) - 1 - mask.sum(dim=-1)] return self.classifier(last_vec)

这个模型不是万能的。真实用户的操作充满不可预测性，比如读屏软件版本不同导致焦点跳转行为不同，或者用户按了一个页面没有监听的热键。所以要加一层规则兜底：当模型输出的置信度低于0.6时，回退到贪心策略——默认执行next_focus，直到找下一个可聚焦节点，或者发现当前操作已经导致页面变化了，再重新提取无障碍树并继续预测。这套"AI为主、规则保底"的设计，让整个验证流程在真实环境中跑得非常稳，几乎没有模型完全失控的情况。

3.4 模块三：模拟执行器与验证断言

模拟执行器是整个工具动作输出的地方。它把AI模型预测出的意图映射成真实的键盘或手势事件。

意图映射表在设计上尽量跟读屏软件的按键约定保持一致：next_focus映射为Tab，prev_focus映射为Shift+Tab，activate_current映射为Enter或空格，jump_to_heading映射为NVDA的H键，open_element_list映射为NVDA的Insert+F7。映射层做成可配置的，因为在移动端TalkBack里没有Tab键，焦点滑动逻辑要换成swipe_to_next。

执行器的核心难点是焦点状态同步。每执行一个按键事件，执行器要立刻从页面读取当前的activeElement，并把它的无障碍树节点ID与上一轮写入日志。一旦发现焦点掉进了不可聚焦节点（比如body或某个没有tabindex的div），需要即时记录为"焦点漂移"问题，并执行备用策略：尝试找离当前最近的下一个可聚焦节点。

验证模块做的事可以总结为三层断言。第一层是静态语义断言，检查焦点所在节点的角色、名称、状态是否符合ARIA最佳实践，比如按钮有没有可访问名称、展开控件有没有aria-expanded、表单输入有没有label。第二层是流程完整性断言，验证一次意图目标（比如"完成下单"）对应的基本操作序列是否走得通。第三层是规范专项断言，对接axe-core规则库跑一次自动检测，再把规则库的结果整合到最终报告里。三层断言叠加，才能既发现"这个按钮没名字"的基础问题，也发现"整个流程走到第三步就走不下去"的行为级问题。

4. 完整实操：从零跑通一个视障交互验证用例

4.1 准备测试目标页面与实验环境

用配置和代码说话。我选取一个典型的电商下单页面作为目标：包含搜索框、商品列表、筛选区、结算入口。这个页面信息密度大，交互路径长，很适合验证工具能力。

环境准备上，用Playwright管理Chromium实例，并设置一个统一的视口和系统语言务。（顺序和细节要拉平，我需要更细致。）

pip install playwright torch python -m playwright install chromium

页面加载后第一时间提取无障碍树，并初始化一个空的"焦点日志"容器。这里有个重要经验：不要着急模拟操作，先做一次静态扫描，把页面本身不符合规范的点记录成“基线问题”。在实际项目中，很多页面第一次跑就会被发现几十个问题，其中一大部分是按钮没有可访问名称、图片没有alt文本、焦点顺序错乱。基于这些问题，再决定接下来模拟哪条交互路径。

4.2 编写意图模型与测试用例

工具使用过程中最频繁的操作是"定义验证路径"。我把一条验证路径定义成一个目标意图序列，比如：

1. 从首页搜索框导航到搜索结果
2. 在搜索结果中选中一个商品
3. 把商品加入购物车
4. 进入结算页面，填写收货地址
5. 提交订单

这个序列里的每一步，在实际执行时都会转化为无数小步的键盘焦点移动和激活操作。AI模型需要把这些上层的业务目标拆分成底层的原子操作序列。为了让模型对流程有更高层的理解，我在训练特征里加入了一个"目标状态"向量，比如"商品已加入购物车"是一个目标状态，"提交订单"又是一个目标状态。模型学会的是从一个目标状态到下一个目标状态的过程中，什么样的焦点操作序列是合理的。

scenario = { "name": "view_user_submit_order_flow", "entry_url": "https://example.com/search?q=laptop", "intents": [ {"goal": "focus_search_result", "expected_role": "link", "expected_name_contains": "Laptop"}, {"goal": "activate_search_result", "expected": "product_detail_open"}, {"goal": "add_to_cart", "expected": "cart_count_updated"}, {"goal": "goto_checkout", "expected": "checkout_page_loaded"}, {"goal": "submit_order", "expected": "order_success"} ] }

测试用例文件采用YAML或JSON描述，测试平台读取这个文件后会依次实例化执行器，跑完后生成结构化的报告。建议团队在这里建立基线用例库：每一个页面留档一份标准验证路径，发版前全量回归，这就是无障碍专项从"临时人工巡检"走向"持续回归"的转折点。

4.3 执行验证与结果分析

真正跑起来的时候，第一个印象是"执行速度比想象中慢"。一次包含20步焦点移动、5次激活操作的流程，加载页面加每一步之间人为故意加的模拟延迟（读屏用户操作节奏），平均耗时在30到60秒。首次跑完，我在一个自测项目中发现了三个比较典型的高价值问题，这里逐一展开。

第一个是焦点漂移：焦点从商品列表移动到"购物车"按钮时，没有任何可见焦点指示，读屏用户根本不知道焦点已经离开了列表区域。这个问题的根因是页面CSS里写了outline: none，但这不是读屏用户能感知的变化，所以只靠自动化对无障碍树做断言也不一定能完全捕获，必须在模拟按下Tab后记录一个"焦点不可见"标记。

第二个是商品卡片结构杂乱：在无障碍树里，整个商品卡片被建模为一个巨型可点击节点，用户按Tab进去，焦点落在卡片容器上，Read屏会报出大段文字，但用户无法细粒度地在"商品标题"和"加入购物车按钮"之间切换。这属于ARIA role和landmark设计缺陷，普通静态扫描查不出来，只有模拟真实操作遍历焦点序列时才暴露——这恰是这类工具不可替代的价值。

第三个是弹窗关不掉：结算页出现一个优惠弹窗，弹窗关闭按钮没有可访问名称，读屏朗读出来是一个"图形"按钮，用户根本不知道那是个关闭入口，更麻烦的是关闭按钮不在键盘焦点的循环顺序里，简单说就是激活弹窗之后，焦点没有自动移到弹窗内部。这个问题在业务回归测试里几乎不会被发现，但在视障交互模拟里暴露得非常彻底。

结果分析阶段，我会把所有原始焦点日志、意图预测记录、断言结果汇总成一个JSON报告，再渲染成HTML。报告的每一条问题都会关联到具体的焦点操作步骤和对应的无障碍树节点信息，开发定位时可以拿节点ID直接跳转到页面元素，不需要像从前那样靠录屏反复回放。

5. 常见问题与排查技巧实录

5.1 焦点丢失与顺序错乱

这是模拟执行中最常见的问题，几乎每天都会遇到。典型表现是：模拟器按Tab后，页面没有响应，activeElement停留在body或者某个不可聚焦的容器上。

排查思路先看两件事。第一，检查DOM里是否真的存在tabindex为负数但视觉上可见的元素，这类元素不会被Tab导航到，但会被读屏用户的"浏览模式"访问到，所以不能简单删掉。第二，检查是否动态渲染导致的异步问题——页面里某个区域是在数据请求回来之后才插入DOM的，模拟器按Tab时这个区域还没渲染出来，自然没反应。我的适配技巧是：在每次分发Tab前主动等待网络空闲（page.wait_for_load_state("networkidle")），同时在模拟器里加入焦点补偿逻辑，一旦发现焦点不变就尝试触发一次Esc键让焦点强制回落到最近的landmark容器。

另外，弹窗和抽屉组件最容易造成顺序错乱。因为这些组件往往把焦点锁在内部，打开弹窗后要自动移动焦点到弹窗容器，关闭后还要把焦点还给触发它的按钮。ADA这部分的实现特别强调"焦点管理不靠内存记忆、靠可预测的逻辑跳转"。我在模拟器里专门维护了一个"焦点历史栈"，每次焦点跳转都会记录来源和目标组件，一旦发现从弹窗关闭后没有回到触发元素，就记录为一个明确的断言失败。

5.2 读屏报读与实际渲染不一致

做无障碍测试久了，就会发现”屏幕上看得到“和“读屏读得到”之间经常有认知差。这个认知差可以总结成一个非常有价值的概念——渲染树和无障碍树不一致。

举个例子，一个页面在视觉上用CSS把错误提示文字渲染成红色，并放在输入框旁边，明眼用户一眼就能看到。但在读屏里，这个错误提示如果没有用aria-live区域包裹，读屏用户根本不会知道这次输入校验失败了。这种问题静态工具也能抓到一部分（比如报aria-live缺失），但更隐蔽的是：错误提示确实存在，却挂在输入框的aria-describedby属性上，读屏用户只有在焦点停留在输入框时才可能听到，一旦焦点移走了，就再也感知不到。

这个问题的排查思路是“跟着焦点走”。执行过程中，凡是出现页面状态变化（比如表单校验、弹窗出现、文字更新）的地方，都要立即做一个额外的无障碍树快照，比对变化前后的差异。如果变化区域不在当前焦点附近、也没有aria-live标记，就判定为一个交互意图感知缺失问题。这个设计让工具的验证深度远超"一次性静态扫描"。

5.3 AI意图误判的典型场景

意图识别模块不是always right，我总结出几个非常典型的误判场景。

第一个是"用户长时间停在某个焦点上，不按Tab也不激活"，模型很容易把这种状态识别成"意图未知"，导致模拟器卡住。真实读屏用户可能在考虑下一步操作，也可能在听长文本，这都是正常行为。处理办法是引入"无操作超时"机制：在当前意图序列执行完成前，一旦连续N步焦点未变化且页面状态未变化，就主动放弃当前意图分支，记录为"用户停留"，而不是推着用户往前走。

第二个是高频切换浏览模式的场景。有些视障用户会在表单里临时从"焦点模式"切换到"浏览模式"去快速扫描页面结构，再切回来继续填写。对模型来说，这两种模式下的Tab行为和方向键行为完全不同。纯序列模型很容易在这个地方出错。我的改进办法是在输入特征里加入"当前模式标识"——执行器每次分发按键前都会记录当前页面处于焦点模式还是浏览模式，再把模式编码作为额外特征注入模型，误判率因此大幅下降。

第三个是垂直列表项的操作。商品列表、搜索结果这类大量垂直堆叠的组件，真实用户更习惯用上下方向键而不是Tab循环。模型不小心把next_focus映射成Tab就会漏过一大片列表项。最终我把意图集合里加了一个move_within_list_vertical，并让模型在学习时看到足够多的列表内箭头导航序列，才算稳住。

5.4 性能与兼容性问题

无障碍自动化对性能的要求比普通UI自动化更苛刻，不是因为交互快，而是因为辅助技术的操作节奏必须接近真实用户。模拟器如果按得太快，反而不真实，容易错过一些延迟渲染的组件；按得太慢，一个长流程用例的耗时又会长到让人受不了。

我的调优经验是把“每步等待时间”做成动态的：普通的相邻焦点移动等待300到500毫秒，遇到打开弹窗、页面跳转这种状态变化事件，等待时间自动拉长到2到3秒，给页面渲染和读屏报读留出空间。这套节奏跑下来，一个20步的流程大概35秒收工，比较接近真人的操作速率，又不至于等到没耐心。

兼容性上，Chromium和Firefox的无障碍树在细节上有不少差异。比如Chromium会把某些组合控件建模为单独的节点，而Firefox会拆成多个子节点，导致断言结果在不同浏览器上飘。我的建议是最小化锚定：每条断言尽量只依赖非浏览器强相关的语义字段，比如role和aria状态，而不是依赖某一条具体的节点路径。移动端WebView的环境差异更大，这个只能靠专项测试矩阵去覆盖，指望一套代码通吃所有环境是不现实的。

6. 落地效果与个人经验反思

6.1 实际发现的高发缺陷类型

项目试运行了两个月后，我统计了一轮工具发现的问题分布，大概分成这么几类：按钮和链接没有可访问名称，占比最高，大概三成；焦点管理混乱，包括焦点不显示、顺序错乱、弹窗焦点未锁定，占四分之一；表单标签缺失或关联错误，占两成；剩下的比较杂，包括图片无替代文本、landmark结构缺失、对比度不足。

发现频率最高的缺陷，往往是静态扫描和动态模拟都能兼顾到的问题。但真正体现这个工具价值的，是大概15%左右的"行为级缺陷"，比如"打开筛选面板后，焦点没有自动跳到面板内部"、"商品数量修改后，读屏没有实时报读变化"。这类缺陷在纯静态工具里完全看不到，在传统UI自动化里测不到，但通过模拟视障用户交互意图的方式，它会在执行流程的特定步骤上自然暴露出来。开发同事看到这类缺陷报告后，定位和修复的效率明显提升了，因为报告里带了具体的焦点操作序列和节点ID，不需要测试人员再去口述"你知道那个弹窗，它就那样那样"。

6.2 几点工具使用心得

先说数据。AI模型在无障碍测试里的价值，更多在于"过滤和引导"，而不在于"一步到位生成完美用例"。想指望模型自动写出所有验证流程，现阶段确实不现实，但它可以帮人把精力集中在真正有风险的操作路径上。我实际操作中体会到，它最大的作用是大幅降低了编写焦点导航脚本的门槛，过去写一个包含5个意图目标的流程脚本可能要半天，现在只需要定义目标状态，AI会自动探索出到达目标的操作路径。

再说模型。尺度和边界要清醒，轻量级模型在大规模、复杂页面上对长尾操作的理解还是比较吃力，回退到规则兜底后虽然能保证流程不中断，但"理解力"确实没有大模型那么强。如果把大模型API引入来做意图理解，效果会更好，尤其对语义复杂的表单填写场景，但这样会引入额外的外部服务依赖，在团队内部落地时需要权衡隐私和成本问题。

最后说落地策略。千万不能一上来就想把整个产品所有页面都覆盖掉，那会直接把你拖垮。正确的节奏是从核心业务路径开始：登录、搜索、详情、下单、支付，先把这几条跑通跑稳，形成团队里所有人都认可的基线用例，再逐步扩展。这个过程中，测试同事的前期数据标注投入会带来很大回报——没有这几百条高质量的操作序列标注，AI模型的落盘效果会很差，这是我踩过最深的坑，所以后期每次给新人介绍这个项目时，我会反复强调数据质量才是整个AI测试项目的重心，模型反而是锦上添花的东西。