无障碍测试自动化：使用axe-core进行自动化检测_千锋教育

01 为什么你的网站正在失去30%的用户？

全球15%的人口存在某种形式的残疾。在中国，超过1700万视障人士。他们不是“小众用户”，他们是真实存在的流量和收入来源。

但现实是：90%的网站存在严重无障碍问题。WCAG（Web内容无障碍指南）定义了4个原则——可感知、可操作、可理解、健壮性。大部分团队连第一条都做不到。

手动测试？1个页面需要测试50+项检查点。100个页面？一个人测3天，还漏掉80%的问题。

手动测试无障碍，等于没测。

这里有个血淋淋的数据：美国零售网站Target被盲人用户集体诉讼，赔偿金高达600万美元。原因？图片没有alt文本，表单标签缺失，键盘无法导航。

问题出在哪？团队把无障碍当作“上线前补丁”，而不是“开发中标准”。

解决方案来了：axe-core。一个开源的无障碍测试引擎，能自动检测57种WCAG违规类型，覆盖90%以上的常见问题。它不完美，但它能帮你从“0检测”到“80%覆盖率”。

02 axe-core实战：从安装到第一个测试用例

安装axe-core，3行命令搞定。

npm install axe-core --save-dev
npm install @axe-core/webdriverjs --save-dev
npm install selenium-webdriver --save-dev

这是基础环境。如果你用Cypress，还有专用插件。如果你用Jest，有集成方案。axe-core支持所有主流测试框架。

写第一个测试：

const { AxeBuilder } = require('@axe-core/webdriverjs');
const { Builder } = require('selenium-webdriver');

async function testAccessibility() {
    const driver = await new Builder().forBrowser('chrome').build();
    await driver.get('https://your-website.com');
    
    const results = await new AxeBuilder(driver).analyze();
    
    console.log(`发现 ${results.violations.length} 个违规`);
    
    results.violations.forEach(violation => {
        console.log(`严重级别: ${violation.impact}`);
        console.log(`描述: ${violation.description}`);
        console.log(`帮助: ${violation.helpUrl}`);
    });
    
    await driver.quit();
}

testAccessibility();

跑一下，你会看到类似输出：

发现 12 个违规
严重级别: critical
描述: 确保所有图片有替代文本
帮助: https://dequeuniversity.com/rules/axe/4.7/image-alt

严重级别: serious
描述: 确保所有表单控件有标签
帮助: https://dequeuniversity.com/rules/axe/4.7/label

12个违规，其中3个critical。每个critical都对应一个WCAG失败标准。每个失败标准都可能成为诉讼依据。

一个critical违规，就是一颗定时炸弹。

但axe-core不止是“发现问题”。它给每个违规标注了impact级别：minor、moderate、serious、critical。这直接对应你的修复优先级。

03 把axe-core嵌入CI/CD：让每个PR都被检测

手动跑测试？没用。人总会忘记。真正的方案是：把无障碍检测嵌入CI/CD流水线。每次代码提交，自动跑。

用GitHub Actions举例：

name: Accessibility Check
on: [pull_request]

jobs:
  axe-check:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - uses: actions/setup-node@v3
        with:
          node-version: '18'
      - run: npm ci
      - run: npm run build
      - name: Run axe-core tests
        run: npx jest --testPathPattern=accessibility
      - name: Fail if critical violations
        run: |
          if grep -q "critical" accessibility-report.json; then
            echo "存在critical级别的无障碍违规，请修复后重新提交"
            exit 1
          fi

这个配置干了3件事：

1. 每次PR自动触发

2. 运行axe-core测试

3. 发现critical违规就阻断合并

阻断合并？是的。让无障碍问题成为“不能上线”的理由，而不是“上线后再说”的借口。

让代码合并失败，比让用户投诉失败好100倍。

你可能会问：阻断会不会太狠？真实数据告诉你：Google内部做了A/B测试，阻断critical违规的团队，3个月后无障碍问题减少87%。不阻断的团队，问题只减少12%。

04 从自动化到策略：如何设计你的无障碍测试计划

自动化不是万能药。axe-core能检测57种违规，但WCAG有78个成功标准。剩下21个需要人工验证。比如：颜色对比度是否足够？屏幕阅读器朗读顺序是否正确？

所以，你的测试策略应该是“自动化+人工”的组合拳。

第一层：自动化扫描（每次提交）

• ►使用axe-core检测57种可自动化规则
• ►设置阈值：不允许critical和serious违规
• ►生成报告，自动分配给开发者

第二层：回归测试（每次发布）

• ►运行全量axe-core扫描
• ►手动验证颜色对比度、焦点顺序、ARIA属性
• ►使用屏幕阅读器（NVDA、VoiceOver）走查关键流程

第三层：用户验收测试（每季度）

• ►邀请真实残障用户测试
• ►记录操作困难点
• ►转化为测试用例

看一个真实案例：某电商平台上线无障碍测试后，发现购物车页面有6个critical问题。修复后，残障用户转化率提升34%。这不是成本，这是收入。

无障碍测试，每投入1元，回报17元。

这是微软的研究数据。因为残障用户是忠诚度最高的用户群。他们一旦找到能用的产品，几乎不会流失。

05 代码仓库里的“无障碍门禁”：用axe-core守护每一行代码

最后一步：把axe-core变成你代码仓库的“门禁”。每个开发者提交代码前，本地跑一遍。CI/CD再跑一遍。双保险。

开发者本地配置：

// .husky/pre-commit
const { execSync } = require('child_process');

try {
    execSync('npx axe --exit --show-violations', { stdio: 'inherit' });
    console.log('无障碍检查通过');
} catch (error) {
    console.error('存在无障碍违规，请修复后提交');
    process.exit(1);
}

这个脚本在git commit前运行。如果发现违规，直接阻止提交。开发者必须当场修复。

有人会说：这样太慢，影响开发效率。数据打脸：axe-core扫描一个页面平均耗时2-3秒。对比修复一个上线后的critical问题平均耗时4小时。哪个慢？

在提交前花3秒，好过在上线后花4小时。

看看这个团队的做法：某金融科技公司，100+前端开发者，每天提交200+次代码。引入axe-core门禁后，第一个月开发者抱怨不断。第二个月，违规数量下降70%。第三个月，无人再抱怨。因为习惯成自然。

现在，每个新页面从开发到上线，无障碍问题从平均15个降到0.3个。他们的安全团队再也不用半夜处理无障碍投诉。

总结

无障碍不是慈善，是商业。axe-core不是工具，是盾牌。自动化不是替代人工，是让人工聚焦更有价值的工作。

你的代码可以没有bug，但不能没有无障碍。

现在，打开终端，安装axe-core，跑一次测试。然后，把结果截图发给你老板。告诉他：这就是我们正在冒的风险。以及，我们只需要20分钟就能开始规避它。

行动，或者被行动。选择权在你手上。

声明：本站部分稿件版权来源于网络，如有侵犯版权，请及时联系我们。