Deque Systems is universally recognized as the leader in accessibility testing and compliance tools and techniques. Core to their success is aXe-core -the industry standard accessibility engine for automated Web UI testing.
🔖 | Bookmark these resources for reference
This section provides a rapid overview of the core concepts and components of this solution, before we dive into actual usage.
What is axe-core? Think of it as as an accessibility-focused test runner that has built-in Rules and Checks for testing accessibility compliance, and can generate Reports in formats suitable for analysis or integration in developer workflows. The workflow has 3 steps:
The report provides details on the rules prioritized in test, the number of nodes (matching elements) on which rules were assessed, and the outcomes (passes, violations, incomplete, inapplicable) of those assessments. The report also provides insights into probable causes for violations, and proposes fixes to remediate them.
The developer can use the report as guidance to make relevant fixes, then re-run scan to validate that fixes worked and accessibility compliance goals are met.
Deque Systems also maintains axe DevTools HTML a suite of accessibility testing tools built on top of axe-core that make it easy to integrate automated testing into your developer workflow.
Key to this is the Shift Left philosophy to move detection and remediation closer to the start of the developer workflow (e.g., design or authoring) instead of at the end (build or post-deployment) - driven by the 4 components below:
🔖 | Bookmark these resources for reference
Ideally, we want to add the linter into our VS Code profile, and use the integrations to automate accessibility testing in our end-to-end developer workflow (from authoring to deployment and CI/CD). However the CLI and extension options are useful when:
We will focus on integrations which drive automated testing workflows with other test runners, while remaining consistent with axe-core engine evolution. The axe-core Philosophy and Manifesto is that automated accessibility testing rules must
At present example integrations exist for JavaScript, C#, Java, Python and Ruby. In this demo and tutorial, we use 🎭 Playwright and dive into usage details later.
🔖 | Bookmark these resources for reference
Automated accessibility testing relies on assessment based on aXe Rulesets - defined as Rule objects with these properties:
id reflecting their purposeimpact from {minor, moderate, serious or critical}type from {failure, needs review}tags that identify “requirements” that rule enforcesFrom a WCAG compliance perspective, rules are grouped as:
wcag2a, wcag2aawcag21a, wcag21aawcag22a, wcag22aawcag2aaabest-practiceexperimental🔖 | Bookmark these resources for reference
cat.* tag subset for type of content.To understand how this works under the hood, it’s useful to start with an example test run - then look at the artifacts generated to provide context. To do that, we’ll start first by running a sample accessibility test using Playwright.
[👉🏽 Next: Playwright]