Category: Testing and Evaluation

axe DevTools

Also known as: Axe DevTools, Axe DevTools Pro, Axe DevTools for Web, axe DevTools Extension

Simply put

axe DevTools is a suite of automated accessibility testing tools, developed by Deque, that helps developers find and fix accessibility issues while building websites and apps. It includes a browser extension for web testing as well as toolkits for web, iOS, and Android, and can be integrated into existing automated testing processes. Automated tools like this detect only a portion of accessibility issues, so manual and assistive technology testing remain necessary.

Formal definition

axe DevTools is a family of accessibility testing products from Deque that build on the axe-core rules engine to evaluate web content against accessibility criteria. The Pro version combines the automated results of axe-core with results from axe Intelligent Guided Test (IGT) tools, and Deque lists this implementation among the W3C WAI Accessibility Conformance Testing (ACT) implementations. The product line spans a browser extension, APIs, and a command-line interface (CLI) for web, plus toolkits for iOS and Android, allowing accessibility checks to be embedded within existing automated testing workflows. As with all automated tooling, it surfaces only the subset of issues detectable by programmatic rules; conformance to WCAG success criteria and legal compliance also require manual review and testing with assistive technologies.

Why it matters

Accessibility defects are generally easier and cheaper to correct when they are caught early in the development process, before code reaches production and before issues compound across a growing codebase. Tools like axe DevTools give developers a way to surface programmatically detectable accessibility problems directly within their existing workflows, whether in the browser during development or embedded in automated testing pipelines for web, iOS, and Android. This can help teams treat accessibility as a routine part of quality assurance rather than an afterthought.

At the same time, it is important to understand what automated tooling can and cannot do. Automated accessibility testing detects only a portion of the issues that affect real users, because many WCAG success criteria depend on human judgment, context, and interaction that programmatic rules cannot fully evaluate. Passing automated checks does not by itself demonstrate conformance to WCAG or guarantee an accessible experience, and it does not confer immunity from legal claims. Deque lists axe DevTools Pro among the W3C WAI Accessibility Conformance Testing (ACT) implementations, but ACT implementation reflects how a tool maps to shared rule definitions rather than certifying legal compliance.

For these reasons, axe DevTools is most useful as one layer within a broader accessibility strategy that also includes manual review and testing with assistive technologies. Organizations should treat it as an aid to finding and fixing issues, not as a complete measure of accessibility or compliance, and should consult qualified legal counsel for questions about their specific obligations, which vary by jurisdiction and continue to evolve through regulation and case law.

Who it's relevant to

Developers and Engineers

Front-end and application developers can use the browser extension, APIs, and CLI to find and fix accessibility issues early in web development, and the iOS and Android toolkits to extend testing to mobile. Embedding checks in existing automated pipelines helps catch programmatically detectable problems before they reach production.

Quality Assurance and Test Teams

QA teams can integrate axe DevTools into automated testing workflows to add accessibility coverage alongside other quality checks. They should pair automated results with manual and assistive technology testing, since automated tooling detects only a portion of accessibility issues.

Accessibility Specialists

Accessibility professionals can use the guided testing capabilities of the Pro version, which combine axe-core results with axe Intelligent Guided Test (IGT) tools, to work through checks that require human judgment. The tool supports, but does not replace, expert manual evaluation.

Compliance Officers and Legal Counsel

Those responsible for accessibility programs should understand that automated testing and ACT implementation status do not by themselves establish WCAG conformance or legal compliance. This entry is not legal advice; obligations vary by jurisdiction and evolve through regulation and case law, so consult qualified counsel for specific circumstances.

Inside axe DevTools

Automated Accessibility Scanner

A rules-based engine that evaluates web content against a subset of WCAG success criteria and flags detectable issues such as missing alternative text, insufficient color contrast, and improper ARIA usage.

Browser Extension and Developer Integrations

Tooling commonly delivered as a browser extension and available for integration into development workflows, allowing engineers to run checks during design, development, and testing phases.

Issue Reporting and Guidance

Output that identifies flagged elements, describes the nature of each potential violation, and often references the relevant WCAG success criterion to help practitioners understand and remediate findings.

Guided Manual Testing Features

Assistive functionality intended to support human reviewers in evaluating issues that automated rules cannot reliably detect, acknowledging that automated scanning covers only a portion of accessibility barriers.

Common questions

