How to get a website accessibility report you can hand to someoneWAVE vs. axe DevTools vs. Lighthouse vs. Page Scanner

The person who runs an accessibility check is often not the person who acts on it. A client wants to know what is wrong with their site, a content editor needs to see which images lack text, a manager wants something to attach to a ticket. Every tool below finds problems on a page. They differ in what is left once the check is done: a view inside your browser, a data file for another tool, a printout of a developer's report, or a PDF of the page with the problems drawn on it.

Four tools at a glance

✓ yes, ✗ no, Pro on that paid plan. An empty cell is one the product's own pages do not answer.

What makes a report something you can pass on

A check that lives in your browser's developer tools is the right shape for the developer who will fix the page: they click a problem, the element lights up, they change the code and run it again. The person who asked for the check usually does not have those tools open, and should not need them. For them a report has to open on its own, show where on the page each problem is rather than only a CSS selector, say which rule failed, and say what an automated check cannot tell you. The last part matters more than it seems, because a short list is easy to read as a pass.

WAVE

WAVE is WebAIM's evaluation tool, which its about page describes as "made available as a free community service" by WebAIM at Utah State University. The extensions for Chrome, Firefox and Edge check the page in your browser, and WebAIM says plainly that "no information is sent to the WAVE server", so it works on intranet, local and password-protected pages. It puts icons into the page itself: red for errors, green for features that probably help, and others, yellow alerts among them, for things a person should look at. It shows each image's alternative text so you can judge it, and it can turn the page's styles off to show the reading order.

WAVE is direct about what a check means. Its help page says "the absence of errors DOES NOT mean your page is accessible or compliant", and WebAIM gives no badge or approval for passing. It also checks hidden elements on purpose, such as a closed menu or a dialog, since a user will see them at some point.

What you hand on is less clear from WebAIM's own pages. The extension page, the help page and the store listing describe running the report and reading it; none of them describes saving or exporting it. The online WAVE has a report address for a public page (wave.webaim.org/report?url=…), which you can send as a link. The WAVE API returns results "in either JSON or XML format", with 100 free credits and then $0.025 to $0.04 a credit, one credit being a basic check of one page. For a report with people in it, the AIM report adds expert manual testing of four pages, notes and recommendations, and a spreadsheet of WAVE data, at "$500 for a one-time scan of up to 20,000 web pages".

Verdict: a clear view for a person learning to evaluate a page, and the only one here that offers a human review, as a paid report.

axe DevTools

axe DevTools is Deque's extension built on axe-core, which, in Deque's words, "powers the Axe DevTools Extension". It opens as an "axe DevTools" tab in the browser's developer tools. Deque's documentation lists what every user gets, a full-page scan and a report with a breakdown of each issue, highlight, inspect, the element's CSS selector and source, how to fix it and the rule's help page, and what needs a Pro or Axe DevTools for Web subscription. Exporting is on the second list. The installation notes put it in so many words: "'Pro' functionality (saving, exporting, Intelligent Guided Testing, usage reporting, etc.) is only available in the Chrome and Edge versions."

With Pro, the export is CSV, JSON or JUnit XML, and saved tests can be shared as links. Pro also brings Intelligent Guided Tests, which walk a tester through the checks automation cannot decide, and user flows across several pages. The pricing page lists no price for Pro; it offers a 14-day trial that needs no payment details and falls back to the free plan when it ends.

Verdict: built for the developer or tester doing the fixing, and on Pro the right export for a bug tracker or a test pipeline. None of its documented exports is a document for a reader.

Lighthouse

Lighthouse is Google's open-source auditing tool, in Chrome's DevTools, on the command line and as a Node module. Its accessibility audits run on axe-core (axe-core is a dependency in its package.json), and its accessibility score is "a weighted average of all accessibility audits", weighted by axe's impact ratings. Each audit passes or fails as a whole, and the report lists the manual checks it cannot make, which do not count towards the score.

Of the three developer tools, Lighthouse's report is the one you can print without a subscription, or save as a PDF from the print dialog. The report's menu has Print Summary and Print Expanded, which open it in a print dialog, and Save as HTML and Save as JSON; the command line writes HTML, JSON or CSV. The report shows each failing element as a small cut from a screenshot of the page. As a handout, its accessibility audits share the report with performance, best practices and SEO unless you run --only-categories=accessibility, and it is still a developer's report: rule names, selectors and code.

Verdict: a free report that can be printed, from a tool already in Chrome.

Page Scanner

