=== Lodestone Accessibility Audit ===
Contributors: loureiro70
Tags: accessibility, wcag, a11y, eaa, ada
Requires at least: 6.4
Tested up to: 7.1
Requires PHP: 7.4
Stable tag: 1.0.4
License: GPLv2 or later
License URI: https://www.gnu.org/licenses/gpl-2.0.html

Scan any page for accessibility problems, get WCAG 2.2 detail on every issue, and publish a dated accessibility statement. Not an overlay.

== 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.

== Frequently Asked Questions ==

= 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.

= Why does the scan open my page in a hidden frame? =

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.

== Screenshots ==

1. The dashboard: open issues by severity and the worst offending pages.
2. Issue detail: the failing rule, the WCAG success criterion, the element and the markup at fault.
3. Ignoring an issue, with the required written reason that becomes your evidence trail.
4. The block editor sidebar, which re-scans the post each time you save.
5. The generated accessibility statement page.

== 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.
