Accessibility overlays are a category of WordPress plugin that promise something appealing: install us, and your site becomes accessible. A small widget appears in the corner of every page, offering controls for text size, contrast, animation, and other settings that disabled users might need. The plugin is sold as compliance in a single click. For site owners who have been told they need to make their site accessible and have no idea what that involves, the pitch is hard to resist.
It is also, in the view of most accessibility professionals and the disabled users they advocate for, mostly wrong. Accessibility overlays do not produce accessible sites. They produce sites with overlays bolted onto inaccessible foundations, and the overlays themselves often make the underlying problems harder to fix. The marketing is selling something the technology cannot deliver.
This is uncomfortable to say, because the overlay industry has grown into a substantial business, and many site owners genuinely believe their overlay has solved their accessibility problem. The honest answer is that accessibility is a build decision, not an add-on, and treating it otherwise produces sites that fail real users while satisfying nobody but the people selling the plugin.
What accessibility actually means
Accessibility, in the web context, means that the site can be used by people with a wide range of disabilities — visual impairments, motor impairments, cognitive differences, hearing impairments — using whatever assistive technology they rely on. Screen readers. Keyboard-only navigation. Voice control. Switch devices. High-contrast modes. Magnification. Reduced motion.
The standards that describe what this means in practice — the Web Content Accessibility Guidelines, or WCAG — are detailed but not mystical. They cover semantic HTML, keyboard operability, sufficient contrast, alternative text for images, captions for video, predictable navigation, error identification, and several other categories. The guidelines are publicly available, well-documented, and broadly stable.
What makes a site accessible is whether it conforms to these guidelines structurally. Is the HTML semantic — using headings, lists, links, and form elements for their actual purposes rather than visual ones? Can every interactive element be reached and operated with a keyboard? Do colours meet the contrast ratios needed for users with low vision? Are images described in alt text that conveys their purpose? Are forms labelled in ways that screen readers can announce? Are video and audio captioned?
These are properties of the underlying code, the design choices, and the content itself. They cannot be retrofitted by a script that runs on top of the page. They have to be there in the first place.
What an overlay actually does
An accessibility overlay is a piece of JavaScript that loads on every page of the site and adds a control widget. The widget offers settings — larger text, higher contrast, reduced motion, alternative cursor, screen reader mode, and so on. Behind the scenes, the overlay attempts to modify the page in real time to apply whatever the user has selected.
Some of what overlays do is genuinely useful. A user-controlled high-contrast mode, for instance, is a real accessibility feature. The problem is that overlays generally do these things badly, in ways that conflict with the assistive technology users already have, while not addressing the structural problems that determine whether the site is actually accessible.
A user who needs higher contrast almost certainly already has it configured in their operating system or browser. The overlay’s high-contrast mode applies on top, sometimes interfering with the user’s existing preferences, sometimes failing on dynamic content, sometimes producing unreadable colour combinations. A user who navigates by keyboard does not need a button that promises “keyboard navigation mode” — they need every element on the page to already be keyboard-accessible. A user who relies on a screen reader does not need an overlay’s “screen reader mode” — they need the HTML to be semantically correct so their existing screen reader can do its job.
In each of these cases, the overlay is trying to provide a feature that the user’s own technology already provides, while leaving the underlying page in a state where the user’s own technology cannot work properly.
The problems overlays introduce
Overlays do not just fail to solve accessibility problems. They often introduce new ones.
The overlay widget itself can interfere with keyboard navigation. Users tabbing through the page hit the overlay controls before they can reach the main content. Some overlays trap focus inside their widget, requiring the user to dismiss it before they can interact with the page at all. For users who rely on keyboard navigation, the overlay can become an obstacle rather than an aid.
Overlays often inject elements into the page that confuse screen readers. ARIA attributes added by the overlay can conflict with the page’s existing semantics. Dynamic changes the overlay makes — adding new elements, modifying existing ones — can cause screen readers to announce confusing information or miss content entirely.
Some overlays attempt to “fix” accessibility problems automatically, in ways that introduce more issues than they resolve. Auto-generated alt text from image recognition, for instance, can produce descriptions that are technically accurate but meaningless in context — “image of a person standing” attached to a CEO’s portrait. Auto-detected headings can impose a structure that conflicts with the actual content. The overlay is producing accessibility-shaped noise.
And then there is the more uncomfortable problem. Several major accessibility overlays have been the subject of lawsuits in the US, where disabled users have argued that the overlay-protected site is still not accessible to them. Courts have, in a number of cases, agreed. The overlay has provided neither accessibility nor the legal protection it was sold to provide.
What actually produces accessibility
An accessible WordPress site is built that way. The work happens in the theme, the content, and the configuration, not in a plugin installed at the end.
The theme has to use semantic HTML. Headings as actual heading tags, in correct hierarchy. Navigation as nav elements. Forms with labels that screen readers can announce. Buttons as buttons, not styled divs. This is not exotic. It is the way HTML is supposed to be written. A theme that does it well is accessible by default; a theme that does not is fundamentally hard to make accessible afterwards.
The colour choices have to meet contrast ratios. WCAG specifies minimum contrast for text against background, depending on text size. A theme that uses light grey text on a white background, no matter how stylish, is failing this. The fix is to choose colours that meet the standard in the first place, not to provide a contrast overlay that users can switch on.
Every interactive element has to be reachable and operable by keyboard. Tab order has to be predictable. Focus states have to be visible. Skip-to-content links have to work. Modal dialogs have to trap focus appropriately. None of this is added by a plugin. All of it is part of the underlying build.
Content has to be written with accessibility in mind. Alt text for images. Captions for video. Descriptive link text rather than “click here.” Headings that actually structure the page. Forms with clear labels and error messages. This is the writer’s job, the editor’s job, the content team’s job — ongoing, on every piece of content the site publishes.
What the conversation should sound like
For developers and agencies, the honest conversation with clients about accessibility is one most are not yet having. It involves saying that accessibility is part of the build, costs more than ignoring it, requires ongoing maintenance, and produces a site that genuinely serves disabled users rather than one that performs the appearance of accessibility for non-disabled regulators.
It also involves saying clearly that the overlay industry is selling a product that does not do what it claims. Some clients will resist this, having already invested in an overlay solution. The honest answer is that the overlay can remain, but it does not constitute compliance, and the structural work still has to happen if the site is to actually serve disabled users.
This is a harder sell than the one-click overlay. It is also the truth, and clients deserve the truth on this. Disabled users deserve more.
The short version
Accessibility overlays promise compliance in a single click. They do not deliver it. Real accessibility is a build decision — semantic HTML, sufficient contrast, keyboard operability, descriptive content, ongoing attention from everyone touching the site — not something a plugin can produce on top of an inaccessible foundation. The overlays sometimes make things worse, by interfering with the assistive technology users already rely on and by giving site owners the false confidence that the accessibility problem is solved. The honest answer is that accessibility costs more than a plugin, requires ongoing effort, and is worth doing for reasons that go beyond compliance — including the basic one that disabled users are part of the audience your site is supposed to serve.
