AI 驱动的前端无障碍合规检测：从手动审查到自动化诊断
一、无障碍合规的隐形成本：手动审查的效率困境
Web 无障碍（Accessibility，简称 A11y）早已不是"锦上添花"的可选项。欧盟《欧洲无障碍法案》（EAA）将于 2025 年 6 月正式生效，美国 ADA 诉讼案件逐年递增，国内《信息技术 互联网内容无障碍可访问性技术要求》也在加速落地。合规压力正在从"道德倡议"转变为"法律红线"。
然而，前端团队在无障碍合规上面临的核心矛盾是：审查成本极高，但问题发现往往滞后。一个中型 SaaS 产品通常包含 200+ 个页面、上千个交互组件。手动审查每个页面的 ARIA 属性、焦点顺序、颜色对比度和屏幕阅读器兼容性，单次全量审计需要 2-3 人周。更棘手的是，无障碍问题具有"回归性"——每次迭代都可能引入新的违规项，而 CI 流水线中的 lint 规则只能覆盖约 30% 的静态问题。
AI 驱动的无障碍检测方案，核心思路是将大模型的视觉理解与 DOM 语义分析结合，在开发和测试阶段自动识别无障碍违规项，并生成可操作的修复建议。
二、AI 无障碍检测的技术架构与语义推理机制
传统无障碍检测工具（如 axe-core、Lighthouse）基于 DOM 规则匹配，只能发现"属性缺失"类问题，无法判断"语义是否合理"。例如，一个 <div onclick="…"> 在规则层面可能通过了所有检查，但对屏幕阅读器用户而言完全不可访问。AI 检测的关键突破在于：将视觉渲染结果与 DOM 结构进行交叉验证，识别语义与视觉的不一致。
flowchart TB
A[页面截图 + DOM 快照] –> B[双通道特征提取]
B –> C[视觉通道：布局/颜色/焦点指示器]
B –> D[语义通道：ARIA/角色/标签/层级]
C –> E[多模态对齐模型]
D –> E
E –> F[违规项检测引擎]
F –> G{违规类型分类}
G –>|静态缺陷| H[属性缺失/值错误]
G –>|语义缺陷| I[角色与视觉不匹配]
G –>|交互缺陷| J[焦点/键盘/时序问题]
H –> K[修复建议生成]
I –> K
J –> K
K –> L[结构化报告输出]
上图展示了双通道检测的完整流程。视觉通道捕获页面的实际渲染状态（颜色对比度、焦点指示器可见性、布局层级），语义通道提取 DOM 的无障碍属性（ARIA 角色、标签、焦点顺序）。多模态对齐模型将两者映射到同一语义空间，识别"视觉上看起来像按钮但 DOM 中只是 div"这类语义不一致问题。
三、生产级实现：双通道无障碍检测引擎
以下实现包含 DOM 语义提取、视觉特征分析和违规检测三个核心模块。
// a11y-detector.ts — AI 驱动的无障碍检测引擎
import { JSDOM } from 'jsdom';
import { VisionClient } from './vision-client';
import { A11yIssue, IssueSeverity, DOMNode, VisualFeature } from './types';
// DOM 语义提取器：从页面快照中提取无障碍相关属性
// 设计意图：不依赖浏览器运行时，通过 JSDOM 解析静态 HTML，
// 提取 ARIA 属性、语义角色和焦点顺序
function extractSemanticFeatures(html: string): DOMNode[] {
const dom = new JSDOM(html);
const document = dom.window.document;
const nodes: DOMNode[] = [];
// 遍历所有可交互元素，提取无障碍语义
const interactiveSelector = [
'a[href]', 'button', 'input', 'select', 'textarea',
'[role="button"]', '[role="link"]', '[role="textbox"]',
'[tabindex]', '[onclick]'
].join(', ');
document.querySelectorAll(interactiveSelector).forEach((el, index) => {
const htmlEl = el as HTMLElement;
nodes.push({
tagName: htmlEl.tagName.toLowerCase(),
role: htmlEl.getAttribute('role') || getImplicitRole(htmlEl),
ariaLabel: htmlEl.getAttribute('aria-label') || '',
ariaLabelledBy: htmlEl.getAttribute('aria-labelledby') || '',
tabIndex: htmlEl.getAttribute('tabindex') || '',
textContent: htmlEl.textContent?.trim().slice(0, 100) || '',
isVisible: isElementVisible(htmlEl),
rect: getBoundingClientRect(htmlEl),
index,
});
});
return nodes;
}
// 视觉特征分析：调用视觉模型分析截图中的无障碍问题
// 设计意图：视觉模型可以检测颜色对比度不足、焦点指示器缺失等
// 纯 DOM 分析无法发现的问题
async function analyzeVisualFeatures(
screenshot: Buffer,
semanticNodes: DOMNode[]
): Promise<VisualFeature[]> {
const visionClient = new VisionClient();
const prompt = `分析这张网页截图的无障碍性问题。重点关注：
1. 文本与背景的颜色对比度是否满足 WCAG AA 标准（4.5:1）
2. 可交互元素是否有可见的焦点指示器
3. 文本字体大小是否过小（低于 12px）
4. 图片是否有可见的替代文本或装饰性标记
5. 表单控件是否有关联的可见标签
已知页面包含 ${semanticNodes.length} 个可交互元素。
请以 JSON 数组格式输出每个发现的问题。`;
const result = await visionClient.analyze(screenshot, prompt);
return parseVisualIssues(result);
}
// 违规检测引擎：合并语义和视觉通道的检测结果
async function detectA11yIssues(
html: string,
screenshot: Buffer
): Promise<A11yIssue[]> {
const semanticNodes = extractSemanticFeatures(html);
const visualFeatures = await analyzeVisualFeatures(screenshot, semanticNodes);
const issues: A11yIssue[] = [];
// 规则 1：可交互元素必须有可访问名称
semanticNodes.forEach((node) => {
const hasAccessibleName =
node.ariaLabel || node.ariaLabelledBy || node.textContent;
if (!hasAccessibleName && node.isVisible) {
issues.push({
severity: IssueSeverity.Critical,
type: 'missing-accessible-name',
element: node.tagName,
description: `元素 <${node.tagName}> 缺少可访问名称，屏幕阅读器无法识别其用途`,
suggestion: `添加 aria-label 属性或关联可见标签元素`,
});
}
});
// 规则 2：语义角色与视觉表现的一致性校验
// 如果视觉模型检测到"看起来像按钮"但 DOM 角色不是 button，标记为语义不一致
visualFeatures.forEach((vf) => {
if (vf.visualRole && vf.semanticRole !== vf.visualRole) {
issues.push({
severity: IssueSeverity.Major,
type: 'role-mismatch',
element: vf.selector,
description: `视觉表现为"${vf.visualRole}"，但语义角色为"${vf.semanticRole}"`,
suggestion: `将元素改为 <${vf.visualRole}> 或添加 role="${vf.visualRole}"`,
});
}
});
// 规则 3：合并视觉通道的对比度问题
visualFeatures
.filter((vf) => vf.contrastRatio && vf.contrastRatio < 4.5)
.forEach((vf) => {
issues.push({
severity: IssueSeverity.Major,
type: 'insufficient-contrast',
element: vf.selector,
description: `颜色对比度为 ${vf.contrastRatio}:1，低于 WCAG AA 标准 4.5:1`,
suggestion: `调整文本或背景颜色，将对比度提升至 4.5:1 以上`,
});
});
return issues.sort((a, b) => a.severity – b.severity);
}
四、边界分析与架构权衡
AI 无障碍检测方案在工程落地中存在几个必须正视的 Trade-off：
检测精度与推理成本的矛盾。视觉模型每次调用的 Token 消耗约为纯 DOM 分析的 5-8 倍。在一个 200 页面的项目中，全量视觉检测的 API 成本可能达到数百美元。实践中需要采用分层策略：CI 流水线中仅运行 DOM 规则检测（零成本），视觉检测仅在 PR 合入前的 staging 环境触发，且只检测变更页面。
误报率与召回率的平衡。大模型对"语义不一致"的判断存在约 15% 的误报率。例如，一个使用 role="tab" 的自定义标签页组件，可能被误判为"视觉表现为按钮但角色不是 button"。解决方案是在检测报告中标注置信度，低于 0.8 的结果标记为"待人工确认"。
动态内容的检测盲区。单次截图只能捕获页面某一时刻的状态。下拉菜单展开后的焦点陷阱、模态框打开后的焦点管理、无限滚动中的 ARIA live region 更新，这些动态交互场景无法通过静态截图覆盖。需要结合 Playwright 等自动化工具，在关键交互节点捕获多帧截图进行时序分析。
适用边界：该方案最适合内容型页面和表单密集型应用。对于高度定制化的交互组件（如画布编辑器、3D 可视化），AI 检测的准确率显著下降，仍需依赖专业无障碍审计师的手动评估。
五、总结
AI 驱动的前端无障碍检测，将合规审查从"人工走查"推进到"自动化诊断"阶段。双通道架构（DOM 语义 + 视觉分析）弥补了传统规则引擎无法检测语义不一致的短板。落地路线建议：第一阶段在 CI 中集成 axe-core 等规则检测，覆盖基础合规；第二阶段在 staging 环境引入视觉检测，聚焦语义一致性；第三阶段将检测结果接入项目管理工具，形成"检测-修复-验证"的闭环流程。关键原则是：不追求 100% 自动化，而是让 AI 处理 80% 的重复性检测，将人力聚焦在高复杂度的交互场景审计上。
