Title: reala11y – Accessibility Checker & Auto-Fix: WCAG 2.2 Scanner, AI Alt Text, ADA & EAA Audit Author: wkh0000 Published: June 18, 2026 Last modified: September 4, 2026 --- Search plugins ![](https://ps.w.org/reala11y/assets/banner-772x250.png?rev=3577133) ![](https://ps.w.org/reala11y/assets/icon-256x256.png?rev=3577133) # reala11y – Accessibility Checker & Auto-Fix: WCAG 2.2 Scanner, AI Alt Text, ADA & EAA Audit By [wkh0000](https://profiles.wordpress.org/wkh0000/) [Download](https://downloads.wordpress.org/plugin/reala11y.1.10.0.zip) * [Details](https://twd.wordpress.org/plugins/reala11y/#description) * [Reviews](https://twd.wordpress.org/plugins/reala11y/#reviews) * [Installation](https://twd.wordpress.org/plugins/reala11y/#installation) * [Development](https://twd.wordpress.org/plugins/reala11y/#developers) [Support](https://wordpress.org/support/plugin/reala11y/) ## Description reala11y is a WordPress accessibility plugin that audits your posts and pages for WCAG issues and fixes them at the code level — a skip link, a visible focus outline, minimum target size, a main landmark, rel=”noopener” on new-tab links, duplicate- id and positive-tabindex cleanup, restored pinch-zoom, and redundant image and tag- cloud title removal. Unlike accessibility overlay widgets, reala11y modifies the underlying HTML, so screen readers and keyboard users encounter the corrected page. It helps your site move toward WCAG 2.2 AA conformance and helps you prepare documentation for ADA and European Accessibility Act (EAA) compliance efforts — honestly, without pretending any tool can do the whole job. #### What reala11y does * **Scans posts, pages, and same-site URLs** against a 26-rule WCAG library, grouped by severity with the exact success criterion and code snippet for each finding. * **Builds a site-wide work list** — findings grouped by rule rather than by page, so one missing skip link in your theme reads as a single job affecting twelve pages, not twelve separate issues. Rules found on every page scanned are called out as likely coming from your theme or a template. * **Applies safe, automated fixes** at the code level (per-rule on/off, every change logged, one-click rollback). * **Exports findings as CSV** — one row per issue with the page it is on, ready to hand to a developer or track in a spreadsheet. * **Lets you mute rules you have judged** — muted rules leave the work list but stay in every scan and in the CSV export, listed separately. Triage, not denial. * **Checks content while you write** — a block-editor sidebar runs the same rules against the post you are editing. * **Inspects the live page** — an author-only inspector overlays findings on the actual front end. Visitors never see it, and logged-out visitors receive zero reala11y code. * **Suggests image alt text with your own AI key** (OpenAI, Anthropic, or Google Gemini) — you review every suggestion before it is applied. * **Tests colour contrast** — a built-in checker for any foreground/background pair against WCAG AA and AAA. * **Generates documentation** — a customizable accessibility statement, a VPAT starter, and a conformance report to document your remediation work. #### WCAG 2.0, 2.1 and 2.2 support The rule library spans success criteria introduced across WCAG 2.0 (alt text, form labels, language of page, colour contrast), WCAG 2.1, and WCAG 2.2 — including 2.5.8 Target Size, new at level AA in 2.2. The free plugin scans against the full, current WCAG 2.2 AA profile. reala11y Pro adds version-targeted scan profiles — WCAG 2.0 AA (the level referenced by Section 508) and WCAG 2.1 AA (referenced by EN 301 549, the technical standard behind the European Accessibility Act) — for teams that need to report against a specific version. #### Help with ADA, EAA and Section 508 compliance efforts Courts and regulators reference WCAG when they evaluate website accessibility. reala11y detects those WCAG issues, fixes the ones automation can fix safely, and generates the paperwork your compliance effort needs: an accessibility statement template, a Voluntary Product Accessibility Template (VPAT) starter for Section 508, a conformance report, and a CSV of findings for your developer or auditor. It reduces the volume of issues a human auditor must triage — it does not replace the auditor. #### What reala11y does NOT do * It does not guarantee WCAG, ADA, EAA, or Section 508 compliance. Automated tools detect approximately 30–40% of WCAG failures by criteria. Full conformance requires human review. * It is not an overlay widget. The Federal Trade Commission’s April 21, 2025 order against accessiBe affirmed that overlay claims of automatic WCAG conformance are not supportable. * It does not run your site’s JavaScript. reala11y checks the HTML your server sends, so anything a script adds after the page loads — a cookie banner, a slider, a modal, content in a single-page app — is not checked. If a page’s content is built in the browser, the scan says so on that page rather than reporting a low issue count as if it were good news. #### External services reala11y is self-contained and contacts third-party services only as described below, and only when the relevant feature is used. * WordPress.org — used for plugin update checks, as for any plugin hosted here. No personal data is sent beyond the standard update request. * AI providers — OpenAI, Anthropic, and Google Gemini (optional, bring-your-own- key). The AI authoring features (for example, alt-text suggestions) stay off until you enter your own API key for a provider and run a feature. When you run a feature, reala11y uses your key to send that provider the input you selected— for example, the URL of an image or a block of your post’s text — together with a short instruction prompt. The response is shown to you for review and is never applied automatically. reala11y does not proxy or resell AI usage; the provider bills you directly. Remove a provider’s key to disable it. - OpenAI — Terms: https://openai.com/policies/terms-of-use/ — Privacy: https:// openai.com/policies/privacy-policy/ - Anthropic — Terms: https://www.anthropic.com/legal/commercial-terms — Privacy: https://www.anthropic.com/legal/privacy - Google Gemini — Terms: https://ai.google.dev/gemini-api/terms — Privacy: https:// policies.google.com/privacy * Freemius — the licensing service for the optional, separately sold reala11y Pro add-on. The SDK ships in this plugin so the add-on can license itself, but it sends nothing anywhere unless you explicitly opt in on the one-time screen shown after activation — choosing “Skip” keeps everything local, permanently, and every feature of this free plugin works identically either way. If you do opt in, Freemius receives basic diagnostic data (site URL, WordPress/PHP versions, admin email, and this plugin’s activation state) to power update notices and, for Pro customers, license checks. - Freemius — Terms: https://freemius.com/terms/ — Privacy: https://freemius. com/privacy/ See our privacy policy at https://reala11y.com/legal/privacy. #### Source code reala11y is open source (GPLv2 or later). The admin interface is written in React and TypeScript and bundled with Vite. The human-readable source for the compiled files in build/admin/ ships with the plugin under admin/src/. To rebuild it, run“ npm install” and then “npm run build” in the plugin’s admin/ directory. #### Why reala11y * Code-level remediation, not an overlay widget. * A work list that answers “what should I fix first?” instead of drowning you in per-page findings. * WCAG 2.2 rules (including 2.5.8 Target Size and the focus criteria), with WCAG 2.0 / 2.1 scan profiles in Pro. * Bring-your-own AI key — no surprise quotas, no resold tokens. * Honest claims. We never tell you you’re “fully compliant.” #### Links * Website and documentation: https://reala11y.com * How reala11y compares to overlay widgets: https://reala11y.com/vs/accessibe and https://reala11y.com/vs/userway * Our own accessibility statement: https://reala11y.com/accessibility-statement ## Screenshots [⌊The site-wide work list — findings grouped by rule instead of page, worst severity first, with a per-rule page count, one-click mute, and CSV export. A rule found on every page is flagged as likely coming from your theme.⌉⌊The site-wide work list— findings grouped by rule instead of page, worst severity first, with a per-rule page count, one-click mute, and CSV export. A rule found on every page is flagged as likely coming from your theme.⌉[ The site-wide work list — findings grouped by rule instead of page, worst severity first, with a per-rule page count, one-click mute, and CSV export. A rule found on every page is flagged as likely coming from your theme. [⌊The dashboard — a plain-language overview of scans, outstanding issues, applied fixes, and AI spend (no single "compliance score").⌉⌊The dashboard — a plain-language overview of scans, outstanding issues, applied fixes, and AI spend (no single "compliance score").⌉[ The dashboard — a plain-language overview of scans, outstanding issues, applied fixes, and AI spend (no single “compliance score”). [⌊The Issues list — each WCAG finding grouped by severity, with its success criterion, the offending code snippet, and inline fixes you can apply or dismiss.⌉⌊The Issues list — each WCAG finding grouped by severity, with its success criterion, the offending code snippet, and inline fixes you can apply or dismiss.⌉[ The Issues list — each WCAG finding grouped by severity, with its success criterion, the offending code snippet, and inline fixes you can apply or dismiss. [⌊The Fixes screen — every applied fix is logged with a before/after view of the exact change, and reversible with one-click undo.⌉⌊The Fixes screen — every applied fix is logged with a before/after view of the exact change, and reversible with one-click undo.⌉[ The Fixes screen — every applied fix is logged with a before/after view of the exact change, and reversible with one-click undo. [⌊The block-editor sidebar — the same WCAG checks running against the post you are writing, inside the editor.⌉⌊The block-editor sidebar — the same WCAG checks running against the post you are writing, inside the editor.⌉[ The block-editor sidebar — the same WCAG checks running against the post you are writing, inside the editor. [⌊The front-end inspector — an author-only overlay that marks findings on the live page. Visitors never see it.⌉⌊The front-end inspector — an author-only overlay that marks findings on the live page. Visitors never see it.⌉[ The front-end inspector — an author-only overlay that marks findings on the live page. Visitors never see it. [⌊The colour-contrast tester — check any foreground/background pair against WCAG AA and AAA for normal and large text.⌉⌊The colour-contrast tester — check any foreground/ background pair against WCAG AA and AAA for normal and large text.⌉[ The colour-contrast tester — check any foreground/background pair against WCAG AA and AAA for normal and large text. [⌊AI alt text — images missing alt text listed with an AI suggestion field; bring your own OpenAI, Anthropic, or Google Gemini key, and review every suggestion before it is applied.⌉⌊AI alt text — images missing alt text listed with an AI suggestion field; bring your own OpenAI, Anthropic, or Google Gemini key, and review every suggestion before it is applied.⌉[ AI alt text — images missing alt text listed with an AI suggestion field; bring your own OpenAI, Anthropic, or Google Gemini key, and review every suggestion before it is applied. [⌊AI tools — provider settings with encrypted key storage, a masked key display, and daily spend caps you control.⌉⌊AI tools — provider settings with encrypted key storage, a masked key display, and daily spend caps you control.⌉[ AI tools — provider settings with encrypted key storage, a masked key display, and daily spend caps you control. [⌊The accessibility statement and reports — generate a customizable statement template, VPAT starter, and conformance report to document your remediation work.⌉⌊The accessibility statement and reports — generate a customizable statement template, VPAT starter, and conformance report to document your remediation work.⌉[ The accessibility statement and reports — generate a customizable statement template, VPAT starter, and conformance report to document your remediation work. ## Blocks This plugin provides 1 block. * Accessibility statement Embeds your generated accessibility statement (a reviewable template). ## Installation 1. Upload the plugin to /wp-content/plugins/reala11y/ or install via the Plugins screen. 2. Activate “reala11y” from the Plugins screen. 3. Go to “reala11y” in the WordPress admin to configure. ## FAQ ### Does this make my site WCAG compliant? No tool can. reala11y identifies common WCAG issues and remediates a defined subset at the code level. Full conformance requires manual review and user testing. ### Do I need an API key for AI features? Yes — bring your own OpenAI, Anthropic, or Google Gemini key. The AI authoring features then work in this free version at no extra charge from us; your provider bills you directly for what you use. reala11y never resells or proxies AI usage. ### How does this compare to accessibility overlay widgets? Overlay widgets (e.g., accessiBe, UserWay) inject a floating JavaScript layer that does not modify the underlying HTML. Screen readers continue to see the original, unfixed page. The FTC fined accessiBe $1,000,000 on April 21, 2025 for claiming automated WCAG compliance. reala11y instead applies fixes to the actual HTML that browsers, screen readers, and crawlers see. ### What WCAG version do you cover? The free plugin scans against the full WCAG 2.2 AA profile — the current W3C Recommendation( October 5, 2023). Its 26-rule library spans success criteria introduced across WCAG 2.0, 2.1, and 2.2. reala11y Pro adds version-targeted scan profiles for WCAG 2.0 AA (the level referenced by Section 508) and WCAG 2.1 AA (referenced by EN 301 549, the standard behind the European Accessibility Act), for teams that need to report against a specific version. ### Does reala11y help with the European Accessibility Act (EAA)? The EAA became enforceable on June 28, 2025, and its technical standard (EN 301 549) references WCAG 2.1 AA. reala11y detects WCAG issues on your pages, applies safe code-level fixes, and generates the documentation an EAA compliance effort typically needs — an accessibility statement template and a conformance report. Like all automated tools it detects a portion of WCAG issues; pair it with manual review, and consult a qualified accessibility professional for high-risk sites. ### Is reala11y an alternative to accessiBe or UserWay? If you are looking for an accessiBe or UserWay alternative that fixes the underlying HTML instead of layering a JavaScript widget on top, reala11y is built for that. Overlay widgets leave the original page unchanged for screen readers; reala11y edits the actual code. As context, the FTC fined accessiBe $1,000,000 on April 21, 2025 over automated WCAG compliance claims. ### Can it generate alt text for my images? Yes. The scanner flags images missing alt text (WCAG 1.1.1), and the bring-your- own-key AI tools can draft an alt-text suggestion using your own OpenAI, Anthropic, or Google Gemini key. Every suggestion is shown for your review and is never applied automatically. ### Will the automatic fixes break my site? Nothing changes without your say-so. Out of the box reala11y only scans: no fix is applied automatically, because the “auto-apply safe fixes” setting is off by default. When you do apply one, reala11y makes only Tier 1 (“safe”) changes to your content— attribute-level edits that leave your text and markup structure alone. Examples: adding rel=”noopener” to a link that opens in a new tab, removing a duplicate id, or stripping a redundant title attribute from an image. (Removing an image’s title attribute also removes the tooltip some browsers show on hover. That is the intent: the tooltip usually repeated the alt text and was never available to keyboard or touch users.) The optional render-time fixes are deliberately different: a visible focus outline or a larger touch target is meant to change how the page looks. Each one is off until you switch it on. Every applied fix is logged, and one-click undo restores the exact content from before it ran. A single Safe Mode switch turns every fix off at once. ### Does reala11y slow down my site for visitors? A visitor’s page never waits for a scan. Scans are queued and carried out in the background by WP-Cron: the worker fetches the page over a separate request, much as a browser would, then analyses the HTML that came back. (As with all WP-Cron work on a standard install, that background request can be set off by site traffic, but it runs on its own and does not hold up the page your visitor sees.) The optional render-time fixes (skip link, visible focus outline, minimum target size, main landmark, restored pinch-zoom) stay off until you enable them individually. Once enabled they add a small amount of markup or CSS to the page, and no external requests. ### Does it work with my theme, or with Elementor, Divi, or Beaver Builder? reala11y scans the HTML your site actually sends to the browser, so it sees whatever your theme or page builder rendered on the server, not just the raw post content. Render-time fixes apply to that same output. What it does not see is anything added afterwards by JavaScript in the visitor’s browser. Most Elementor, Divi and Beaver Builder content is rendered on the server and is checked normally, but a widget that builds itself in the browser is not. When a page looks like its content is assembled by JavaScript, the scan flags that page so a low issue count is not mistaken for a clean one. ### How do I undo a fix? Open the Fixes screen. Each applied fix is listed with a timestamp, and Undo restores the exact content from before it ran. If you would rather switch everything off at once without reverting each change, turn on Safe Mode. ### Is my content sent anywhere? Scanning and fixing happen entirely on your own server. The only outbound requests are the standard WordPress.org update check and — if, and only if, you add your own AI provider key and run an AI feature — the specific text or image you selected, sent to that provider under your own key. See “External services” above. ### Does reala11y work on WordPress Multisite? The free plugin can be activated on each site in a network and works per site. Managing many sites from the network admin — one roll-up dashboard, cross-site bulk scans, white-label reports — is the separate reala11y Pro add-on. ### A scan is stuck on “queued” and never finishes reala11y queues scans through WP-Cron, and the worker then fetches the page over an HTTP request back to your own site (a “loopback” request). If scans never leave“ queued”, the two usual causes are: 1. WP-Cron is turned off (DISABLE_WP_CRON is set to true in wp-config.php) and no real system cron job replaces it. 2. The server blocks loopback requests to itself, which some hosts and local development environments do by default. Ask your host to allow loopback requests, or run wp-cron.php from a system cron job. ### The scan finished, but I do not see the fixes on the front end The render-time fixes — skip link, focus outline, minimum target size, main landmark, restored pinch-zoom — are opt-in. Enable the ones you want on the Fixes screen, and check that Safe Mode is off, since Safe Mode disables every fix at once. ### Why does the dashboard not show a compliance score? Because a single score would be misleading. Automated tools detect roughly 30–40% of WCAG failures by criteria; the rest need human judgement. reala11y shows what it found, what needs review, and what passed, so you can act on real issues rather than chase a number. ## Reviews There are no reviews for this plugin. ## Contributors & Developers “reala11y – Accessibility Checker & Auto-Fix: WCAG 2.2 Scanner, AI Alt Text, ADA& EAA Audit” is open source software. The following people have contributed to this plugin. Contributors * [ wkh0000 ](https://profiles.wordpress.org/wkh0000/) [Translate “reala11y – Accessibility Checker & Auto-Fix: WCAG 2.2 Scanner, AI Alt Text, ADA & EAA Audit” into your language.](https://translate.wordpress.org/projects/wp-plugins/reala11y) ### Interested in development? [Browse the code](https://plugins.trac.wordpress.org/browser/reala11y/), check out the [SVN repository](https://plugins.svn.wordpress.org/reala11y/), or subscribe to the [development log](https://plugins.trac.wordpress.org/log/reala11y/) by [RSS](https://plugins.trac.wordpress.org/log/reala11y/?limit=100&mode=stop_on_copy&format=rss). ## Changelog #### 1.10.0 * **New check: several links that read the same but go to different places.** This is the pattern a blog archive creates by default — a row of posts each ending in the same “Read the full review” or “Continue reading”. Someone using a screen reader often navigates by pulling up a list of the links on a page, and there they see the same words repeated with no way to tell which is which. * It only reports links that nothing nearby identifies. If each link sits beside a distinct post title pointing to the same post — which is how most themes build an archive — the surrounding card already says where it goes, and the check stays quiet. Links repeated to the _same_ destination are never reported either, since that is allowed and is not a naming problem. * Generic wording such as “read more” is still reported by the existing link-text check rather than by both, so one line of markup is not flagged twice. * The scanner now ships 26 checks in total; a WCAG 2.2 scan runs 25 of them. #### 1.9.0 * **New check: low contrast between theme colours.** Low contrast is the most common accessibility problem on the web — the WebAIM Million 2026 study found it on 83.9% of home pages, more than any other issue — and until now reala11y could only spot it when both colours were set directly on an element, which is rare. It now also catches the case you are most likely to create: choosing a text colour and a background colour from your theme’s palette in the editor that are too close together. It reads the actual colour values your theme publishes in the page, so it knows the real ratio rather than guessing. * The new check stays quiet when it cannot be sure. Colours it cannot read exactly— such as ones built with `color-mix()` — are skipped rather than guessed at, and if a section’s background cannot be determined the text inside it is left alone. A warning you cannot reproduce is worse than no warning. * Fixed: text sized at exactly 18pt was measured against the stricter small-text contrast requirement instead of the large-text one, so it could be reported as failing when it actually passed. * The scanner now ships 25 checks in total; a WCAG 2.2 scan runs 24 of them (WCAG 2.2 removed the duplicate-ID criterion). #### 1.8.1 * **Fixed: uninstalling reala11y now removes everything it created.** Six settings stayed in your database after the plugin was deleted, and one scheduled task kept being triggered by WordPress on a site where reala11y no longer existed. Nothing was harmed by it, but a plugin you have removed should leave nothing behind. Database tables were already removed correctly. If you had previously uninstalled reala11y, installing and removing this version will clear the leftovers. * Includes everything from 1.8.0, which was tagged but never published here. #### 1.8.0 * **New: reala11y now tells you when it could not see a page.** reala11y checks the HTML your server sends and does not run your site’s JavaScript, so a page that is assembled in the browser looks almost empty to it — and an almost empty page produces almost no findings. On the same page, a server-rendered version reported 5 issues and a browser-rendered one reported 1. When a page looks like its content is built by JavaScript, the Scans screen now says so and shows how little it could actually read, so a low issue count is never mistaken for a clean result. * The notice is deliberately hard to trigger. An ordinary WordPress page contains plenty of server-rendered markup and also loads plenty of scripts, so scripts alone never cause it; the page has to be genuinely empty of content. Checked against real theme output — home page, posts, search results and a 404 — none of which are flagged. * Documentation is clearer about the same limit in the ordinary case: anything a script adds after the page loads — a cookie banner, a slider, a modal, a single- page app — is not checked, even on pages that are otherwise rendered normally. #### 1.7.0 * **New: see what changed since your last scan.** Open the issues for a scan and reala11y now tells you what moved since the previous scan of that same page — how many issues are newly reported, how many are no longer reported, and how many are still there, with the exact elements behind each. An issue count on its own has no direction: forty issues today looks the same whether last week was forty or four. This is what catches a theme or plugin update quietly bringing back something you had already fixed. * Issues that stopped being reported are described as “no longer reported” rather than “fixed”. reala11y cannot tell whether you repaired an element or simply removed it from the page, so it says what it knows and leaves the judgement to you. * Issues you have dismissed are left out of the comparison, so something you have already reviewed and set aside is not announced as new every time the page is scanned. #### 1.6.1 * **Important fix — backslashes were being deleted from your posts.** Applying any fix to a post removed every backslash in it, so a Windows path like `C:\Users\ alice` became `C:Usersalice`, a regex in a code block like `\d+` became `d+`, and LaTeX or escaped quotes lost characters too. Undo did not rescue it: undo saved through the same faulty step, so it deleted the backslashes a second time instead of putting them back. Both paths are fixed, and undo now restores the original content exactly. If a post of yours contains code, file paths or maths and a fix has been applied to it, compare it with the before/after on the Fixes screen. * Alt text saved from the Alt text screen had the same problem and lost backslashes on save. Fixed. #### 1.6.0 * **Important fix — a fix could delete text from your posts.** The “Remove positive tabindex” fix searched your whole page instead of only inside HTML tags, so a sentence that merely _mentioned_ tabindex=”5″ had that text deleted from the paragraph. Posts about accessibility were the most likely to be affected. The fix now only ever touches real attributes, and prose is left alone. If you applied safe fixes to a post that discusses HTML attributes, check it against the before/ after diff on the Fixes screen; every change is still reversible with Undo. * Fewer false positives. reala11y no longer reports problems inside markup the browser never displays: `