=== Siftra – Free WCAG & ADA Accessibility Checker ===
Contributors: a11ycheck
Tags: accessibility, wcag, ada, section 508, accessibility statement, accessibility checker, eaa, wcag 2.2, alt text, accessibility audit
Requires at least: 5.8
Tested up to: 7.1
Requires PHP: 7.4
Stable tag: 0.2.0
License: GPLv2 or later
License URI: https://www.gnu.org/licenses/gpl-2.0.html

Free WCAG and ADA accessibility checker: nine checks, the exact element for each finding, and a statement you can publish. No account, no overlay.

== Description ==

Siftra runs a free accessibility scan of your published pages and tells you what to change, element by element.

If you want to know why that is worth ten minutes, here is the state of the web. The WebAIM Million analyses one million home pages every year. In the 2026 edition, **53.1%** of them had images with no alt text, **51%** had form fields with no label, **46.3%** had empty links, **30.6%** had empty buttons, and **13.5%** declared no page language. Those five failure types are decided from markup alone, and they are four of the nine checks in this plugin.

The sixth most common failure, low contrast text, was found on **83.9%** of pages. It needs the rendered page, so no server-side scanner can decide it, including this one. Siftra says so in the report rather than quietly leaving it out.

Nothing is added to your front end: no overlay, no widget, no script. There is no account to create, and nothing leaves your database.

And it ends with something you can use: an accessibility statement, with the known limitations from the last scan already filled in. That is the document you hand to a client.

**What it does**

* Scans up to 50 of your published pages by default, five at a time, in the background. You can raise the limit to 300 before you start.
* Reports nine kinds of problem that automated testing can actually decide from the markup: missing image descriptions (alt text), unlabeled form fields, broken heading order, "click here" links, missing page language, empty buttons and links, tables without header cells, untitled iframes, and media that plays by itself.
* Shows the page, the element, the WCAG criterion, and the fix for every finding. No vague "12 issues found".
* Includes a free, unlimited accessibility statement generator. Where the European Accessibility Act (EAA) applies, it asks for a published statement and a feedback channel.

**What it does not do**

* No overlay widget, and no automatic rewriting of your pages. The plugin reports what it finds on each element; you decide what to change.
* No "one-click fix" and no "AI makes your site compliant". Automated testing cannot make that promise, and this plugin does not make it.
* No account, no email, no usage data, no third-party requests.
* No claim of compliance. A clean scan means the nine automated checks passed. It does not mean your site is accessible, and the plugin says so in the report and in every generated statement.

**Who it is for**

Site owners and small agencies who want to know what is wrong before they pay anyone for an audit. The aim is to stop guessing, not to wait for a complaint.

**If you look after sites for other people**

Two things are built for that job rather than for a single site owner. On the **Client report** tab you enter your own name, email and website once. From then on:

* The report you copy out is a plain-text document addressed to your own client, ending with your name on it, not this plugin's.
* The accessibility statement says the site is maintained by you on behalf of the client, with your contact details in it.
* The one line that mentions Siftra is a checkbox. Switch it off and the documents carry your brand only.

The report is deliberately plain text: it survives being pasted into an email, a ticket or a document, and every finding names the page and the fix, so your client can see what they are paying for. The exact element behind each finding stays in your dashboard, which is where the work gets done.

In the EU, the European Accessibility Act has applied since June 2025. In the US, Section 508 covers federal agencies, and Seyfarth Shaw counted 3,117 website accessibility lawsuits in federal court in 2025, up 27% from 2024.

Four of the six problems cited most often in those lawsuits are covered by the nine checks: missing alt text, unlabeled form fields, empty links and buttons, and missing page language.

**How to read your first number**

WebAIM found that 20.5% of home pages had five or fewer detectable errors and 30.4% had ten or fewer. So a first scan that comes back with forty findings is not a broken plugin: on a page with sixty images and a contact form, that is the normal range, and every site owner sees roughly the same distribution.

The useful signal is not the total. It is whether the same three or four types of problem keep appearing on every page. That pattern means one theme or template change fixes everything at once, which is a different job from chasing individual images.

**About**

