| 开发者 | wowstudioplugin |
|---|---|
| 更新时间 | 2026年10月12日 23:08 |
| PHP版本: | 8.1 及以上 |
| WordPress版本: | 7.1 |
| 版权: | GPLv2 or later |
| 版权网址: | 版权信息 |
/wp-content/plugins/wowstudio-accessibility-remediation, or install it through Plugins → Add New.No, and be careful of any tool that says it will. Accessibility conformance is a property of your site and your organisation's practices, not something a plugin can confer. This plugin helps you find issues, fix them properly, document what you did, and notice when something regresses. The remaining work — manual testing, testing with disabled users, editorial judgement — is yours.
No. Overlays layer a script over your site at run time and are widely criticised by disabled users, and have drawn regulatory action. This plugin changes the underlying markup instead, and adds nothing to your front end for visitors.
Yes. Fixes are stored in a reversible override layer rather than being written over your content, and each one can be reverted.
No. Nothing here is generated, and nothing is sent anywhere. Where an answer depends on what your content means — what an image is for, what a link promises — the plugin says so and gives you the fastest way to write it yourself, rather than producing a plausible sentence and leaving you to notice it is wrong.
No. Everything in this plugin is free, including checking your whole site at once. There are no locked buttons and no upgrade prompts, and nothing is withheld until you pay.
There is a separate paid plugin, WOWStudio Accessibility Remediation Premium, which adds scheduled re-checking: it re-runs the same checks on a schedule and reports what changed since the last run. It is an add-on that attaches to this plugin rather than a different build of it, so installing it takes nothing away and not installing it leaves nothing locked. This plugin mentions it once, at the foot of its own dashboard, and says nothing about it once it is installed. The wsak_mention_add_on filter removes even that.
41 checks against WCAG 2.2 level A and AA. 36 of them read the rendered HTML on the server. The other five run in your browser, on the page as it was actually painted, because contrast, target size and computed text size are not knowable from markup alone. Every finding names the success criterion it came from and says whether a machine settled it or a person still has to look.
Three things. It proposes changes to your own code rather than layering anything over the top, so the fixes survive the plugin being removed. It makes no outbound requests at all — no account, no API, no telemetry, no AI — so nothing about your site leaves your server. And nothing is gated: every check, every severity and the whole-site scan are free, because withholding a finding means not telling somebody their site has a barrier, and the person who loses that trade is the disabled visitor.
Elementor is supported and was tested against a real page rather than its documentation — it keeps nothing in post_content, so the plugin asks the builder for the content instead. Divi and WP Bakery keep shortcodes in post_content and need nothing special. Oxygen, Beaver Builder, Avada and ACF are untested so far; the wsak_builder_content filter is the seam if you need to teach it one.
Nothing is added to your front end unless you switch on a site-wide fix, and then only the CSS or the small script that the fixes you enabled actually need. There is no widget, no toolbar and no third-party request on any page view. Scanning runs in the admin and, for whole-site runs, in the background through Action Scheduler, so it never blocks a page load for a visitor.
In WordPress's own alt text field on the media item. It therefore applies everywhere that image is used, works with every theme and plugin, and stays behind if you remove this plugin.
wsak_mention_add_on filter removes it entirely. Nothing in this plugin became locked, limited or worse: every check, every severity and the whole-site scan are still free, with no page limit.