Accessibility Audit – WCAG & EAA Compliance Checker

Find out where your site fails WCAG 2.2 — and build the accessibility information the European Accessibility Act requires you to publish. Accessibility Audit scans your published pages and posts against 25 automated checks and reports what to fix, grouped so that one theme colour failing on twelve pages reads as one fix, not twelve problems.

The scan runs in your own browser

No page content is ever sent anywhere. The scan loads each page in a frame inside your WordPress admin and reads the finished, rendered result — which is why it can measure real colour contrast, resolving inherited colours, translucent overlays and CSS variables. A server-side HTML parser cannot see any of that: it reads the source, not what a visitor sees.

That also means: no scanning service, no API key, no per-scan fee, and nothing added to your front end for visitors. The plugin contacts WPBay to validate your purchase code and check for updates, which carries licence and site metadata only — never page content, scan results, or anything about your visitors. Usage analytics are switched off.

What it checks

25 automated checks. Eighteen map to a WCAG 2.2 success criterion, across fourteen distinct criteria at levels A and AA: 1.1.1, 1.3.1, 1.3.5, 1.4.2, 1.4.3, 1.4.4, 2.4.1, 2.4.2, 2.4.4, 2.5.8, 3.1.1, 3.1.2, 3.3.2 and 4.1.2 — images without alternative text, buttons and links with no accessible name, form fields with no label, insufficient contrast, tables without header cells, frames without a title, focusable elements hidden from screen readers, blocked pinch-zoom, autoplaying audio, and more.

The other seven are recommended practice, and the report says so. A skipped heading level, a missing h1, an empty heading, a duplicate id, a positive tabindex, vague link text, a missing main landmark: all worth fixing, none of them a conformance failure. WCAG does not require sequential heading levels, “read more” can satisfy 2.4.4 from its surrounding context, and 4.1.1 Parsing was removed from WCAG 2.2 altogether. Tools that present these as WCAG failures inflate their own numbers and yours. Every finding here is labelled, so you always know which ones a conformance claim rests on.

A report you can act on

• Grouped by rule, not by page. Each group shows impact, the WCAG criterion where there is one, and how widespread it is — “12 occurrences across 3 pages”.
• Straight to the fix. Where possible each finding links to that page’s editor or to the Media Library entry. That is the advantage of running inside WordPress instead of as an external scanner.
• A verdict in words, not just a number. A bare score invites the wrong conclusion; the report says plainly whether critical barriers are blocking people.
• Comparison between scans. Fix something, scan again, and see exactly which rules cleared — and which are new.

The European Accessibility Act information

Since 28 June 2025 businesses providing services to consumers in the EU must publish information about the accessibility of those services. With a licence, the generator builds it and publishes it as a real page you can link from your footer.

It follows Annex V of Directive (EU) 2019/882, which is what actually applies to a business: a description of the service in accessible formats, what someone needs in order to understand how it works, how the accessibility requirements in Annex I are met, and how your delivery process and its monitoring keep it that way. If you are a public sector body it builds the other document instead — the model in Implementing Decision (EU) 2018/1523, under Directive (EU) 2016/2102. Most tools conflate the two; they are different obligations.

The known-barriers section is prefilled from your latest scan, with a success criterion attached only where there genuinely is one. The generator argues back when the document does not hold together: full conformity claimed while your own scan still shows failures, disproportionate burden invoked with no assessment date behind it, or a microenterprise being handed a compliance claim that Article 4(5) exempts it from making.

Publishing a page is not a filing. Where your country requires submission through a national portal, this does not replace that — and nothing here is legal advice.

Free and licensed

Without a licence the scanner is complete and genuinely usable: 20 checks, up to five pages per scan, the last three scans kept, full report and comparison.

A licence adds:

• Every page, with no five-page limit
• Five further checks: touch target size (2.5.8 AA), autocomplete on personal data fields (1.3.5 AA), list structure (1.3.1 A), language of parts (3.1.2 A), and a main landmark, which is recommended practice
• Unlimited scan history
• The accessibility information generator, for the EAA or the public sector regime

One download either way. Entering your purchase code unlocks everything in place — nothing to re-install.

Requirements

• WordPress 6.2 or newer
• PHP 7.4 or newer
• A modern browser for the admin screen — the scan runs there

What it does not do

Being straight about this saves us both time.

• Automated testing finds roughly a third of accessibility barriers. A clean report is a good sign, not a conformance statement. Keyboard and screen reader testing by a person is still required for WCAG or EAA conformance, and no tool on the market changes that.
• It scans pages and posts. Individual WooCommerce product pages are not in the scan list. Your shop, cart and checkout pages are, because those are pages.
• Pages that refuse to be framed cannot be scanned. If a page sends X-Frame-Options: DENY or a restrictive frame-ancestors, you get a clear error rather than a false “clean” result.

Tested against

WordPress 7.0, six themes (Twenty Twenty-Five, Twenty Twenty-One, Astra, GeneratePress, OceanWP, Kadence), Elementor and SiteOrigin, multisite, a 510-item site, and a single page with 3000 paragraphs. Alongside WooCommerce, Contact Form 7, WPForms and ACF with no conflicts.

During that testing the scanner found a genuine WCAG 4.1.2 failure in WooCommerce’s own Mini Cart — a drawer marked aria-hidden="true" whose buttons stay visible and reachable by keyboard. It finds real problems in real software.

Questions worth asking before you buy

Will this make my site compliant?
No, and no automated tool can. Automated testing finds roughly a third of real accessibility barriers; the rest needs a person with a keyboard and a screen reader. This plugin finds and explains the mechanical failures fast, and says plainly in the report that a clean result is not a conformance statement. Any tool that promises compliance is selling you a false sense of safety — in 2025 the US Federal Trade Commission fined an overlay vendor $1 million for exactly that claim.

Is it an overlay?
No. It changes nothing on your front end and adds no script for visitors. It reports what is wrong so you can fix it. Overlays do not make a site conformant, and in the first half of 2025, 22.6% of US accessibility lawsuits targeted sites that had one installed.

Do I even need this?
Possibly not. Article 4(5) of Directive (EU) 2019/882 exempts microenterprises providing services — fewer than 10 people, and turnover or balance sheet not above €2 million — from the accessibility requirements for services altogether. The generator asks, and if you say yes it explains the exemption instead of building you a conformity claim you do not owe. Accessibility is still worth doing; the exemption is from the obligation, not from your users.

Is the document it generates legally sufficient?
It is a starting point built from what you tell it and what your site actually does, structured on the provision that applies to you — Annex V of Directive (EU) 2019/882 for a business, or the Implementing Decision (EU) 2018/1523 model for a public sector body. It is not a filing: where your country requires submission through a national portal, publishing a page does not replace that. And nothing in the plugin is legal advice.

Does anything leave my site?
The scan contacts nothing — no API, no account, no per-scan fee, and your page content never leaves the browser it is scanned in. The plugin does contact WPBay to validate your purchase code and check for updates, which carries licence and site metadata only. Usage analytics are switched off.

Are all 25 checks WCAG failures?
No, and this is the question most tools answer badly. Eighteen map to a WCAG 2.2 success criterion, across fourteen distinct criteria at levels A and AA. The other seven are recommended practice, and the report labels them as such. A tool that presents every finding as a WCAG failure inflates its own numbers and yours — and yours is the one that ends up in a published conformance claim.

A fuller statement of what these products claim and what they do not is at groundedwp.com/what-we-claim.