| 开发者 | lalokupfer |
|---|---|
| 更新时间 | 2026年10月3日 04:26 |
| PHP版本: | 7.4 及以上 |
| WordPress版本: | 7.1 |
| 版权: | GPLv2 or later |
| 版权网址: | 版权信息 |
[a11ylogbook_barrier_form] places it on any other page.
Visitor accessibility toolbar
A small button lets each visitor choose larger text, high contrast, underlined links, readable text spacing, paused animations, a keyboard focus highlight and a reading guide. Choices are kept in that visitor's own browser; no cookies are set. Link to #a11y-preferences from any menu to open it. The toolbar changes how the site looks for one visitor; it does not make a site accessible on its own, and it says so.
Privacy
This plugin does not connect to any external service. It makes no outbound requests of any kind — no telemetry, no analytics, no fonts or scripts from a CDN. It stores no IP addresses and no browser details. The only visitor data it keeps is what a visitor chooses to write in the barrier report form; an e-mail address given there is e-mailed to you by your own site and not stored. Suggested wording for your privacy policy is added under Settings → Privacy.
No plugin can do that, and you should be wary of any that says it does. Automated checks find only part of the barriers people meet (commonly quoted at 30–40%). This plugin finds what can be found automatically, fixes a set of problems safely, and keeps a dated record of the testing and remediation you do — which is what you need to show your work. Manual testing and user feedback cover the rest.
It is a WCAG 2.2 checker. WCAG 2.1 AA is the standard US courts, settlements and the ADA Title II rule refer to, and WCAG 2.2 includes it, so the scan checks the automatable parts of what an ADA review looks at. It cannot certify anything, and the report says so.
No. WCAG (the Web Content Accessibility Guidelines) is a standard published by the W3C. Vouchlog is an independent plugin that checks pages against that standard; it is not affiliated with or endorsed by the W3C.
Overlays run JavaScript over the page and are widely criticised for it. The fixes here change the HTML your server sends, are each off until you enable them, and are logged. The visitor toolbar only offers personal display preferences and is labelled as such.
That an entry has not been changed since it was written: each entry's hash covers the entry before it, so an edit breaks the chain from that point. Someone with direct database access could rebuild the whole chain; keeping a downloaded copy or a printed report outside the site is what makes that detectable too.
Yes. The contrast checker tests any two colors, and the scanner measures the contrast of the visible text on each page against its real background, reports the ratio, and suggests the nearest color that passes. Text over a background image or gradient, or text that is partly transparent, is skipped rather than guessed — check those by eye with the contrast checker.
Yes. Images with no alt attribute are reported with the page and the element. The "media library alt text" fix fills in alt text you already saved in the media library; it never invents alt text.
Some failures only happen on phones: pages that scroll sideways (1.4.10 Reflow), tap targets that are too small (2.5.8 Target Size) and pinch zoom switched off (1.4.4). Each page is checked at 1280 px and at 360 px (the phone width can be switched off in Settings).
No. The scan runs in your own browser while you watch; your visitors are not affected. With fixes switched on, the page is processed once as it is sent, using WordPress core's HTML processor.
Yes. The fixes are part of the HTML, so a page cache stores the fixed page. Clear the cache after switching fixes on or off. Scans are run while you are logged in, which most caches skip.
The scan opens each page in a frame on your own site. If a page refuses that — it sends X-Frame-Options: DENY or a Content-Security-Policy with frame-ancestors 'none' (some security plugins do), or it redirects to another domain — the scan tells you which header refused it and offers to check those pages in a separate window instead. Pages checked that way are recorded as such in the evidence log. If you skip them, the scan says so for each page and carries on.
The EU rules expect an accessibility statement with a way for people to report problems. The statement page this plugin creates includes your contact details, the known issues, the date of the last review, and a form for reporting a barrier — each report is kept, dated, in the evidence log.
No. There is no external service, account or API key. Scans run in your browser and results are stored in your site's database.
Deleting it removes its database tables and its settings, including the evidence log — download the log first if you want to keep it. Deactivating keeps everything. The statement page, if you created one, stays, because it is your content.
[a11ylogbook_barrier_form] shortcode). Each report is dated in the evidence log and e-mailed to you; no IP address or browser details are kept.