Accessibility Plugins: Overlays, Auditors and Fixers
Accessibility plugins split into three categories, and one of them — the overlay widget promising one-click compliance — is rejected by most of the people it claims to help. Knowing why changes how you spend the budget.
Accessibility is a property of your theme, your content and your markup — not something a plugin can bolt on. That single fact sorts the category cleanly, because the three kinds of accessibility plugin relate to it very differently.
| Category | What it does | What it is worth |
|---|---|---|
| Overlay widget | Injects a toolbar and scripted "fixes" at page load | Widely criticised; does not fix the underlying markup |
| Auditor | Scans pages or posts and reports failures | Genuinely useful, within known limits |
| Remediation aid | Helps you fix specific things properly | The category that actually moves the needle |
Be clear about overlays
Overlay widgets are the products marketed as one-click compliance: a floating accessibility icon offering font resizing, contrast modes, a "screen reader profile" and similar toggles, plus scripts that attempt to patch missing labels and roles at runtime.
They are the most-advertised option and the most criticised. Disabled users and accessibility professionals have objected to them consistently and publicly, and the objections are specific rather than aesthetic:
- They duplicate tools people already have. Screen reader users bring their own software, configured to their preferences. A site-side "screen reader mode" is not something they asked for.
- They can interfere. Scripts that rewrite roles, labels and focus behaviour on the fly can make a page harder to operate with assistive technology, not easier.
- They patch symptoms. Guessing an accessible name from surrounding text is not the same as the developer supplying a correct one, and nothing in the underlying template is repaired.
- They have not prevented litigation. Accessibility complaints and lawsuits have been brought against sites that had an overlay installed. Buying one is not a shield.
None of that is legal advice, and this article does not offer any. It is a description of how the tools are regarded by the people who use assistive technology daily, which is the evidence that should carry the most weight when you are choosing.
The standards landscape, factually
The Web Content Accessibility Guidelines (WCAG) are the technical standard almost everything else points at. They define success criteria at three conformance levels — A, AA and AAA — with AA being the level commonly referenced in public sector rules, procurement requirements and settlement agreements.
Regional frameworks then reference WCAG rather than replacing it: Section 508 in United States federal procurement, EN 301 549 in Europe, and equivalent public-sector regulations elsewhere. The Americans with Disabilities Act is civil rights legislation rather than a technical specification, which is precisely why "ADA compliance plugin" is a marketing phrase and not a product category. Build to WCAG AA and take questions about legal exposure to a lawyer.
Auditors: useful, with a ceiling
A good auditing plugin runs accessibility checks against your pages, or inside the editor as authors write. Look for one that checks content at the point of creation — flagging a missing alt attribute while the author is placing the image — because that is where accessibility debt is cheapest to avoid.
Judge auditors on whether they explain the failure and the fix rather than emitting a rule code, whether they scan rendered pages rather than raw post content, and whether they can be run across the whole site rather than page by page. Accept the ceiling: automated checks cover the machine-checkable subset of WCAG. Meaningful alt text, sensible heading structure, logical focus order and comprehensible link text all require a human.
What real remediation involves
The work is unglamorous and mostly lives outside the plugins directory.
- Start with the theme. Keyboard-operable menus, a visible focus indicator, a skip link, correct landmarks and heading order. A theme that gets these wrong will undo everything else — see how to customise a WordPress theme and, for navigation specifically, building a WordPress menu.
- Fix contrast at the palette level, not with a toggle. Decide it once using how to choose a website colour palette.
- Set readable type. Size, line height and line length are accessibility decisions; choosing fonts for a website is where that starts.
- Restore focus styles if the theme removed them — a few rules added via custom CSS fixes one of the most common failures on the web.
- Train authors. Alt text, descriptive links, real headings instead of bold text, captions on video.
- Check on real devices, including at 200% zoom and on a small screen, which overlaps with the responsive design checklist.
Where to start on Monday
Unplug the mouse and try to complete your site's main task — read a page, use the menu, submit the contact form — with the keyboard alone. Then run an auditor across the site and fix everything it reports in the theme's templates. Then have someone who uses a screen reader test the two or three journeys that matter. That sequence costs less than most overlay subscriptions and produces a site that is actually usable, which is the only outcome worth buying.
Frequently asked
- No plugin can make that guarantee, and overlays in particular are widely criticised by disabled users and accessibility practitioners for interfering with the assistive technology people already use. Sites running overlays have still been the subject of accessibility complaints and lawsuits.
- WCAG is the technical standard nearly every accessibility regulation and procurement rule points at, with level AA as the usual target. Building to WCAG AA is the durable answer regardless of which jurisdiction's rules apply to you; for anything about legal obligation, ask a qualified lawyer.
- Automated tools reliably catch machine-checkable failures like missing alt attributes, empty links, low contrast values and missing form labels. They cannot judge whether alt text is meaningful, whether focus order makes sense or whether a custom widget is operable, which is why manual testing is not optional.