Skip to main content

Accessibility overlays: why painting over problems doesn't fix them

Sergi Sánchez Mancha

There's a category of product that promises to make any website accessible by adding a single line of JavaScript. A floating widget appears in the corner, offering controls for contrast, font size, reading guides, and color adjustments. Some even claim compliance with WCAG, the EAA, or the ADA.

The pitch is appealing: paste a script tag, get a toolbar, check the compliance box. No code changes, no design work, no developer time.

It sounds too good because it is.

What overlays actually do

These widgets typically inject CSS and JavaScript that modifies how a page looks and behaves on the client side. Common features include:

  • Font size and spacing controls that adjust text display properties
  • Contrast modes that swap color palettes to higher-contrast themes
  • Reading aids like a line guide that follows the cursor, link highlighting, and title emphasis
  • Animation controls for pausing motion on the page
  • Profile presets ("seizure-safe", "ADHD-friendly", "vision-impaired") that bundle several adjustments together

Some of these features sound genuinely helpful. The problem isn't the idea of giving users control over their experience. The problem is where these controls live, and what they replace.

The core issue: overlays don't fix the code

If a form has no labels, an overlay can't add meaningful ones. If images have no alt text, the widget can't describe what's in the photo. If the tab order is broken, injecting CSS won't fix keyboard navigation. If heading levels jump from h1 to h4, no client-side script can rebuild your document structure.

Overlays address presentation, how things look. But most accessibility barriers are structural, how things are built. A screen reader doesn't read CSS. It reads the DOM. And if the DOM is broken, the overlay can't help.

This is like putting a fresh coat of paint on a building with no wheelchair ramp and calling it accessible. The paint looks nice. The ramp is still missing.

They can make things worse

This isn't theoretical. Research and user reports consistently show problems:

Conflicts with assistive technology. People who use screen readers, magnification software, or custom stylesheets already have their own tools configured for their needs. An overlay that injects its own focus management, color overrides, or font changes can interfere with these existing configurations. Users end up fighting two systems instead of one.

Performance impact. Overlays load additional JavaScript, sometimes significantly. For users on slower connections or older devices (the people who often need accessibility features most), this adds load time and can delay the page becoming interactive.

Inconsistent behavior. The overlay might work on one page but break on another where the site's own JavaScript conflicts with the injected modifications. Users can't predict when their adjustments will hold.

A separate experience. When accessibility depends on a widget instead of the native interface, users with disabilities get a fundamentally different experience from everyone else. The goal of accessible design is one good experience for everyone, not two separate paths.

The compliance question

Some overlay vendors market their products as making sites legally compliant. This claim doesn't hold up.

The EAA, which takes effect in June 2025, requires that products and services be accessible, not that they offer a separate tool for accessibility. WCAG conformance is measured against the site itself, not against what a third-party widget adds on top.

In the United States, courts have consistently ruled that overlays don't constitute compliance with the ADA. Organizations using overlays have been defendants in lawsuits because of their overlays, not despite them.

An overlay can't produce conformance with standards that require the underlying HTML to be correct. aria-label attributes, semantic heading structure, keyboard operability, form associations: these are code-level requirements.

Why overlays exist

This isn't about calling anyone negligent. Overlays became popular because accessibility is genuinely hard, tooling has historically been poor, and most teams face real constraints: limited budgets, tight deadlines, developers who weren't taught accessible patterns in school.

When someone offers a drop-in solution that promises compliance in five minutes, it's understandable that teams reach for it. The marketing is convincing, the urgency is real, and the alternative (learning and implementing accessible patterns across your entire codebase) sounds overwhelming.

The problem isn't that people want a shortcut. The problem is that this particular shortcut doesn't lead where it promises.

What actually works

Accessibility needs to be built into the code, not layered on top. That means:

Semantic HTML from the start. Use the right elements: <button> for actions, <nav> for navigation, <label> for form fields. This handles a surprising amount of accessibility without any extra effort.

Testing with real assistive technology. Screen readers, keyboard-only navigation, and magnification tools reveal issues that no automated scan or overlay will find.

Automated scanning in the development workflow. Tools like axe-core can catch structural issues during development, before they reach production. Catching a missing alt attribute during a code review is vastly better than patching it with an overlay after launch.

Continuous tracking. Accessibility isn't a one-time audit. Sites change constantly. Every new feature, every content update, every redesign can introduce new barriers. Teams need a way to verify that what was fixed stays fixed.

The WebAIM Million report finds that sites using overlays actually have more detectable accessibility errors on average than sites without them. This statistic alone tells the story.

The takeaway

If you're evaluating accessibility solutions, be cautious of anything that promises compliance without touching your codebase. Real accessibility is structural. It lives in your HTML, your ARIA attributes, your keyboard interactions, your color choices, your content hierarchy.

The good news: building accessible products is more achievable than it's ever been. Modern frameworks have better defaults, design systems are incorporating accessible patterns, and tools that integrate into development workflows can catch issues before they ship.

The work is worth doing properly. The people who depend on it deserve better than a widget.

Every product mentioned on this blog is used or built by a team trying to solve a real problem. Our focus isn't on who's doing it wrong, but on what "doing it right" actually looks like.