Page Scanner checks the page with axe-core too, version 4.13.0, so it finds the same kinds of problems axe DevTools and Lighthouse find; it runs only the rules tagged WCAG 2.0, 2.1 and 2.2, levels A and AA, and leaves axe's best practices out. The difference is what it writes. Page Scanner is a full-page capture tool, so the check runs on the page laid out exactly as the capture is, and the result is drawn onto that capture:

• In the editor. With Check accessibility on in the settings (off by default), each scan from the popup also runs the check, and the editor's rail gets an Accessibility panel: how many rules failed and by how many elements, then each rule with its impact, axe's statement of it and a link to Deque's page on it, and its elements numbered. While the panel is open every failing element is boxed on the page in its impact's color, red for critical, orange for serious, blue for moderate and gray for minor.
• The marked PDF. Download marked PDF saves the capture as a vector PDF with each failing element boxed and numbered where it is, then A4 sheets that list each rule with its WCAG tags, and each element by number, selector and axe's line on what is wrong. Its first sheet says that an automated check finds some of what fails WCAG, not all. The text is real text, so a reader can search it for a selector or copy a rule's name.
• From a script or an agent. The same files come from the command line, and from the MCP server's scan_page with accessibility:

page-scanner scan --url https://example.com/ --accessibility --out ./example.pdf

That writes example.pdf, example.accessibility.pdf and example.accessibility.json, the whole report with each element's box. Add --page-width phone and the page is laid out 390 px wide first, so the check and the boxes are on the phone layout.

The page is checked on your computer, and nothing about it is sent anywhere. On W3C's deliberately inaccessible demo page the check found 6 rules failed by 46 elements, every one boxed; on Wikipedia's article on web accessibility, 18,916 px tall, 4 rules and 32 elements in 800 ms.

What it costs and where it stops: an element inside a frame or a shadow root is listed but not drawn, and a hidden element is listed as not on the page. The report keeps 500 elements and counts the rest. A raster capture has no check, and the rule list is set in Helvetica, so a character outside Latin-1 in a selector shows as ?. It checks the scans made after the setting is on, not a capture already open. Each scan goes through Chrome's debugger, so Chrome's "started debugging this browser" bar shows while it runs. And it is the automated check only: there is no guided testing and no score.

Verdict: the one to use when the report is for someone who will read it rather than run it.

Which should you use?

Use WAVE if you are learning to evaluate a page yourself and want the problems and the alt text in place on the page, or you want WebAIM's paid AIM report with human testing.

Use axe DevTools if you are the developer or tester fixing the issues, and on Pro if the results have to go into a tracker, a spreadsheet or a test run.

Use Lighthouse if you want a free report you can print or save as HTML, and a score to track over time.

Use Page Scanner if the report goes to someone who has no developer tools open: a PDF of the whole page with each problem boxed where it is and the rules listed after it.

Frequently asked questions

Does a report with no problems mean the site is accessible or compliant? No, from any of these tools. Automated rules decide what can be decided from the code, not whether alt text says the right thing or the page reads in a sensible order. WAVE's help says so in capitals, Lighthouse lists manual checks beside its score, and Page Scanner's marked PDF says it on its first sheet. None of the four certifies a site.

Can I check a page behind a login? WAVE's extension says it handles password-protected pages, and Lighthouse's documentation says its DevTools panel can audit pages that require authentication. Page Scanner checks the page in your own Chrome, so a tab you are signed in to is checked as it stands.

Why do WAVE and axe report different numbers? They are different engines. WAVE runs WebAIM's own and checks hidden elements on purpose; axe DevTools, Lighthouse and Page Scanner run axe-core. Page Scanner lists a hidden element but cannot draw a box for it, since it has no place on the capture.

Can I check the mobile layout? Choose Narrowed to a phone in Page Scanner's popup, or --page-width phone on the command line, and the page is laid out at a phone's width before the check. Capturing a site at phone, tablet and desktop widths covers what that width does and does not change.

Can an agent make the report? Yes, through the MCP server's scan_page with accessibility, which writes both files and returns their paths; letting an AI agent capture a web page covers the setup. For a batch run without an agent, see capturing a web page from the command line. The same extension can also read a site's colors and their contrast ratios as files, which extracting a website's design system covers.

Where this comes from

• WebAIM's WAVE browser extensions, WAVE help, About WAVE, WAVE API, AIM report and the WAVE Evaluation Tool in the Chrome Web Store.
• Deque's axe DevTools Extension documentation, Exporting Data and pricing.
• Chrome for Developers, Introduction to Lighthouse and Lighthouse accessibility score; Lighthouse on GitHub: its README, package.json, the report's menu labels and its element screenshots.
• Page Scanner's Check accessibility setting, Accessibility panel, page-scanner scan and scan_page documentation.