axe DevTools: Auditing Accessibility in the Browser and What It Misses
axe DevTools audits accessibility in the browser with the axe-core engine. What it checks, which plans it offers today, and what needs manual review.
What does axe DevTools do?
You open a page in the browser, run the extension, and get a list of issues grouped by severity and by WCAG criterion. Each finding shows the affected element, why it fails, and how to fix it. That makes it useful for concrete technical problems: insufficient contrast, an image without alt text, a form field without a label.
The official page describes the extension as a tool for automated testing and AI-driven guided tests, to find more issues than automation alone (Deque, “axe DevTools”). That guided part is what covers what a script can’t decide.
What plans does it have today?
According to Deque’s official pricing page (November 2026), there are three options (Deque, “Pricing”):
- Free extension: basic automated testing, page by page.
- Pro extension: adds AI-enhanced features, intelligent guided tests, user flow analysis, and Jira integration. It has a 14-day trial with the full feature set and no card required; when it ends, the account falls back to the free plan.
- Axe DevTools for Web (bundle): includes everything in Pro plus MCP connections, linter access, and CI/CD and API integrations. It is bought through sales.
The page doesn’t publish prices for Pro or the bundle, so confirm them with Deque before budgeting.
How complete is the automation?
This is the figure most often misread. In March 2021 Deque published a study of about 2,000 anonymized audits, more than 13,000 pages, and almost 300,000 issues, and concluded that, on average, its automated testing fully covered 57% of the issues found. The measure is total volume of issues, weighted by severity and impact, not the percentage of WCAG success criteria that a tool can test (Deque, “Automated testing study identifies 57 percent of digital accessibility issues”).
It is a useful number, with two limits. It comes from the vendor, and it measures something different from a share of criteria. What it does show is that automation finds a large part of the problems and leaves the rest for manual review.
Why should a designer care?
Because the extension lets you check the real version of the product, with the code that gets rendered, not only the design. A contrast value that passed in Figma can fail in the browser because a color is applied through another CSS rule. A button that looks right may have no accessible name.
It also helps you talk with development using evidence. Instead of saying “I think the button isn’t clear”, you can show the finding, the criterion it breaks, and the suggested fix.
What does it miss?
Automated tools can’t decide whether alt text describes an image well, whether the reading order makes sense, or whether an error message is clear. They don’t replace testing with screen readers or with people who use assistive technology. That is why screen reader testing remains part of the process.
For the color side, the math of color contrast helps you understand why a value fails and which change fixes it.
Example
Illustrative example: a team publishes a sign-up page. Running axe DevTools shows three problems: a field without an associated label, a “Read more” link repeated ten times with no context, and a submit button with insufficient contrast. All three are easy to fix, and the tool names the criterion for each. What doesn’t show up is whether error messages are announced properly to a screen reader. For that, the team runs a manual test with a reader and adds it to the list.
When NOT to rely on it
- As the only review. An automated audit is not a complete accessibility audit.
- To decide about intent or clarity. If a text confuses people, the tool doesn’t know.
- Before there is a design. To review the palette or states, Stark in Figma is useful before coding.
- As an excuse not to fix things. A report full of findings without a work plan just creates noise.
Common mistakes
- Declaring a page accessible because the extension found no errors.
- Ignoring low-severity findings without checking their impact.
- Fixing only what the tool flags and not the pattern that produces it.
- Running it once at the end, instead of building it into the workflow.
- Confusing the free version with the paid one without checking what each includes.
How to start tomorrow
Install the extension in your browser and open the most visited page in your product. Review the high-severity problems first. For each one, note the criterion, the element, and the fix. Then open one ticket per pattern, not per element: if the same error appears on ten buttons, the problem is in the component. Save each result with the date and the version you audited. That way you can compare the next review with this one and see whether problems go down or keep coming back, which is the signal that really matters. And add a accessibility review to your process that includes manual testing, not only this extension.