reala11y – Accessibility Checker & Auto-Fix: WCAG 2.2 Scanner, AI Alt Text, ADA & EAA Audit
| 开发者 | wkh0000 |
|---|---|
| 更新时间 | 2026年9月4日 23:59 |
| 捐献地址: | 去捐款 |
| PHP版本: | 8.1 及以上 |
| WordPress版本: | 7.0 |
| 版权: | GPLv2 or later |
| 版权网址: | 版权信息 |
详情介绍:
- 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.
- 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.
- 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/
- 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."
- 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
安装:
- Upload the plugin to /wp-content/plugins/reala11y/ or install via the Plugins screen.
- Activate "reala11y" from the Plugins screen.
- Go to "reala11y" in the WordPress admin to configure.
屏幕截图:
常见问题:
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:
- WP-Cron is turned off (DISABLE_WP_CRON is set to true in wp-config.php) and no real system cron job replaces it.
- The server blocks loopback requests to itself, which some hosts and local development environments do by default.
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.
更新日志:
- 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.
- 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).
- 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.
- 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.
- 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.
- 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\alicebecameC:Usersalice, a regex in a code block like\d+becamed+, 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.
- 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:
<template>blocks (used by block themes, page builders and many JavaScript libraries), elements with thehiddenattribute, and elements hidden inline withdisplay:noneorvisibility:hidden. One template alone could add four findings for images and links that were not on the page. - Content that is hidden visually but still read aloud — the standard
.screen-reader-textpattern,hidden="until-found", and anything insidearia-hidden— keeps being checked, because that content really does reach people. - New: reala11y now tells you when a check could not run. If a check fails on a particular page it is skipped so the rest of the scan still completes, but the Scans screen now says which check was skipped and that the list is incomplete. Previously a scan that ran 23 of 24 checks looked exactly like a clean one.
- New site-wide work list on the Site audit screen. Findings are grouped by rule rather than by page, so a single missing skip link in your theme reads as one job affecting twelve pages instead of twelve separate issues. Groups are ordered worst-severity first, then by how many pages they touch, and a rule found on every page scanned is called out as likely coming from your theme or a template rather than any one page's content.
- Export findings as CSV. One row per issue with the page it was found on, ready to hand to a developer or track in a spreadsheet. Values scraped from your pages are escaped so a post title beginning with "=" cannot run as a formula when the file is opened.
- Mute a rule you have already judged. Muted rules drop out of the work list but keep being found by every scan and keep appearing in the CSV export, listed separately with their own count. Muting is a triage tool: it does not fix anything and does not make a page more accessible.
- Accessibility fixes to reala11y's own admin screens, found by running our scanner and axe-core against ourselves. Our panel no longer adds a second "main" landmark inside WordPress's own; de-emphasised rows keep full text contrast instead of being faded below the 4.5:1 threshold; the mute control now meets the 24x24 target-size minimum; the applied-fix diff no longer skips a heading level; keyboard focus follows a rule when you mute or unmute it, and the change is announced to screen readers; and every screen now reflows to a 320px viewport without scrolling sideways.
- Fixes a bug in 1.4.0 that made every reala11y screen except the first one answer with "Sorry, you are not allowed to access this page" until you dismissed the one-time licensing screen. The plugin now starts in its skipped, send-nothing state, so Scans, Issues, Fixes, Site audit, Tools, AI tools, Alt text, Statement and Settings all keep working immediately after updating. Opting in is still offered, and still entirely optional.
- Adds the Freemius SDK as the licensing foundation for the optional reala11y Pro add-on. Nothing is sent anywhere unless you explicitly opt in on the one-time screen after updating — "Skip" keeps everything local, permanently, and every feature of the free plugin works identically either way. A new Add-ons screen lists what Pro adds.
- A small, dismissible note on reala11y's own screens (never elsewhere in your admin) may ask for a WordPress.org review after the plugin has completed at least ten scans over two weeks. One click dismisses it forever.
- Two new checks, 24 in total. ARIA validity: reala11y now flags roles that do not exist, abstract roles that were never meant to be used directly, ARIA attributes set to values outside their allowed range, roles missing a state they require, and
aria-hiddenplaced on the page body or wrapped around something a keyboard user can still focus. - Page-builder widgets. Accordions, tabs, toggles, and icon-only buttons built with Elementor, Divi, or Beaver Builder are flagged for review when the page's HTML carries no ARIA state or accessible name for them. These are review items, not errors: reala11y reads the HTML your server sends, and several page builders add the missing ARIA with JavaScript after the page loads. The check tells you where to look; it does not claim the control is broken.
- Expanded documentation: a much longer FAQ covering fix safety, performance, page-builder and theme compatibility, undoing a fix, Multisite, what data leaves your site, and the two usual causes of a scan stuck on "queued".
- Add a "Buy me a coffee" support link on the Plugins screen and the plugin page (optional donation; no data sent).
- Scan your whole site in one click. A new "Scan whole site" button queues a scan for every published post and page, and you can schedule recurring scans (daily or weekly) so new content keeps getting checked automatically.
- Fix your whole site in one click. A new "Fix whole site" button applies every safe, code-level fix across all your published content at once. Each change is logged and reversible with one-click undo, and Safe Mode pauses every fix instantly.
- Bulk alt-text from the Media Library. See every image missing alt text in one place, then review and apply descriptions — optionally drafted with your own AI key — without hunting through individual posts.
- Six new checks, 22 in total: iframe titles, data-table headers, video captions, empty headings, list structure, and adjacent links to the same destination.
- Applied fixes now clear themselves from your list: when a fix resolves an issue, that issue leaves the active list automatically. Plus broader inline-fix coverage and an accessibility pass over the admin screens.
- Fix issues inline, right where you see them. On a flagged issue (in the Issues list or the on-page checker) you can now type and apply the fix in one step: image alt text, descriptive text for vague links, accessible names for icon-only buttons and links, and form-field labels.
- Colour-contrast fixer: pick or auto-suggest an accessible text/background pair and apply it, with a live contrast ratio and WCAG AA pass/fail.
- Heading-level fixer: re-level a heading that skips a step, with an optional bring-your-own-key AI outline suggestion.
- New render-time theme-output fixes (off by default): a site-wide skip link, a visible keyboard-focus outline, a minimum target size, a main landmark, and restore-zoom. These inject real code (not an overlay) and are gated by Safe Mode; with the feature off, visitors get a byte-identical page.
- Every fix is reversible with one-click undo and is logged.
- Listing refresh: real admin screenshots, clearer and more discoverable readme copy, and visible project links. No functional code changes.
- First public release.
- Scanner: 16 WCAG 2.2 rules across posts, pages, and rendered theme output.
- Auto-fix engine: safe, reversible, code-level fixes with per-fix toggles, one-click undo, and a Safe Mode kill-switch.
- Inspect on page: an author-only annotated overlay on the live site (logged-in editors only; visitors never see it).
- Dismiss issues with a structured reason and reopen them later.
- Colour Contrast Tester in the new Tools screen.
- BYOK AI authoring suite: bring your own OpenAI, Anthropic, or Google Gemini key — you pay your provider directly, never us.
- Accessibility statement generator, VPAT starter, and compliance report.
- Encrypted API-key storage and a clean uninstall.
- Scanner: 12 WCAG 2.2 rules across posts, pages, and rendered theme output.
- Auto-fix engine: safe, reversible, code-level fixes with per-fix toggles and one-click undo.
- "Scan this post" button in the block-editor sidebar; scan any post or same-site URL from the Scans screen.
- BYOK AI authoring suite: bring your own OpenAI, Anthropic, or Google Gemini key — you pay your provider directly, never us.
- Accessibility statement generator, VPAT starter, and compliance report.
- Encrypted API-key storage and a clean uninstall.
- Initial scaffold.