A family friend runs a physical therapy clinic. Good practice, solid reputation, the kind of place where patients actually get better. A few weeks ago they asked me to take a look at their website. They'd been paying for an accessibility overlay, one of those tools that drops a widget icon in the corner of your site and claims to make it WCAG-compliant. I quickly realized the site was relying entirely on an overlay for accessibility, and it wasn't doing its job. Not even close.
I hold the W3Cx WAI0.1x certification from W3C, and I built AccessHawk, an AI-powered WCAG scanner. So this is something I think about a lot. But you don't need a certification or a scanning tool to understand the problem here. These overlay companies have been selling a shortcut that doesn't work, and businesses, especially in healthcare, are the ones left holding the bag when it falls apart.
What overlays actually do (and don't do)
An accessibility overlay is a third-party JavaScript widget that gets injected into your website. Overlay companies sell these products with a simple pitch: add one script tag, and your site becomes accessible. WCAG-compliant. ADA-ready. No code changes needed.
In practice, these widgets add a toolbar that lets users adjust font size, toggle contrast, or enable a screen reader mode. Some use AI to guess at missing alt text or infer form labels. On the surface, it looks like it's doing something. But here's the problem: none of that fixes the underlying code.
If your site has a form where the input fields aren't associated with their labels, an overlay might try to guess the association at runtime. If an image is missing alt text, the AI might generate a description. But these are band-aids applied on top of broken markup. Screen readers don't always pick them up. The fixes can conflict with assistive technology that users already have configured. And when the overlay's JavaScript fails to load, or the user has scripts blocked, everything the widget was supposedly fixing reverts to its broken state.
The Overlay Fact Sheet, signed by over 800 accessibility professionals, puts it plainly: overlays do not and cannot repair the underlying accessibility problems in a website's source code.
The legal landscape has shifted
For years, overlay companies operated in a gray area. They made big claims, businesses bought in, and nobody looked too closely. That changed fast.
The FTC stepped in
In January 2025, the FTC announced a $1 million settlement with accessiBe for deceptive marketing. The company had claimed its AI-powered widget could make any website WCAG-compliant within 48 hours. The FTC found those claims were "false, misleading, or unsubstantiated." The final order, approved in April 2025, bars accessiBe from making compliance claims without evidence and remains in effect for 20 years.
That's not a slap on the wrist. That's the federal government saying, on the record, that these products cannot do what they advertise.
Overlays are showing up in lawsuits as the problem, not the solution
According to UsableNet's 2024 Year-End Report, over 4,000 ADA digital accessibility lawsuits were filed in 2024. Of those, 25% specifically cited accessibility widgets and overlays as barriers rather than solutions. Plaintiffs are pointing at the overlay itself as evidence that the site isn't accessible.
The lawsuits kept coming in 2025, with nearly 500 targeting overlay-equipped websites in just the first half of the year. Having an overlay installed isn't a legal shield. It's a target.
Overlay companies are getting sued by their own customers
In 2024, a flower delivery company filed a class action lawsuit against UserWay in Delaware District Court after being sued by a disabled user who couldn't navigate their site despite the UserWay overlay being installed. The lawsuit alleges UserWay promoted its product as a simple, foolproof ADA compliance solution and failed to deliver. The court allowed the case to proceed.
Meanwhile, AudioEye previously sued accessibility expert Adrian Roselli for publicly criticizing overlay products. The case was widely viewed as a SLAPP suit to silence critics. AudioEye dropped it in January 2024. The National Federation of the Blind revoked accessiBe's sponsorship of its 2021 national convention, calling the company's behavior "harmful to the advancement of blind people in society."
When the disability community, the courts, and the federal government are all telling you the same thing, it's worth listening.
Why healthcare sites carry higher risk
Every business with a public website has some level of ADA exposure. But healthcare practices face more risk than most.
Think about who visits a physical therapy clinic's website. Patients recovering from injuries. People managing chronic pain or mobility limitations. Older adults who may have vision or motor impairments. These are exactly the populations most likely to rely on assistive technology, and most likely to encounter barriers that overlays don't fix.
- Healthcare providers are places of public accommodation under ADA Title III. Courts have increasingly ruled that this extends to websites, especially when the site is used to schedule appointments, access patient information, or submit intake forms.
- A PT clinic isn't like a skateboard shop. Your patients are, by definition, dealing with physical limitations. If your appointment booking form can't be navigated with a keyboard, that's not a hypothetical problem.
- HIPAA doesn't directly mandate WCAG compliance, but a third-party overlay script running on pages that handle patient information raises data handling questions most small practices haven't thought about.
- California, New York, and Illinois have all seen aggressive ADA web accessibility litigation. Healthcare practices in these states are frequent targets.
The DOJ's April 2024 Title II rule requires WCAG 2.1 Level AA conformance for state and local government web content, with compliance deadlines in 2026 and 2027. While Title II targets government entities, it signals the direction enforcement is heading for Title III (private businesses) as well.
What real accessibility looks like
If overlays don't work, what does? The answer isn't complicated. It's just not a shortcut. Real accessibility is built into the source code of your website. It's not bolted on after the fact with a widget.
Semantic HTML
Use the right elements for the right purpose. A navigation menu should be inside a <nav> element. A page heading should be an <h1>, not a <div> styled to look like one. Buttons should be <button> elements, not <div onclick> hacks. When you use semantic HTML, screen readers and other assistive technology can understand the structure of your page without any extra work.
Form labels and associations
Every form input needs a <label> element explicitly associated with it using the for attribute. Placeholder text is not a label. When a screen reader user tabs into an email field that has no associated label, they hear "edit text" with no context. That's the kind of issue overlays try to guess their way around, and frequently get wrong.
Keyboard navigation and focus management
Every interactive element on your page needs to be reachable and operable with a keyboard alone. Tab order should follow a logical sequence. Focus should be visible (no outline: none without a replacement). Modal dialogs should trap focus and return it when closed. Dropdown menus should be navigable with arrow keys. This is basic stuff, and overlays can't retrofit it.
Meaningful alt text
Images that convey information need alt text that describes what the image communicates, not just what it contains. A photo of your clinic's entrance might need alt text like "Front entrance with wheelchair-accessible ramp and automatic doors" rather than "building." Decorative images should have empty alt attributes (alt="") so screen readers skip them entirely.
Color contrast
WCAG 2.1 Level AA requires a contrast ratio of at least 4.5:1 for normal text and 3:1 for large text. That light gray text on a white background might look clean, but it's unreadable for users with low vision. This is a design decision, not something a runtime widget can reliably fix across every element on your site.
ARIA attributes (used correctly)
ARIA (Accessible Rich Internet Applications) attributes provide additional context to assistive technology. But the first rule of ARIA is: don't use ARIA if native HTML can do the job. When you do need it, use it correctly. An aria-label on a button that says "X" can tell screen readers it means "Close dialog." But ARIA misuse, like adding role="button" to a <div> without also handling keyboard events, actually makes things worse.
Putting it together: what accessible markup actually looks like
Here's a real-world example. An appointment request form, the kind you'd find on a healthcare website. The first version is what overlays try to patch at runtime. The second is what it looks like when you build it right from the start.
Inaccessible markup (what overlays try to fix):<div class="form">
<div class="field">
<input type="text" placeholder="Full Name">
</div>
<div class="field">
<input type="text" placeholder="Email">
</div>
<div class="field">
<input type="text" placeholder="Phone">
</div>
<div class="field">
<div class="label">Preferred Date</div>
<input type="text" placeholder="MM/DD/YYYY">
</div>
<div class="field">
<div class="label">Reason for Visit</div>
<textarea placeholder="Describe your condition..."></textarea>
</div>
<div class="btn" onclick="submitForm()">Request Appointment</div>
</div>
No <form> element. No <label> elements. Placeholder text used as labels (which disappears on focus). A <div> acting as a button with no keyboard support. A screen reader user landing on this form hears a series of unlabeled edit fields with no context.
<form aria-labelledby="form-heading" method="post" action="/api/appointments">
<h2 id="form-heading">Request an Appointment</h2>
<div class="field">
<label for="full-name">Full Name</label>
<input type="text" id="full-name" name="fullName" required
autocomplete="name">
</div>
<div class="field">
<label for="email">Email Address</label>
<input type="email" id="email" name="email" required
autocomplete="email">
</div>
<div class="field">
<label for="phone">Phone Number</label>
<input type="tel" id="phone" name="phone"
autocomplete="tel">
</div>
<div class="field">
<label for="date">Preferred Date</label>
<input type="date" id="date" name="preferredDate" required>
</div>
<div class="field">
<label for="reason">Reason for Visit</label>
<textarea id="reason" name="reason" required
aria-describedby="reason-hint"></textarea>
<p id="reason-hint" class="hint">
Briefly describe your symptoms or the type of care you need.
</p>
</div>
<button type="submit">Request Appointment</button>
</form>
Every input has an associated <label>. The form has a semantic heading. Input types are specific (email, tel, date) so mobile keyboards adapt and validation is built in. The submit element is a real <button> that works with keyboards and screen readers out of the box. The textarea has a hint linked with aria-describedby so assistive technology reads it in context. No overlay needed.
The overlay pitch vs. reality
Overlay companies sell to business owners who don't have the technical background to evaluate the claims. The pitch sounds reasonable: "You don't need to rebuild your site. Just add this one script." For a small business owner who's already juggling payroll, marketing, and patient care, that's hard to say no to.
But the reality is that accessibility is a development practice, not a product you install. It's like the difference between a building that was designed with wheelchair ramps, wide doorways, and accessible restrooms versus one that bolts a "wheelchair accessible" sign on the front door without changing anything inside.
The building inspector doesn't care about the sign. And increasingly, neither do the courts.
What to do if your site is using an overlay right now
If you're a business owner reading this and your site currently uses an overlay, don't panic. But do take it seriously.
- Have a qualified developer or accessibility professional evaluate your site against WCAG 2.1 Level AA. Tools like AccessHawk can give you an automated baseline, but a thorough audit includes manual testing with screen readers and keyboard-only navigation.
- Focus on the issues that prevent users from completing core tasks first. Can someone book an appointment? Can they navigate to your contact information? Can they read your services page? Fix these first.
- Accessibility isn't a one-time fix. It needs to be part of how your site is built and maintained. If your current developer's answer to accessibility is an overlay, find someone who knows how to write accessible markup.
- Once your site's source code is accessible, you don't need a widget. The overlay adds page weight, can interfere with assistive technology, and signals to informed plaintiffs that your site likely has underlying issues.
- Maintain an accessibility statement on your site. Note what standards you're conforming to, what's been tested, and how users can report issues. This shows you're taking it seriously and staying on top of it.
The bottom line
Accessibility overlays are not a compliance solution. The FTC has said so. The courts are saying so. The disability community has been saying so for years. These products create a false sense of security while leaving the actual problems untouched, and increasingly, they're making businesses more vulnerable to legal action, not less.
If your website was built accessible from the source code, you wouldn't need an overlay. You want a site where the HTML, the design, and the interactions work for everyone, not a widget guessing at fixes on top of broken markup.
For healthcare practices especially, this isn't optional. Your patients are the people who need accessible websites the most. Build it right, or find someone who will.