WordPress Accessibility Overlays vs. Built-In Compliance: Why Plugins Alone Will Not Make Your Site WCAG Compliant

Accessibility overlay tools are currently one of the most actively marketed products in the web industry. If you have received an email warning that your website may be out of ADA compliance and offering an immediate fix via a single script installation, you have seen this marketing in action.

The tools being sold vary in name: accessiBe, UserWay, AudioEye, EqualWeb, and many others. Their marketing claims vary in specificity but share a common promise: install our widget, achieve compliance, eliminate legal risk.

The accessibility research community has spent several years evaluating these claims. The findings are consistent and worth understanding before your organization spends money on an overlay tool or, more importantly, before you represent your site as compliant because you installed one.

This post covers what accessibility overlays are, what independent testing shows about their actual performance, the specific limitation they cannot overcome regardless of quality, and what genuine built-in accessibility looks like for WordPress sites. We are not selling a competing overlay tool. We are making a case for the only approach that actually works.

What Accessibility Overlays Are

Accessibility overlays are JavaScript widgets that load on top of an existing website and attempt to automatically detect and fix accessibility issues, or offer users a control panel where they can adjust display settings (larger text, higher contrast, simplified layout, etc.).

The detection-and-fix category attempts to automatically repair code-level accessibility failures using AI or scripted rules. Overlay companies claim their tools can fix missing alt text, improve keyboard navigation, enhance color contrast, and address other WCAG criteria automatically, without changing the underlying website code.

The user control panel category gives visitors a toolbar with settings they can adjust themselves: text size, cursor size, color mode, animation reduction. These tools do not fix underlying accessibility failures; they give individual users options to modify their experience.

Many overlay tools offer both approaches combined: automatic fixes running in the background plus a user-facing control panel.

What Independent Research Has Found

The most significant body of evidence against overlay effectiveness comes from disability rights organizations, individual accessibility researchers, and large-scale studies of overlay performance.

The Overlay Fact Sheet, a public document signed by over 700 accessibility professionals, accessibility researchers, and people with disabilities, states that overlay tools do not provide accessibility compliance and often introduce new barriers for users of assistive technology. The signatories include some of the most respected voices in web accessibility worldwide.

WebAIM Million, an annual large-scale study of web accessibility, has consistently found that websites using overlay tools do not demonstrate better accessibility outcomes than comparable sites without them. In some analyses, sites with overlays showed slightly worse automated accessibility performance than sites without them.

Automated testing limitations. Overlay vendors often demonstrate their effectiveness by showing before-and-after automated accessibility scans with higher scores after the overlay is installed. These demonstrations reveal a fundamental misunderstanding: automated scanning catches only 30 to 40 percent of WCAG failures. An overlay that improves automated scores by addressing detectable issues while leaving the 60 to 70 percent of issues that require manual testing is not providing meaningful compliance. It is optimizing for a test while leaving the actual barriers in place.

The Fundamental Problem: What Overlays Cannot Fix

The most important limitation of overlay tools is not about how well they are engineered. It is structural. There are categories of accessibility issues that cannot be fixed by a JavaScript layer running on top of a website without touching its underlying code.

Keyboard navigation failures in custom interactive components. If your website has a custom dropdown menu, accordion, or modal dialog that is not keyboard accessible, an overlay cannot fix it. Keyboard accessibility requires changes to how event listeners are written in the JavaScript that powers those components. No external script can rewrite another script’s event handling.

Complex focus management. When a user opens a dialog box, focus should move into the dialog. When they close it, focus should return to the element that opened it. An overlay tool can monitor the DOM, but it cannot reliably intercept every focus event in a complex, dynamically rendered application and redirect it correctly. Focus management failures are among the most commonly documented issues with overlay tools.

Screen reader interaction for complex components. ARIA (Accessible Rich Internet Applications) implementation in custom components requires correct role, state, and property attributes in the HTML itself. An overlay that injects ARIA attributes into DOM elements it detects as interactive frequently gets this wrong, producing ARIA implementations that confuse screen readers more than the original unmarked elements did.

Accurate alt text for images. Some overlay tools claim to use AI to automatically generate alt text for images missing the attribute. AI-generated alt text is frequently inaccurate, particularly for complex images, charts, infographics, headshots, and images with text. Wrong alt text is in some ways worse than missing alt text: it gives a screen reader user a false description of what they are looking at.

PDF accessibility. Your PDF documents are not part of your website’s DOM. An overlay widget cannot make inaccessible PDFs accessible.

