Axe
The world's leading accessibility testing engine. Automated WCAG compliance checking for web, mobile, and documents.
Overview
Axe, created by Deque Systems, is the most widely used accessibility testing engine in the world. It powers accessibility testing in browser developer tools, CI pipelines, and automation frameworks. Axe tests web pages against the Web Content Accessibility Guidelines (WCAG) 2.1 and 2.2, flagging issues like missing alt text, incorrect heading hierarchy, colour contrast failures, and keyboard navigation problems.
Axe is available as a browser extension (free), a JavaScript library for automation integration, and a comprehensive enterprise platform (Axe DevTools). It is the standard tool for automated accessibility testing.
What it's used for
Axe is essential for:
- WCAG compliance testing: Automated checks for accessibility standards compliance.
- CI/CD accessibility gates: Block deployments that introduce accessibility regressions.
- Developer accessibility awareness: Browser extension provides instant feedback during development.
- Legal compliance: Many jurisdictions (including NZ) require digital accessibility under human rights legislation.
Pros & Cons
Pros
- Industry standard — used by Google, Microsoft, and government agencies
- Low false-positive rate compared to other accessibility tools
- Integrates with Playwright, Cypress, Selenium, and Jest
- Free browser extension for quick checks
- Comprehensive rule set covering WCAG 2.1 and 2.2
Cons
- Only catches ~30% of accessibility issues — manual testing still required
- Enterprise platform (Axe DevTools) is expensive
- Some advanced WCAG criteria require manual verification
- Can miss context-specific accessibility problems
- Requires understanding of accessibility to interpret results
Platforms & Integrations
Axe runs on Windows, macOS, and Linux. The browser extension works in Chrome, Firefox, and Edge. The JavaScript library integrates with any Node.js test framework.
Pricing
| Tier | Cost | Includes |
|---|---|---|
| Axe DevTools Browser Extension | Free | Basic accessibility scanning in browser |
| Axe DevTools Pro | $40/user/mo | Advanced rules, guided testing, reporting |
| Axe DevTools Enterprise | Custom | CI integration, dashboard, governance, support |
NZ Context
Axe is the recommended accessibility testing tool in NZ government digital standards. The Digital Service Standards and NZ Accessibility Guidelines reference automated testing tools like Axe. NZ organisations receiving government funding or serving the public are increasingly required to meet WCAG 2.1 AA standards. For NZ web developers and testers, Axe is an essential tool.
Alternatives
- Lighthouse — Built into Chrome DevTools. Free but less comprehensive.
- WAVE (WebAIM) — Free browser extension with visual feedback.
- Pa11y — Command-line accessibility testing. Good for CI integration.
When to choose Axe
A quick decision guide for NZ teams evaluating accessibility testing options.
| Choose Axe when… | Choose something else when… | Combine with… |
|---|---|---|
| You're running Playwright or Cypress and need automated WCAG checks baked into your CI pipeline | You need PDF or native mobile accessibility coverage — Axe doesn't reach documents or Swift/Kotlin UI; use Deque's axe-android/axe-ios or PAC 3 for PDFs | NVDA or JAWS for screen-reader path testing; automated tools can't replicate how a real screen-reader user navigates |
| Your team is new to accessibility and needs low-noise, actionable findings — Axe's false-positive rate is the lowest in the category | You need a single-page visual summary for a non-technical stakeholder — WAVE renders overlaid icons directly on the page and is easier to demo | Lighthouse for performance + SEO + accessibility in one report; run both in CI so you're not switching tools for different concerns |
| You're building a government or health sector product in NZ and need to evidence WCAG 2.1 AA compliance — Axe is the tool auditors recognise | Your codebase is a .NET or Java thick-client desktop app — Axe is a browser/DOM tool; use Accessibility Insights for Windows or Axe's enterprise platform for cross-platform coverage | Pa11y for headless batch-scanning entire sitemaps overnight; Axe for in-test assertions on specific user flows |
| Budget is constrained and you need zero licensing cost — axe-core (the open-source library) is MIT-licensed and free forever | You need full WCAG coverage without manual testing — no automated tool achieves this; plan for Axe to catch ~30% of issues, then schedule a manual expert audit for the remainder | A manual checklist against WCAG 2.1 success criteria that axe-core can't evaluate (SC 1.4.3 contrast in some contexts, SC 2.4.6 headings descriptiveness, all SC 3.x language criteria) |
What I would do
Practitioner judgment on tool adoption, team onboarding, and when to swap.
aria-label in a way that reads sensibly to the tool but confuses a screen-reader user.The bottom line: Axe is the best automated accessibility net you can cast across a web product — but treat a clean Axe report as the start of accessibility testing, not the end. Build it into CI so the easy wins are always protected, then spend your manual testing time on the judgment calls that no tool can make.
Interview questions
Questions you are likely to get if you list axe on your CV — with what interviewers are really testing for.
What is axe-core and what kinds of accessibility issues can it detect automatically?
What they’re really testing: Whether you understand the scope and limits of automated accessibility checking, not just that you know the tool’s name.
Strong answer covers: axe-core is an open-source rules engine that checks DOM against WCAG 2.1/2.2 success criteria; it catches roughly 30% of accessibility issues (colour contrast, missing alt text, label associations, heading order, landmark roles); mention that NZ government digital standards recognise axe as the industry-standard automated tool, and that the remaining 70% requires manual and assistive-technology testing.
When would you choose axe over WAVE, and when would WAVE be the better pick?
What they’re really testing: Whether you can match the right tool to context rather than defaulting to one tool for everything.
Strong answer covers: axe for CI/CD integration and programmatic assertions inside Playwright or Cypress suites; axe has a lower false-positive rate, which matters when blocking deployments; WAVE for visual, stakeholder-facing demos because it renders overlaid icons directly on the page — handy when presenting findings to a NZ government client who needs to see issues in context without reading a JSON report.
You’re a QA engineer at a Wellington public-sector agency. Axe returns zero violations on the new self-service portal. The delivery lead wants to close the accessibility ticket. What do you do?
What they’re really testing: Whether you know that a clean axe report is the beginning of accessibility testing, not the end, and whether you can hold that position under delivery pressure.
Strong answer covers: Push back with evidence — explain that axe covers ~30% of WCAG criteria; commit to a keyboard-only tab run and an NVDA or VoiceOver screen-reader pass before closing; reference NZ’s Human Rights Act and Web Accessibility Standard 1.1 obligations as the business reason why “axe passed” is not sufficient sign-off for a public-sector portal.
Your axe assertions pass in local Playwright runs but the same tests fail in the GitHub Actions CI pipeline with a colour-contrast violation. How do you investigate?
What they’re really testing: Debugging depth and environment-awareness — can you reason about why a headless environment produces different results than a headed one.
Strong answer covers: Headless Chromium in CI defaults to a light colour scheme; check whether the app switches to a dark or high-contrast theme based on prefers-color-scheme and whether that theme has a contrast issue; reproduce by setting colorScheme: 'dark' in Playwright config locally; also check if CI is running against a different build (minified CSS, CDN assets) than local dev.
How would you structure axe checks across a large Playwright suite so accessibility failures block the right pipelines without creating noise that teams learn to ignore?
What they’re really testing: Whether you can think architecturally about accessibility quality gates, not just whether you know the API.
Strong answer covers: Scope axe to critical user flows (login, checkout, form submission) rather than every page — full-page scans on marketing content generate noise without protecting real user journeys; configure runOnly: { type: 'tag', values: ['wcag2a', 'wcag2aa'] } so you’re testing to a defined standard; treat violations as hard failures in CI and log incomplete (needs-review) items separately for a manual triage queue; for NZ health or finance sector products, document the standard you tested against (WCAG 2.1 AA) in your test report to satisfy audit evidence requirements.