WordPress Accessibility Checker: Why You Need Rendered Page Scans
If you are looking for a WordPress accessibility checker, you've likely found a dozen tools offering automated scanning via an API. They promise to crawl your site, check the HTML, and return a report.
But there is a fundamental problem with this approach: they scan the HTML your server sends, not the page the visitor actually sees.
In this post, we explain why rendered page scans are essential for an accurate WCAG 2.2 accessibility audit and why we built our tool to run entirely inside your wp-admin dashboard.
The Flaw in API Scanners
Modern WordPress sites rely heavily on JavaScript, complex CSS, and dynamic page builders. When an external API scanner pings your URL, it reads the raw markup.
This causes massive blind spots, particularly regarding color contrast:
- It cannot accurately measure text placed over a translucent overlay.
- It cannot determine the color of text that inherits its style dynamically from a parent element.
- It flags false positives for elements that are hidden from the user by CSS or JavaScript.
If your accessibility checker can't read the resolved styles, your report is full of noise.
The Solution: Rendered Page Scans
To fix this, we built the Accessibility Audit plugin differently. Instead of sending your pages to an external API, it loads your published pages into a frame inside your own wp-admin dashboard.
It checks the rendered result—the exact visual and structural page your visitor experiences.
- Color contrast is measured on the final resolved styles.
- No scanning API: Your page content is never uploaded anywhere and there is no account to create. The plugin does contact WPBay to validate a purchase code and to check for updates, which carries licence and site metadata only — never page content, scan results, or anything about your visitors.
- Your data stays on your server.
Grouped Findings (Stop the Noise)
Another issue with traditional checkers is how they report errors. If your theme uses an inaccessible color for primary buttons, and that button appears on 50 pages, a traditional scanner reports 50 separate errors.
Our tool groups findings by rule rather than by page. Twelve contrast failures caused by a single theme color read as one single fix on your report.
Honest About the Numbers (What Automation Misses)
Many tools present every single finding as a strict WCAG failure, inflating their numbers to look more valuable. We don't.
Our plugin runs 25 automated checks:
- 18 checks map directly to a WCAG 2.2 success criterion (across 14 distinct criteria at levels A and AA).
- 7 checks are recommended best practices, and the report clearly labels them as such.
We are also honest about the limits of automation: automated testing finds roughly a third of real accessibility barriers. A clean report is a great sign, but it is not a conformance statement. Human testing with a keyboard and screen reader remains necessary.
(Need to build compliance documentation? Learn how the licensed version generates the required European Accessibility Act (EAA) Annex V documents.)
Start Your Audit Now
Get an accurate, noise-free accessibility report of your rendered WordPress site without sending your page content to an external scanning API.
Start testing your most critical pages in less than two minutes.
Get Accessibility Audit on WPBay
FAQ
Does this plugin slow down the front-end of my site? No. The scans happen on-demand inside your wp-admin dashboard. There are no tracking scripts or continuous scanning agents running on the front-end of your site that would affect performance for your visitors.
What is the difference between the free and licensed versions? Without a license, the plugin runs 20 checks on up to five pages per scan, provides the full report, and lets you compare history between scans. The licensed version adds 5 additional checks, allows unlimited pages per scan, offers unlimited history, and includes the EAA document generator.
Does this plugin fix the issues automatically? No. Accessibility overlay tools that promise to "automatically fix" issues with JavaScript frequently create new barriers for screen reader users, and in 2025 the US Federal Trade Commission fined an overlay vendor $1 million over claims that its product could make websites WCAG-compliant. Our tool audits your site and tells you what needs fixing at the source code or content level; the fixing is yours.
Sources: Directive (EU) 2019/882 · WCAG 2.2
I am a developer, not a lawyer, and none of this is legal advice. Article 4(5) of the EAA exempts microenterprises providing services altogether, which is worth reading before you buy any compliance tooling — ours included.