Description
Accessibility Audit finds the accessibility problems on your WordPress pages and tells you what
is wrong, which WCAG 2.2 success criterion it fails, which element is at fault, and how to fix
it. It is a scanner and a reporter for the person maintaining the site — not a widget bolted
onto the front end for visitors.
Scanning runs in your own browser using axe-core, the same open-source engine behind most
professional accessibility tooling. Your pages and your results are never sent anywhere. No
account, no API key, no scanning service, no setup wizard. Activate the plugin and scan a page
immediately.
This is not an accessibility overlay
Overlay widgets promise to “fix” accessibility with a line of JavaScript that rewrites your
page for visitors. They are rejected by the disability community, they have been the subject of
lawsuits, and they do not work. This plugin adds nothing to your front end at all. It shows you
what is broken so that you can fix it properly, in your content and your theme.
What the free version does, permanently
- Scan any post, page or custom post type on demand, from the row action in your lists or from the block editor sidebar.
- Re-scan automatically when you save a post in the block editor.
- Full detail on every issue: the axe rule, its impact level, the WCAG 2.2 success criterion it maps to, the CSS selector, the offending markup, and a link to the fix documentation.
- A dashboard across everything you have scanned: open issues, a breakdown by severity, and the worst offending pages.
- Ignore an individual issue, with a required written reason recorded against your name and the date.
- Generate a plain accessibility statement page.
There is no page limit, no scan quota, no trial period, and nothing that switches itself off
later. If you never buy the Pro version, nothing you use today stops working.
What Pro adds
Pro is for people who have to prove the work was done: a full ignore log with author, date and
reason, exportable; history and trend lines showing regressions; CSV and printable audit
exports; and the EN 301 549 statement form the European Accessibility Act expects. It also adds
a full-site scan queue, scheduled re-scans, a small set of genuinely safe server-side fixes (all
off by default), WP-CLI and a multisite network dashboard.
One notice, and one menu
The plugin shows exactly one dismissible admin notice, ever. It tells you where the plugin
lives and retires itself the moment you open that screen. It registers one top-level menu and
nothing else: every screen is a tab inside it. No banners, no countdown timers, no nags on
other people’s screens, no onboarding wizard, and nothing installed or suggested that you did
not ask for.
There is no activation step and no consent screen in your way. Licensing is handled by the
Freemius SDK, which starts switched off: nothing is registered and nothing is transmitted
unless you go and opt in, and everything works whether you ever do or not. The one thing not
in our hands is that opening the upgrade page adds a Freemius “Upgrade” item under the menu
while you are on it.
Screenshots
FAQ
Does this make my site WCAG compliant?
No, and be sceptical of any tool that says it does. Automated testing detects only a portion of accessibility barriers — commonly estimated at around a third. It is very good at the things machines can check: missing alternative text, insufficient colour contrast, unlabelled form fields, broken heading structure, invalid ARIA. It cannot tell you whether your alt text is meaningful, whether your page makes sense when read aloud in order, or whether a custom component actually works with a screen reader. This plugin finds the automatable third and is honest about the rest, including in the statement it generates for you.
Is this an accessibility overlay or a toolbar?
No. It adds nothing to your front end. Overlays inject JavaScript that alters your pages for visitors at runtime, which is a different product with a bad reputation it has earned — they frequently break the assistive technology they claim to help, and the disability community has been consistently clear that they are not a substitute for accessible markup. This plugin only reads your pages and reports on them.
What is the European Accessibility Act?
The EAA is EU legislation, in force since June 2025, that requires a range of products and services — including many websites and e-commerce operations — to meet accessibility requirements. In practice conformance is assessed against EN 301 549, which incorporates WCAG. It generally expects you to be able to show what you tested, when, what you found, and what you decided about anything you did not fix. That evidence trail is what the ignore log and the audit export exist to produce.
Does the plugin send my content anywhere?
No. axe-core is bundled with the plugin and runs in your browser, against your own site, on your own machine. Your pages, your scan results and your ignore reasons never leave your server.
The only component that could is the Freemius SDK, which handles licensing, and it starts switched off. It contacts nothing until you choose to opt in, and if you never do, it never does. Opting in is offered rather than required, it tells you exactly what it would share first (your WordPress user’s name and email address, your site address and title, your WordPress and PHP versions, and the list of plugins and themes installed), and every feature works the same either way.
Contrast ratios, computed styles and focus order only exist once a page has actually been laid out by a browser. There is no way to evaluate them by parsing HTML on the server, and any tool that claims to will give you wrong answers. So the scanner loads your page in an offscreen frame and measures the real rendered result. The frame is only ever created for a logged-in user with editing permission, and the scanning script is never loaded for ordinary visitors.
Can I scan drafts?
Yes. Unpublished posts are scanned through their preview link, and the result is recorded against the post itself, so its history carries over when you publish.
Can I translate it?
Yes, and it will always be free to do so. Every string is translatable and a POT file ships with the plugin.
Reviews
There are no reviews for this plugin.
Contributors & Developers
“Lodestone Accessibility Audit” is open source software. The following people have contributed to this plugin.
Contributors
Translate “Lodestone Accessibility Audit” into your language.
Interested in development?
Browse the code, check out the SVN repository, or subscribe to the development log by RSS.
Changelog
1.0.4
- The published accessibility statement now reads “3 pages were tested” rather than “3 page(s) were tested”. It is a document you put your own name to, and it should not look like nobody read it.
- The same fix in the Pro full-site scan queue and its WP-CLI commands, which counted pages the same way.
1.0.3
- Fixed: scanning did not work on sites using WordPress’ default “plain” permalinks. The scanner built a REST URL that put its argument inside the route name, so every scan failed with a routing error. It now works whichever permalink structure you use.
- The plugin’s own dashboard is now the first thing you see. Opting in to email updates is offered rather than required, and nothing is transmitted unless you choose it.
- The dashboard now keeps a “Scan another page” button once you have scanned something, instead of removing every control after the first scan.
- Prices are shown in euros per year on the upgrade page, matching the Pro tab, instead of being converted to a monthly figure in dollars.
- Authors and contributors are no longer shown the accessibility statement tab, which needs a capability they do not have, or the Pro pitch, which they cannot act on. They keep the dashboard and can scan their own drafts.
- Issues are now titled in plain English — “Images must have alternative text” rather than “image-alt”. The axe rule id is still shown, and still linked to its documentation.
- Fixed: the dashboard’s “nothing scanned yet” button sent Authors and Contributors to the Pages list, which they cannot open. It now points at the list their role can actually use.
- Fixed: the block editor sidebar reported “1 open issues”.
- Fixed: “0 further checks could not be decided automatically” was printed after every clean scan.
- The ignore log, CSV export and printable report now name WCAG success criteria in full (“1.1.1 Non-text Content (A)”) instead of printing axe’s internal tags.
- The Pro description no longer lists a safe fix that the Safe fixes screen does not offer.
- Clearer wording throughout on what the optional Freemius opt-in prompt is and what it shares.
1.0.2
- Ignoring or reopening an accessibility issue now refuses by default. Rulings on issues whose scan is missing, or on a scanned URL that is not a post, previously fell through the per-post check; they now require the Editor capability, and an issue with no scan behind it can be ruled on by nobody.
1.0.1
- Site-wide figures, the ignore log, the history chart and the printable report now require the Editor capability. Authors and Contributors see the dashboard scoped to their own content instead of the whole site.
- The full-site scan REST endpoints now require the same administrator capability as the screen that drives them.
- Class and view loading is restricted to files inside the plugin directory.
1.0.0
- Initial release.