Automated accessibility testing with axe-core, Lighthouse, and Pa11y
The systematic use of axe-core, Lighthouse, and Pa11y libraries within CI/CD pipelines and development workflows to programmatically detect and report violations of Web Content Accessibility Guidelines (WCAG) against web applications.
This skill enables organizations to shift accessibility left in the development lifecycle, reducing legal risk (ADA, Section 508, AODA), broadening market reach to the 1.3 billion people with disabilities, and improving overall UX and SEO through compliance with core web vitals. It directly impacts time-to-market by automating what was a manual, expensive testing phase.
1Careers
1Categories
9.1 Avg Demand
15%
Avg AI Risk
How to Learn Automated accessibility testing with axe-core, Lighthouse, and Pa11y
1. **Foundational Concepts & Standards**: Master the Web Content Accessibility Guidelines (WCAG) 2.1 AA criteria, understanding the principles of Perceivable, Operable, Understandable, and Robust (POUR). Learn the differences between axe-core (the engine), Lighthouse (a broader performance/SEO/audit tool that uses axe-core), and Pa11y (a wrapper for running axe-core via CLI).
2. **Tool-Specific Configuration & Integration**: Move from running tools manually to integrating them into your workflow. Learn to configure axe-core's `rules` and `checks` for specific projects. Implement Lighthouse in Chrome DevTools for ad-hoc audits and understand its scoring. Use Pa11y's CLI and `--runner` flag for custom axe-core configurations.
3. **Pipeline Orchestment & Signal-to-Noise Ratio**: Master the integration of these tools into a CI/CD pipeline (e.g., GitHub Actions, GitLab CI). Develop strategies to manage false positives through `axe.run()` context options and baseline comparisons. Architect a system where test results (JSON reports) feed into dashboards or issue trackers (Jira) to create actionable developer feedback loops, moving beyond mere error reporting to guided remediation.
Practice Projects
Beginner
Project
Local Environment Audit of a Public Website
Scenario
You are tasked with performing an initial accessibility audit on your company's public marketing site before a major redesign. You have no prior tool experience.
How to Execute
1. Install the axe DevTools browser extension for Chrome. Run a scan on the homepage and a key subpage, noting the 'critical' and 'serious' issues. 2. Open Chrome DevTools, go to the Lighthouse tab, and run an 'Accessibility' audit. 3. Install Pa11y via npm (`npm install -g pa11y`). Run a terminal scan (`pa11y https://yoursite.com`) and compare the output to the browser extension results. 4. Compile a unified report listing each violation, the WCAG criterion it fails (e.g., 4.1.2), and the specific HTML element involved.
Intermediate
Project
Automated CI/CD Accessibility Gate
Scenario
Your team wants to prevent new accessibility regressions from being deployed. You need to implement a non-blocking but visible test in the pull request (PR) pipeline.
How to Execute
1. Create a new GitHub Actions workflow file. Add a step that uses the `pa11y-ci` npm package with a `.pa11yci` config file. 2. Configure the `.pa11yci` file to test key routes, set the WCAG standard to `WCAG2AA`, and specify an axe-core config to ignore known legacy issues (`axe-core-config.json`). 3. Have the script run Pa11y and generate a JSON report. Use a subsequent step to parse this report and post a summary as a comment on the PR, failing the build only if a new, un-ignored critical violation is introduced. 4. Document the process and the configured rule ignores for team transparency.
As the lead engineer for a large-scale e-commerce platform, you must implement a continuous monitoring system that tracks accessibility scores across microfrontends, assigns ownership, and integrates with the sprint cycle.
How to Execute
1. Architect a system where each microfrontend has its own axe-core configuration file, managed by its feature team. 2. Develop a central scanning service (using Pa11y's programmatic API or axe-puppeteer) that runs nightly against staging environments, aggregates scores (Lighthouse performance/accessibility) and violation counts per component. 3. Store results in a database and build a dashboard (e.g., Grafana) showing trends, team-specific scores, and top violations. 4. Implement a webhook that, when a new 'Critical' violation is detected in a component, automatically creates a detailed Jira ticket assigned to the owning team's backlog with a link to the report and suggested remediation code snippets from axe-core's helpUrl.
axe-core is the industry-standard accessibility testing engine; use its `axe.run()` API for custom, granular tests. Lighthouse provides a composite score and is best for broad, high-level audits. Pa11y is the premier CLI tool for orchestrating axe-core scans, ideal for scripting and CI integration.
Use CI platforms to run Pa11y-ci or custom axe-core scripts on every PR. Integrate axe-core directly into component/unit testing with Jest for React/Angular or Playwright for E2E tests. Puppeteer/Playwright are essential for automating complex user interactions (logins, dynamic content) before running axe-core.
Reporting & Management Tools
Axe CLI (npm: @axe-core/cli)Jira/Asana with custom integrationsGrafana/Power BI for dashboards
Axe CLI is useful for quick, local terminal scans. Integrate with project management tools via APIs to auto-create tickets from JSON reports. Build dashboards to visualize trends, track team performance, and communicate compliance status to non-technical stakeholders.
Interview Questions
Answer Strategy
The interviewer is testing your ability to manage technical debt, configure tools effectively, and foster developer adoption. A strong answer demonstrates a phased, empathetic approach. **Sample Answer**: 'I'd start by validating the noise. I'd run a baseline audit to categorize the violations-separating true bugs from false positives or framework-specific quirks. I'd then configure axe-core's `rules` option to temporarily ignore known, non-critical legacy issues, and document these suppressions. I'd create a clear, team-owned backlog for these ignores with a sunset plan. Concurrently, I'd set the pipeline to fail only on *new* violations introduced in a PR, making the signal actionable. Finally, I'd provide targeted training on how to fix the top 3 recurring issues.'
Answer Strategy
This is a behavioral question testing communication, empathy, and technical translation skills. Use the STAR (Situation, Task, Action, Result) method. **Sample Answer**: 'In my last role, a developer built a custom dropdown using divs, which axe-core flagged as missing an `aria-label`. I met with them and first acknowledged the complexity of the widget. Instead of just citing WCAG 4.1.2, I used a screen reader (NVDA) live to demonstrate the failure-the user heard 'group' but had no context. I then showed them the W3C's own APG (ARIA Authoring Practices Guide) example for a combobox, mapping the code directly to their component. I offered to pair-program for 15 minutes. The developer not only fixed the issue but later championed the APG guide for other projects.'
Careers That Require Automated accessibility testing with axe-core, Lighthouse, and Pa11y