The digital accessibility audit in France assesses the compliance of websites and digital services with RGAA standards, aligned with the WCAG, in order to guarantee their accessibility to people with disabilities. Mandatory for public bodies since the Law for a Digital Republic, it identifies obstacles, proposes corrections and results in a declaration of accessibility. Carried out via technical and user tests, the audit improves the user experience, optimizes SEO, reduces legal risks and enhances the inclusive commitment of organizations.
Let’s take a look at how Playwright can be used to audit the accessibility of a web page.
Limitations with Playwright
Automated tools like axe-core
(which we’ll be using with Playwright) mainly detect technical and structural errors (missing tags, alt attributes, contrast, etc.), but only cover around 30-50% of accessibility problems. They are unable to assess such issues as
- The user experience of a disabled person,
- The relevance of text descriptions,
- The effectiveness of keyboard navigation or the use of screen readers in complex scenarios,
- Interaction logic and ergonomics.
In addition, Playwright, acting as a browser, does not act as a screen reader, and therefore cannot simulate scenarios involving them.
A manual audit is still required to:
- Test user interactions,
- Verify content comprehension,
- Validate the experience with assistive technologies (screen readers, voice commands).
We are now aware of Playwright’s limitations, but using Playwright remains advantageous because it enables efficient automation of testing, rapid identification of technical errors and continuous verification across multiple browsers.
Installation
Now that we know the limitations of Playwright, let’s take a look at how to set it up.
The basis remains the same as in the article on JavaScript errors.
Next, install the @axe-core/playwright
package with the command npm i @axe-core/playwright --save-dev
.
Usage
Next, we’ll create a scenario that will detect two pages: one without violations (https://playwright.dev
) and one with (https://france.fr
).
|
|
A few notes to bear in mind:
- You can define which accessibility standards you want to take into account (complete list)
- You can control the number of violations returned (
accessibilityScanResults.violations
), but also the number of rules that are ok (accessibilityScanResults.passes
), as well as those that are not applicable to your page (accessibilityScanResults.inapplicable
).
Violations
In our simple case, we only check the number of violations, but the @axe-core
library can be used to retrieve more precise information on violations. Let’s take a closer look:
|
|
The first violation can be seen as follows:
|
|
Each violation has this structure:
id
: a unique identifier,impact
: the criticality level of the violation,- tags: the set of tags assigned to the violation,
- description: a description of the rule,
help
: a description of the violation,helpUrl
: a link to dequeuniversity.com with complete information about the violation.nodes
: the list of all impacted elements in the pagehtml
: code of the impacted HTML element- impact`: the criticality level of the violation for this element,
- failureSummary`: an explanation of how to correct the violation
Conclusion
With Playwright, you can save an enormous amount of time on the possible returns from an accessibility audit. To do this, you need to be proactive:
- a script that launches the AxeBuilder audit on a representative set of your site’s pages;
- correction as soon as a problem is detected;
- a CI launched regularly to avoid regression.