Web accessibility (a11y) often feels like a daunting checkbox at the end of a project. In my experience, trying to fix accessibility bugs right before a production release is a recipe for stress and technical debt. That’s why I’ve integrated automated testing into my daily workflow. If you’re wondering how to use axe DevTools to make your sites more inclusive, you’re in the right place.
axe DevTools is a browser extension that allows you to scan your web pages for accessibility violations based on WCAG (Web Content Accessibility Guidelines). Unlike some tools that just give you a score, axe helps you pinpoint the exact line of code causing the issue and tells you how to fix it. It’s one of the best Chrome extensions for web developers in 2026 because it bridges the gap between ‘knowing’ a site is broken and ‘knowing’ how to fix it.
Prerequisites
Before we dive into the scanning process, ensure you have the following set up:
- Google Chrome or Firefox: While axe works on several browsers, I find the Chrome integration most stable.
- The axe DevTools Extension: Installed from the Chrome Web Store or Firefox Add-ons gallery.
- A Local or Live Project: Any website you’re currently developing that you want to audit.
Step-by-Step: How to Use axe DevTools for Accessibility Audits
Step 1: Launching the Tool
Once the extension is installed, you don’t actually click a button in your browser toolbar to start the scan. Instead, axe lives inside your developer tools.
- Open the page you want to test.
- Right-click anywhere on the page and select Inspect (or press
F12/Cmd + Opt + I). - In the top navigation bar of the DevTools panel, look for the axe tab. If you don’t see it, click the double arrow (
>>) to reveal hidden tabs.
Step 2: Running Your First Scan
Now that you’re in the axe tab, it’s time to analyze the DOM. Click the “Scan all of my page” button.
The tool will now run a series of automated checks. Within seconds, you’ll see a list of issues categorized by severity: Critical, Serious, Moderate, and Minor. As shown in the image below, the tool doesn’t just list the error; it provides a direct link to the element in the DOM.
Step 3: Analyzing and Fixing Violations
This is where the real work happens. When you click on a specific issue—for example, “Buttons must have discernible text”—axe will highlight the offending element on your live page.
If I encounter a button that only contains an icon, I know I need to add an aria-label. Here is how I typically handle that in my code:
<!-- Bad: Screen readers can't tell what this does -->
<button class="btn-close">
<i class="fas fa-times"></i>
</button>
<!-- Good: Accessible to all users -->
<button class="btn-close" aria-label="Close modal">
<i class="fas fa-times"></i>
</button>Step 4: Re-scanning for Verification
After applying your fixes in your IDE, you don’t need to refresh the entire page if you’re using a framework like React or Next.js with Hot Module Replacement (HMR). Simply click “Scan all of my page” again to verify that the violation has disappeared from the list.
Pro Tips for Better Accessibility Workflow
After using axe for several years, I’ve picked up a few tricks to make the process more efficient:
- Focus on ‘Critical’ First: Don’t get overwhelmed by 50 minor warnings. Fix the Critical and Serious issues first; these are the ones that completely block users with screen readers.
- Test Different Viewports: Accessibility isn’t just about screen readers; it’s about zoom and layout. Open DevTools device mode, switch to a mobile view, and run the axe scan again. Some issues only appear when the layout shifts.
- Combine with Manual Testing: Remember that axe only catches about 30-50% of accessibility issues. It cannot tell you if your tab order is logical or if your alt text actually makes sense in context. Always perform a manual keyboard-only navigation test.
Troubleshooting Common Issues
Sometimes you might encounter hurdles while using the tool. Here are the most common ones I’ve faced:
| Issue | Solution |
|---|---|
| axe tab is missing in DevTools | Restart Chrome or ensure the extension is enabled in chrome://extensions. |
| Scan doesn’t find known issues | Ensure the page is fully loaded. If you have a single-page app (SPA), navigate to the specific route before scanning. |
| ‘Cannot access DOM’ error | This usually happens on restricted pages (like Chrome internal pages). Try scanning on a standard http/https URL. |
What’s Next?
Now that you know how to use axe DevTools for manual audits, the next logical step is to automate this process. You don’t want to rely on manual scans for every single PR. I recommend looking into @axe-core/react or cypress-axe to catch these bugs in your CI/CD pipeline.
If you want a more detailed breakdown of the tool’s capabilities and how it stacks up against alternatives, check out my axe DevTools review. For those looking to broaden their toolkit, I’ve also compiled a list of the best Chrome extensions for web developers to boost your productivity.