本文探讨了使用playwright进行无障碍性测试时，如何有效获取和分析页面的可访问性树（accessibility tree, at）。针对`page.accessibility.snapshot()`方法的局限性及其已弃用状态，文章重点推荐并演示了如何集成和使用业界标准的`@axe-core/playwright`库进行自动化无障碍性审计，并强调了结合浏览器开发者工具进行手动验证的重要性。
理解可访问性树（Accessibility Tree）
可访问性树（Accessibility Tree，简称AT）是浏览器根据文档对象模型（DOM）构建的一个特殊表示，旨在为辅助技术（如屏幕阅读器、语音识别软件等）提供页面内容的语义和结构信息。与DOM不同，AT只包含对辅助技术有意义的元素，例如交互式元素（按钮、输入框）和描述性元素（标签、标题）。它提供了一种简化且语义化的视图，帮助用户理解和操作网页。Playwright等自动化工具通过与浏览器引擎交互，间接或直接地利用了AT信息，例如通过getByRole等选择器。
Playwright中获取可访问性树的挑战
在Playwright中，曾有一个page.accessibility.snapshot()方法，其设计初衷是为了获取页面的可访问性信息。然而，实际使用中，该方法存在显著局限性，并且目前已被弃用。
最初的尝试可能如下所示：
const playwright = require('playwright');
async function getAccessibilitySnapshot(url) {
const browser = await playwright.chromium.launch({ headless: true });
const context = await browser.newContext();
const page = await context.newPage();
await page.goto(url);
// 尝试获取可访问性快照
const snapshot = await page.accessibility.snapshot();
console.log(JSON.stringify(snapshot, null, 2));
await browser.close();
}
// 示例用法
// getAccessibilitySnapshot('https://example.com');然而，page.accessibility.snapshot()返回的通常是一个扁平化的元素列表，而非一个具有父子层级关系的完整可访问性树结构，这与在Chrome开发者工具中观察到的层次化AT大相径庭。由于其输出的结构不符合预期，且该功能已被标记为弃用，因此不建议依赖此方法来获取精确的、结构化的可访问性树。
现代化无障碍性测试方案：集成@axe-core/playwright
鉴于page.accessibility.snapshot()的局限性，进行全面的无障碍性测试应转向使用更专业、更强大的工具。业界标准的选择是集成axe-core，特别是其Playwright版本——@axe-core/playwright。
axe-core是一个高度优化的无障碍性规则引擎，能够识别出网页中常见的无障碍性问题，并提供详细的报告和修复建议。它遵循WCAG（Web内容无障碍指南）标准，能够检测出包括对比度不足、缺少替代文本、键盘导航问题等多种缺陷。
安装与配置
首先，需要在项目中安装@axe-core/playwright包：
npm install @axe-core/playwright axe-core
使用示例
以下是如何在Playwright测试脚本中集成@axe-core/playwright来执行无障碍性审计的示例：
const playwright = require('playwright');
const { AxeBuilder } = require('@axe-core/playwright');
async function runAccessibilityAudit(url) {
const browser = await playwright.chromium.launch({ headless: true });
const context = await browser.newContext();
const page = await context.newPage();
try {
await page.goto(url, { waitUntil: 'networkidle' });
// 创建AxeBuilder实例并运行审计
const accessibilityScanResults = await new AxeBuilder({ page })
.analyze();
// 打印审计结果
console.log(`URL: ${url}`);
console.log('--- Accessibility Scan Results ---');
if (accessibilityScanResults.violations.length > 0) {
console.log('Violations Found:');
accessibilityScanResults.violations.forEach((violation, index) => {
console.log(` ${index + 1}. Rule: ${violation.id}`);
console.log(` Impact: ${violation.impact}`);
console.log(` Description: ${violation.description}`);
console.log(` Help: ${violation.helpUrl}`);
console.log(` Nodes:`);
violation.nodes.forEach(node => {
console.log(` - Selector: ${node.target.join(', ')}`);
console.log(` HTML: ${node.html}`);
console.log(` Fixes: ${node.failureSummary}`);
});
});
} else {
console.log('No accessibility violations found!');
}
console.log(`Passes: ${accessibilityScanResults.passes.length}`);
console.log(`Incomplete: ${accessibilityScanResults.incomplete.length}`);
console.log(`Inapplicable: ${accessibilityScanResults.inapplicable.length}`);
} catch (error) {
console.error(`Error during accessibility audit for ${url}:`, error);
} finally {
await browser.close();
}
}
// 示例用法
runAccessibilityAudit('https://www.google.com');
// runAccessibilityAudit('https://your-website-with-issues.com');结果解读：
analyze()方法返回的结果对象包含多个数组，每个数组代表一种类型的审计结果：
- violations: 发现的无障碍性违规，需要修复。每个违规都包含详细的规则ID、影响级别、描述、帮助链接以及受影响的DOM节点信息。
- passes: 通过的无障碍性检查。
- incomplete: 未能完全检查的规则，可能需要手动验证。
- inapplicable: 不适用于当前页面的规则。
通过分析violations数组，开发者可以清晰地了解页面存在的无障碍性问题及其具体位置，从而有针对性地进行修复。
结合Playwright与浏览器开发者工具进行深度分析
虽然@axe-core/playwright提供了强大的自动化检测能力，但它主要侧重于发现常见的无障碍性问题，而非直接提供一个完整的、可编程访问的可访问性树结构。对于需要深度分析或验证特定可访问性行为的场景，仍需结合使用浏览器开发者工具进行手动检查。
Playwright在这些场景中扮演着关键角色，它可以帮助我们：
- 导航到特定状态： 使用Playwright的API（如page.click(), page.fill(), page.selectOption()等）将页面导航到需要检查的特定状态，例如打开一个模态框、激活一个下拉菜单。
- 设置特定上下文： 模拟不同的用户行为或设备状态，以便在这些特定条件下检查可访问性。
- 配合可视化调试： 在headless: false模式下运行Playwright，可以直接观察页面行为，并在浏览器中打开开发者工具，切换到“Accessibility”（可访问性）面板，查看实时的可访问性树。
Playwright的getByRole等选择器本身就是基于可访问性树的信息进行查找的，这间接证明了其与AT的关联。通过这些选择器，我们可以验证特定元素是否被正确地暴露给辅助技术。
// 示例：使用getByRole验证元素的可访问性名称
await page.getByRole('textbox', { name: 'email' }).click();
// 如果此行代码能够成功执行，说明一个角色为“textbox”且可访问性名称为“email”的元素存在于AT中最佳实践与注意事项
- 弃用旧方法： 避免使用已弃用的page.accessibility.snapshot()，它无法提供所需的详细和结构化信息。
- 拥抱专业工具： 优先使用@axe-core/playwright进行自动化无障碍性审计。它能高效地发现大量常见问题，并集成到CI/CD流程中。
- 结合自动化与手动测试： 自动化工具是基础，但不能替代所有场景。对于复杂交互、上下文依赖的无障碍性问题，仍需结合屏幕阅读器、键盘导航和浏览器开发者工具进行手动测试。
- 持续集成： 将无障碍性测试作为开发流程的一部分，在每次代码提交或部署时运行自动化审计，确保无障碍性不会随着新功能引入而退化。
- 参考官方文档： 始终关注Playwright和axe-core的官方文档，以获取最新的API、功能和最佳实践。
总结
尽管Playwright没有提供一个直接且易于解析的API来提取完整的、层次化的浏览器可访问性树，但通过集成@axe-core/playwright，开发者可以有效地进行全面的自动化无障碍性测试。结合Playwright在准备测试场景方面的强大能力，以及浏览器开发者工具进行深度手动分析，可以确保构建出符合无障碍性标准的高质量Web应用。无障碍性是现代Web开发不可或缺的一部分，采用正确的工具和方法至关重要。