Answers to the questions practitioners most commonly ask about axe DevTools.

Does passing all axe DevTools checks mean my site is fully WCAG compliant and legally safe?

No. Automated tools like axe DevTools detect only a portion of accessibility issues, and estimates commonly cited suggest automated testing catches a minority of WCAG-related problems. Many success criteria require human judgment, for example, whether alternative text is meaningful, whether reading order is logical, or whether a control is genuinely operable with assistive technology. A clean automated scan does not establish WCAG conformance, does not guarantee a usable experience for people with disabilities, and does not confer immunity from legal claims. Manual testing and testing with assistive technologies remain necessary, and questions about legal exposure should be directed to qualified legal counsel.

Is axe DevTools an official standard or does it decide what counts as accessible?

No. axe DevTools is a vendor testing tool, not a standard-setting authority. The applicable technical benchmarks are the Web Content Accessibility Guidelines (WCAG) published by the W3C through the Web Accessibility Initiative. axe DevTools maps many of its automated rules to WCAG success criteria, but the tool's results reflect its own rule implementations rather than an authoritative determination of conformance. Distinguish the tool's reporting from the underlying WCAG criteria and from any legal obligations under authorities such as the ADA or Section 508.

How should axe DevTools fit into a broader testing workflow?

It is generally used as an early, repeatable layer that surfaces programmatically detectable issues, complemented by manual review and assistive technology testing. Teams commonly run automated scans during development and in continuous integration to catch regressions, then rely on human evaluation for criteria that automation cannot reliably assess, such as meaningful alternative text, logical focus order, and overall keyboard and screen reader usability.

At what point in the development process is axe DevTools typically run?

It is often integrated at multiple points: during active development through browser extension checks, and within automated pipelines so scans run on builds or pull requests. Running checks early and repeatedly can help identify issues before they reach production, though this shift-left approach supplements rather than replaces later manual and assistive technology testing.

Which WCAG conformance level should I configure axe DevTools to target?

Level AA is the conformance level most commonly cited as a target in policies, settlements, and agency guidance, so many teams configure automated checks with AA in mind. Keep in mind that the tool can only evaluate the subset of criteria that are programmatically testable, so aligning its ruleset to a level does not by itself demonstrate conformance to that level. Confirm which WCAG version and level apply to your context, and consult qualified counsel where legal obligations are at issue.

How should I handle issues axe DevTools does not report?

Treat the absence of reported issues as incomplete rather than conclusive. Because automated tools detect only part of the WCAG landscape, plan for manual checks, keyboard-only navigation, screen reader testing, evaluation of alternative text quality, color and contrast in context, and dynamic content behavior, to cover criteria that require human judgment. Documenting both automated and manual findings supports a more complete accessibility assessment.

Common misconceptions

Passing an axe DevTools scan with no errors means a site is fully accessible or legally compliant.

Automated tools detect only a portion of accessibility issues. A clean automated scan does not guarantee an accessible experience for all users, nor does it ensure conformance with WCAG or immunity from legal claims. Manual review and assistive technology testing are generally required.

Using axe DevTools satisfies the ADA's technical requirements for websites.

The ADA is a US civil rights law and does not itself contain detailed web technical specifications. WCAG is often cited as a benchmark in settlements and guidance rather than codified in the ADA. A testing tool measures against WCAG criteria it can evaluate, but it does not establish legal compliance, and readers should consult qualified legal counsel.

The tool tests against every WCAG success criterion across all versions and levels.

Automated rules can evaluate only those criteria that lend themselves to programmatic detection. Many success criteria, including numerous Level AA and AAA requirements, depend on human judgment and cannot be fully assessed by automation.

Best practices

Treat automated scan results as a starting point, and pair them with manual testing and evaluation using assistive technologies such as screen readers and keyboard-only navigation.

Integrate accessibility checks early and repeatedly throughout design and development rather than relying on a single scan late in the process.

Define a clear conformance target, commonly WCAG 2.1 Level AA, and verify which version and level your testing is evaluating against.

Have qualified reviewers investigate flagged issues and reference the cited WCAG success criteria to confirm findings and plan remediation.

Do not interpret a passing automated result as legal compliance; consult qualified legal counsel and monitor evolving regulations and case law for your jurisdiction.

Document your testing methodology, including the portions covered by automation versus manual review, to support informed and defensible accessibility decisions.