What it checks
Scans run in DevTools against the rendered page — not a copy of your source, not a crawled snapshot. What the scanner sees is what the browser built, after your JavaScript has run.
- The complete axe-core rule set, plus additional checks for problems axe does not cover.
- Inside iframes. Embedded checkouts, players and widgets are scanned and merged into one report rather than skipped.
- Inside shadow DOM, so web components are checked like any other markup.
- Keyboard reachability, focus order and positive
tabindex. - Colour contrast, with the measured ratio and the nearest passing colour.
Fixes, not just failures
Each finding carries the opening tag that caused it, a CSS selector you can paste into the console, and a suggested fix.
When the page is built with a framework the scanner recognises — Angular, React, Vue, Svelte or Ember — you get a second version of the fix written in that framework’s idiom, along with the evidence that led it to that guess. Detection changes the suggestions. It never changes the findings.
Where the results go
Results render in the panel you scanned from, and a full report tab opens alongside it. That tab is reused across scans rather than spawning a new one each time, so a fix-and-recheck loop refreshes in the background instead of pulling you out of the page you are editing.
Worth knowing: Automated rules find a meaningful subset of accessibility problems — commonly cited as between a third and a half of WCAG failures. No scanner establishes conformance on its own, which is what the guided manual checks are for.
Start with the page you are on
Install the extension, press F12 and open the Accessibility tab. No account, nothing to configure, and nothing leaves your machine.