Video captions. Overlay tools cannot add captions to uncaptioned videos. This requires actual caption files associated with the video.

Logic-level WCAG criteria. Many WCAG criteria address design and content decisions that no automated tool can evaluate or remediate. Does the page structure make logical sense? Do the headings convey accurate hierarchy? Is the content written in plain language? Does the link text describe the destination? These require human judgment and cannot be automated.

What Real Accessibility Looks Like in WordPress

Built-in accessibility, sometimes called remediation or native accessibility, means that the website’s code, content, and design are built to be accessible from the start rather than having accessibility patched on top after the fact.

For WordPress specifically, this means:

Theme-level accessibility. The WordPress theme (the code that controls layout, typography, and visual design) must produce semantically correct HTML with proper landmark regions, heading hierarchy, and keyboard navigable navigation. ArcStone uses Kadence as a base theme framework, with custom modifications that address Kadence’s known accessibility gaps. Every theme customization is tested for accessibility impact.

Accessible block patterns and components. WordPress’s block editor is used to build page templates and reusable content patterns. Each block pattern must include correct ARIA implementation for interactive elements, visible focus indicators, sufficient color contrast, and semantic HTML structure. We audit these patterns and maintain them across WordPress core and block editor updates.

Accessible form implementation. Gravity Forms, our preferred form plugin, supports accessible form markup but requires correct configuration. Every form must have associated labels for each input, descriptive error messages, ARIA descriptions for complex fields, and submit buttons with meaningful text.

Content-level accessibility. Alt text for images, captions for videos, transcripts for audio, accessible heading structure, plain language, and meaningful link text are content decisions that require training and guidelines for the staff who maintain the site after launch. We provide content guidelines and train staff on accessible content practices as part of every project.

Accessible PDFs. For organizations with significant PDF libraries, we work through document accessibility systematically: tagging documents for reading order, adding alt text to images within PDFs, ensuring form fields are labeled, and converting high-use documents to accessible HTML where practical.

Ongoing monitoring. An accessible site at launch does not remain accessible without monitoring. Plugin updates change output. New content introduces new issues. New team members add content without following guidelines. We use Insi, an accessibility monitoring platform that scans pages continuously and surfaces new issues before they accumulate into compliance problems.

The Legal Risk Question

Overlay companies frequently lead with legal protection as a primary selling proposition. Their marketing implies that installing an overlay insulates an organization from ADA lawsuits.

This is not what the legal record shows.

Multiple organizations that had overlay tools installed have been named in ADA web accessibility lawsuits. Courts have found that the presence of an overlay does not establish ADA compliance. Several plaintiffs’ attorneys have explicitly targeted overlay-using sites because the overlay demonstrates that the organization was aware of its accessibility obligations but chose a shortcut rather than genuine remediation.

The legal standard is not “best effort” or “we tried something.” It is compliance with WCAG 2.1 Level AA (the standard specified in the ADA Title II rule and the HHS Section 504 rule) or, by extension, WCAG 2.2. Overlays cannot reliably produce that outcome.

What to Do Instead

The alternative to an overlay is not a perfect, unattainable standard. It is a systematic process.

Start with an accessibility audit. An audit using automated tools plus manual keyboard testing and screen reader testing identifies where your site currently stands. The output is a prioritized list of issues organized by severity and complexity.

Fix structural issues in the theme and codebase first. Keyboard navigation, focus management, ARIA implementation in custom components, skip links, and landmark regions are code-level issues that affect every page. Fixing them at the theme level produces site-wide improvement efficiently.

Address content issues systematically. Alt text, heading structure, form labels, and link text can be addressed in a content audit pass with appropriate staff training and a clear style guide.

Implement ongoing monitoring. Once the initial remediation is complete, monitoring ensures compliance is maintained as the site grows and changes.

This process takes longer and costs more than installing an overlay widget. It also actually works.

A Note on User Preference Tools

Not everything an overlay provides is without value. User-facing preference tools (text size controls, high contrast mode, motion reduction) can be genuinely useful for some users as supplemental tools. The problem is when these are marketed as compliance solutions rather than as supplemental enhancements.

Building these features natively into your WordPress site using CSS custom properties and JavaScript preference storage is technically straightforward and does not carry the same risks as third-party overlay tools. The result is preference tools under your full control, without a third-party script running on every page load.

Frequently Asked Questions: Accessibility Overlays

ArcStone uses the Insi accessibility monitoring platform for ongoing compliance monitoring across all hosted sites. If you need an accessibility audit or want to talk about moving from an overlay to genuine WCAG compliance, we are ready to help.