Playwright无障碍性测试实践：从DOM到可访问性树的探索与现代工具应用

本文探讨了使用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来执行无障碍性审计的示例：

Replit Agent

Replit最新推出的AI编程工具，可以帮助用户从零开始自动构建应用程序。

下载

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在这些场景中扮演着关键角色，它可以帮助我们：

1. 导航到特定状态： 使用Playwright的API（如page.click(), page.fill(), page.selectOption()等）将页面导航到需要检查的特定状态，例如打开一个模态框、激活一个下拉菜单。
2. 设置特定上下文： 模拟不同的用户行为或设备状态，以便在这些特定条件下检查可访问性。
3. 配合可视化调试： 在headless: false模式下运行Playwright，可以直接观察页面行为，并在浏览器中打开开发者工具，切换到“Accessibility”（可访问性）面板，查看实时的可访问性树。

Playwright的getByRole等选择器本身就是基于可访问性树的信息进行查找的，这间接证明了其与AT的关联。通过这些选择器，我们可以验证特定元素是否被正确地暴露给辅助技术。

// 示例：使用getByRole验证元素的可访问性名称
await page.getByRole('textbox', { name: 'email' }).click();
// 如果此行代码能够成功执行，说明一个角色为“textbox”且可访问性名称为“email”的元素存在于AT中

最佳实践与注意事项

1. 弃用旧方法： 避免使用已弃用的page.accessibility.snapshot()，它无法提供所需的详细和结构化信息。
2. 拥抱专业工具： 优先使用@axe-core/playwright进行自动化无障碍性审计。它能高效地发现大量常见问题，并集成到CI/CD流程中。
3. 结合自动化与手动测试： 自动化工具是基础，但不能替代所有场景。对于复杂交互、上下文依赖的无障碍性问题，仍需结合屏幕阅读器、键盘导航和浏览器开发者工具进行手动测试。
4. 持续集成： 将无障碍性测试作为开发流程的一部分，在每次代码提交或部署时运行自动化审计，确保无障碍性不会随着新功能引入而退化。
5. 参考官方文档： 始终关注Playwright和axe-core的官方文档，以获取最新的API、功能和最佳实践。

总结

尽管Playwright没有提供一个直接且易于解析的API来提取完整的、层次化的浏览器可访问性树，但通过集成@axe-core/playwright，开发者可以有效地进行全面的自动化无障碍性测试。结合Playwright在准备测试场景方面的强大能力，以及浏览器开发者工具进行深度手动分析，可以确保构建出符合无障碍性标准的高质量Web应用。无障碍性是现代Web开发不可或缺的一部分，采用正确的工具和方法至关重要。