The Vitality of Accessibility Testing
Accessibility testing is the process of ensuring that a digital product or service is accessible to people with various disabilities, such as visual, auditory, physical, speech, cognitive, language, and learning disabilities. This type of testing is crucial because it enables people with disabilities to participate fully in society by providing them with equal access to information, services, and opportunities.
However, manual accessibility testing can be challenging as it requires a deep understanding of accessibility standards and techniques. Additionally, it can be time-consuming and labour-intensive.
In the olden days, tools for ensuring website accessibility were primarily rule-based, checking for specific errors such as missing alt text for images. In 2012, the US Department of Justice issued guidance on the Americans with Disabilities Act (ADA) and website accessibility, which was the first time I had heard about accessibility. Suddenly, the company I was working for had to make their website accessible due to the new rule.
In 2020, the COVID-19 pandemic increased the use of digital products and services, making accessibility even more important.
Axe and Google Lighthouse are two accessibility testing tools with Playwright integration. They automate the testing process, identify accessibility errors, and track progress. These open-source tools check web pages for accessibility issues. The @axe-core/playwright module analyzes Axe with Playwright, while the playwright-lighthouse package is used to integrate Lighthouse with Playwright. Both tools generate a web audit report for several pages in an automated way but only run in Chrome.
Manual testing is necessary to detect many accessibility issues, so recommend using a combination of automated and manual testing, along with inclusive user testing.
test('should not have any automatically detectable accessibility issues', async ({ page },testInfo) => {
await page.goto('<https://the-internet.herokuapp.com/>');const accessibilityScanResults = await new AxeBuilder({ page })
.withTags(['wcag2a', 'wcag2aa', 'wcag21a', 'wcag21aa'])
.analyze(); await testInfo.attach('accessibility-scan-results', {
body: JSON.stringify(accessibilityScanResults, null, 2),
contentType: 'application/json'
}); expect(violationFingerprints(accessibilityScanResults)).toMatchSnapshot(); interface Violation {
id: string;
nodes: { target: string }[];
}
function violationFingerprints(accessibilityScanResults: any) {
const violationFingerprints: Violation[] = accessibilityScanResults.violations.map(
(violation: any) => ({
rule: violation.id,
targets: violation.nodes.map((node: { target: string }) => node.target),
})
);
return JSON.stringify(violationFingerprints, null, 2);
}
});
When adding accessibility tests to an application, ignore some violations with AxeBuilder.exclude(). This can add complexity and fragility. Alternatively, use snapshots to verify that a set of pre-existing violations hasn't changed. Create a fingerprint of the violation(s) by including only enough information to uniquely identify the issue, then take a snapshot of the fingerprint.
Using a test fixture for common axe configuration across many tests allows for a consistent set of rules among all tests. This suppresses known violations in a common element across multiple pages and makes attaching accessibility reports for many scans easier.
My recent publication compiled a comprehensive collection of 100 similar typescript programs. Each program not only elucidates essential Typescript concepts and expounds upon the significance of test automation but also provides practical guidance on its implementation using Playwright. This resource will undoubtedly be valuable if you look deeper into similar topics.