I am one developer, not a company. Siftra exists because I wanted to know what was wrong with a page before paying someone for an audit. Every tool I tried either put a widget on the front end, or told me the site was compliant when it plainly was not.

I am not an accessibility expert, and the plugin does not pretend to be one. The nine checks are the ones that can be decided from markup without guessing; anything that needs a browser or a human is listed as a limit instead of being guessed at. If you hit a false positive, report it in the support forum and I will fix it. That is the whole roadmap for this version.

Source is GPLv2. No tracking, no upsell, no account.

== Installation ==

1. Upload the plugin folder to `/wp-content/plugins/`, or install it from Plugins > Add New.
2. Activate the plugin.
3. Go to **Siftra** in the admin menu and press **Scan my site**.
4. You can close the tab. The scan runs in the background and the results are waiting when you come back.

== Frequently Asked Questions ==

= How long does a scan take? =

Five pages per request. On a normal shared host that is a few seconds per batch, so fifty pages usually take under two minutes. A slow or busy host will take longer. Closing the browser does not stop the scan.

= Why did every page fail to load? =

Some hosts block requests from the server to its own address (loopback), and so do some security plugins. The plugin detects this and says so. Ask your host to allow loopback requests, or run the scan on a staging copy on the same server.

A scan that read nothing is never reported as a clean site. If no page could be fetched, the plugin says the scan failed instead of showing a green result, and it warns you before generating a statement from that scan.

= Does this make my site compliant? =

No. Automated testing only finds a share of accessibility problems. Use the findings as a to-do list, then test your main pages with a keyboard and a screen reader.

= Will it slow my site down? =

No scripts or styles are added to your front end, so visitors load exactly what they loaded before. Scanning happens in the admin, in background batches of five pages, so no single request runs long enough to stall your site.

= Where is my data stored? =

Two tables in your own database. Nothing is sent anywhere. Deleting the plugin removes both tables.

= Can I use the statement generator for a client site? =

Yes, it is free and unlimited, and there is no agency tier to buy. Put your own details on the Client report tab and both the report and the statement will speak for you rather than for the site owner.

= What can this plugin not find? =

Four limits worth knowing:

* Contrast, keyboard order, and how a screen reader actually announces the page. These need a human or a real browser. No server-side scanner can decide them.
* Elements hidden only by an external stylesheet. The plugin reads inline `style` attributes and `hidden`, but it does not fetch your theme's CSS files, so something hidden only in a `.css` file may still be reported.
* Anything rendered by JavaScript. The plugin reads the HTML your server sends.
* Pages larger than 3 MB, which are skipped and counted separately.

= Why does my site show almost no problems? =

Two usual reasons. Either the site really is clean in markup, or its content is built by JavaScript. The plugin only sees the HTML the server returns: a page that sends 40 KB of shell markup and renders itself in the browser has almost nothing for a markup scanner to read. On such a site, treat a low number as "not measured", not as "clean".

== Screenshots ==

1. The scan summary: pages checked, findings that need fixing, findings worth reviewing, and pages affected.
2. Findings are grouped by type, each group tagged with the WCAG criterion it breaks.
3. Open a group and every instance is listed with the page, the exact element, and why it fails.
4. The accessibility statement generator, with the known limitations filled in from your last scan.

== Upgrade Notice ==

= 0.2.0 =
Adds a Client report tab: enter your own name and contact once, and both the report and the statement go out under your brand. Existing scans and settings are untouched.

= 0.1.0 =
First public version.

== Changelog ==

= 0.2.0 =
* New Client report tab: a plain-text accessibility report you can send to a client, naming the pages and the elements behind each finding.
* New branding fields (name, email, website). The report and the statement now name the maintainer instead of the site owner.
* The "Created with Siftra" credit line can be switched off, so an agency can hand over documents under its own brand.
* A scan that could not read a single page no longer produces a report or a statement that reads like a clean result. Both now say plainly that nothing was checked, so nobody sends out a "no problems" document for a site that was never read.
* Nothing changed in the scanner, the database or the front end.

= 0.1.0 =
* First version. Nine automated checks, background batching, per-element findings, free statement generator.
