WordPress accessibility belongs in the code, not in an overlay.

Accessibility overlays are the WordPress plugin category I most consistently recommend against. They promise WCAG compliance with a one-line install. They deliver something closer to security theater for accessibility — an icon in the corner, a settings panel few users open, and almost no improvement in the actual lived experience of disabled visitors. Real accessibility happens in the code. Here's why overlays don't work, what they break, and what to build instead.

The accessibility overlay vendors have done extraordinary marketing work in the last five years. AccessiBe, UserWay, EqualWeb, AudioEye — each one offers some version of the same pitch: install our JavaScript, your site becomes WCAG compliant, you’re protected from accessibility lawsuits. The pitch is internally coherent. It’s also not how accessibility works. The reason websites using accessibility overlays are still routinely subject to lawsuits, from the same disabled users the overlays claim to help, is that the underlying technology can’t do what the marketing says it does.

What overlays actually do.

An accessibility overlay is, mechanically, a JavaScript file that runs after the page loads and tries to patch the rendered DOM to improve accessibility. Typically it does some combination of:

• Adds an icon (usually bottom-right) that opens a settings panel
• Lets the user pick font size, contrast level, link highlighting, animation reduction
• Attempts to add missing alt text using AI image recognition
• Attempts to infer ARIA roles for elements that lack them
• Sometimes reads the page aloud via a built-in screen reader

None of this is inherently wrong. The problem is that each of these features is dramatically less reliable than the equivalent built into the user’s existing assistive technology — and several of them actively conflict with the assistive technology the user is already running.

Why overlays fail the people they claim to help.

The specific failure modes that show up in real user testing:

• Screen-reader conflict. A blind user already has a screen reader (NVDA, JAWS, VoiceOver). When an overlay tries to inject ARIA labels onto elements at runtime, the screen reader is now seeing different DOM than it expected mid-session. The result is duplicated announcements, broken navigation order, and a worse experience than the un-overlaid page would have been.
• Auto-generated alt text is mostly wrong. AI-generated alt text without editorial review produces strings like “a person standing in a room” for a photo of a CEO, or “a logo” for a brand mark. Screen reader users hear noise where they need context.
• Focus management breaks. When the overlay’s settings panel opens, focus often jumps to it without warning. When it closes, focus doesn’t return to where it started. For keyboard users, this means losing your place on the page every time the overlay does anything.
• The settings panel itself is rarely accessible. Several major overlays have been audited and found to have their own WCAG violations in their UI — ironically.
• Performance impact. The overlay runs on every page load, on every browser, even for users who don’t need any of its features. On mobile especially, the added JS is noticeable.

The pattern across all of these: the overlay is solving for a checkbox on a marketing site, not for the actual experience of a disabled user. The checkbox passes. The experience gets worse.

What real WordPress accessibility looks like.

Accessibility in code, the way it actually works:

• Semantic HTML. Use headings hierarchically (one H1, descending H2/H3 below it). Use buttons for actions, links for navigation. Use form labels. Use landmark elements (nav, main, footer). This is the foundation; everything else builds on it.
• Color contrast that meets WCAG 2.2 AA on every text/background pair. Verified at design time, enforced in CSS variables, not bolted on at runtime.
• Keyboard support. Every interactive element reachable and operable with a keyboard. Visible focus states. Sensible tab order. No focus traps in dropdowns, modals, or accordions.
• ARIA used minimally and correctly. The first rule of ARIA is: don’t use ARIA when native HTML works. Most accessibility wins come from native semantics, not from layered ARIA roles.
• Alt text written by humans for every image. Decorative images get alt="". Informative images get descriptive alt that conveys the information the image carries. Editorial process makes this happen at upload time, not as a backlog item.
• Forms with accessible error states. Errors announced via aria-live, field-level errors associated to their input via aria-describedby, focus moved to the first error on submit failure.
• Reduced-motion respected. When the user’s OS says “prefer reduced motion,” animations stop. CSS makes this easy with a media query.

What about WordPress specifically.

WordPress sites have some specific accessibility patterns that recur:

• Theme-level templates that use semantic HTML by default. Most off-the-shelf themes ship with semantic markup; some ship with div-soup. Audit the theme before you build on top of it.
• ACF flexible-content fields that include accessibility-relevant configuration. Heading levels should be configurable, not hardcoded. Decorative-vs-informative image distinction should be explicit at the editor level.
• Plugins that add markup. Form plugins, gallery plugins, slider plugins — each one adds its own markup that may or may not be accessible. Audit the rendered output, not the plugin’s marketing.
• Editor training. The team uploading content needs to know what alt text actually is, what a meaningful link looks like, why headings matter. This is a 20-minute conversation that materially affects the accessibility of every page they touch.

So why are overlays still everywhere.

Three reasons, in order of how often I hear them:

• The sales pitch is hard to resist. “Install this; you’re compliant” is more attractive than “here’s a 30-day code-level accessibility effort.” The illusion of fast compliance is what overlays are actually selling.
• The cost difference is real. An overlay subscription is hundreds per year. A real accessibility pass is thousands or tens of thousands. The expensive version is the right one for sites with real exposure; the overlay is the wrong version of cheap.
• The downside isn’t immediate. A poorly-coded site with no overlay doesn’t trip a visible alarm. The site fails its users quietly. The cost surfaces only when a user actually tries to navigate and can’t — and most teams never hear about it.

The right WordPress accessibility posture in 2024 is to skip the overlay, do the code-level work, and treat WCAG conformance as something the site genuinely meets — not something a bolted-on widget claims on its behalf. See accessibility that holds up for what that engagement actually looks like.