That Accessibility Widget Won't Protect Your Medical Practice From a Lawsuit

A practice manager at a small orthopedic office told us she thought she had this handled. A vendor had sold her an accessibility widget two years ago, the kind that adds a little person shaped icon to the corner of the site with sliders for bigger text and higher contrast. The sales page said it made her website ADA compliant. She pasted in the code, checked the box in her head, and moved on. Then a demand letter arrived in the mail, from a law firm she had never heard of, representing a patient who said he could not book an appointment on her site with his screen reader.

She was stunned for two reasons. First, she thought the widget was her shield. Second, the letter actually mentioned the widget, and not in her favor. That is the uncomfortable truth more practice owners are running into this year. The accessibility overlay you bought to avoid a lawsuit has become one of the first things a plaintiff's attorney looks for. Let us walk through why, and what to do instead.

What an accessibility widget actually is

These tools go by a few names: overlays, accessibility widgets, accessibility plugins. The best known are products like accessiBe and UserWay. The pitch is irresistible to a busy practice owner. One line of code, a monthly fee, and a promise that software will scan your site and fix it for people with disabilities, automatically, forever. No developer, no audit, no hassle.

Here is the problem. An overlay does not change your website. It is a script that loads on top of your existing code and tries to patch things in the half second a page opens, guessing at fixes. It leaves the actual source of your site exactly as broken as it was. As one widely cited accessibility engineer put it bluntly, overlays cannot repair the underlying accessibility problems in a website's source code. You have put a bandage over the code, not healed it.

Why the widget can make things worse

A bandage would at least be neutral. The trouble is that overlays often fail in ways that are their own problem, and that failure is now being used against the businesses that installed them.

• They fight the tools patients already use. A blind patient has their own screen reader set up exactly how they like it. An overlay that tries to take over can conflict with that setup and make the site harder to use, not easier.
• They depend on a script loading. If the overlay script is blocked or fails, every supposed fix vanishes and the page is broken again.
• They guess, and guess wrong. Automated alt text and form labels generated by the widget frequently miss the context a real person needs, so an image or a booking field still makes no sense out loud.
• They advertise the problem. This is the big one. The visible widget tells a plaintiff's attorney two things at a glance: this business knew accessibility was an issue, and it chose a shortcut instead of a real fix.

That last point is why the numbers have turned. In 2024, roughly a quarter of all digital ADA lawsuits named an accessibility widget as part of the barrier rather than the solution, and in the first half of 2025 alone nearly 500 lawsuits targeted sites that had an overlay installed. The regulators noticed too. In January 2025 the Federal Trade Commission settled with accessiBe for one million dollars over marketing claims it called deceptive. The shortcut everyone was sold is now the thing being litigated.

Why small practices are the target now

If you run a single location practice and assume these suits only hit big hospital systems, the data says otherwise. UsableNet, which tracks this litigation, reports that about two out of three website accessibility lawsuits are filed against companies earning under 50 million dollars a year. The small local business is not the exception anymore. It is the pattern.

The reason is simple math for the firms filing. A local medical practice usually has a website with a booking form, a patient portal link, or an intake form, exactly the kind of page where accessibility failures are easy to document. The practice is big enough to pay a settlement and small enough that it rarely has a legal team on standby. Multiply that by the roughly 265,000 businesses that receive accessibility demand letters each year, per the Bureau of Internet Accessibility, and you see why healthcare keeps showing up in the filings. Medical and health sites made up 75 of just over 1,000 cases that one tracker logged in a single recent quarter.

What the law actually asks for

There are two forces at work, and it helps to keep them straight. The first is the Americans with Disabilities Act. Courts have increasingly treated a medical practice website as an extension of your office, a place of public accommodation that has to be usable by people with disabilities. This is the basis for most of the private lawsuits, and it applies whether or not you take any government money. If you want the plain language version, the Department of Justice lays it out at ADA.gov.

The second is newer and specific to healthcare. A 2024 federal rule under Section 504 of the Rehabilitation Act now requires organizations that receive federal funding, which includes almost anyone who bills Medicare or Medicaid, to make their websites meet a recognized standard called WCAG 2.1 at Level AA. Larger organizations had to comply by the spring of 2026. Practices with fewer than 15 employees have until the spring of 2027. WCAG is the technical checklist courts and regulators use to decide if a site is genuinely accessible, and you can read it straight from the source at the W3C Web Accessibility Initiative.

The short version: between the ADA on one side and the Section 504 rule on the other, a real accessibility standard now applies to practically every practice in the country. A widget does not meet it. We walked through the basics of this in our earlier piece on whether a medical practice website needs to be ADA compliant, and the overlay question is the natural next one owners ask.

What real accessibility looks like

Here is the good news hiding inside all of this. Making a site genuinely accessible is not mysterious, and it is not endless. It is a defined set of things, done in the actual code of your website rather than bolted on top of it. The core of WCAG 2.1 AA comes down to a handful of plain ideas.

• Structure. Real headings in order, so a screen reader can move through the page the way a sighted patient skims it.
• Text alternatives. Every meaningful image has a short description, so a photo or a map is not just silence.
• Labeled forms. Every field on your booking or intake form is clearly tied to its label, so a patient filling it out by voice knows what goes where.
• Contrast. Text that stands out enough from its background to read, including for the many patients with aging eyes.
• Keyboard access. The whole site can be used without a mouse, because many assistive tools drive the page from the keyboard.
• Captions. Any video on the site is captioned.

The honest path is an audit of your current site against that standard, a round of fixes in the real code, and a test with actual assistive technology, ideally watched by a real user. It is more effort than pasting a script, and it is the only thing that both lowers your legal exposure and, more to the point, lets a disabled patient actually book with you. Roughly one in four American adults lives with a disability. For a practice, these are not edge cases. They are patients.

The part that surprises owners: it helps your ranking too

Accessibility and search optimization are not two separate chores competing for your budget. They are mostly the same work. The clean heading structure a screen reader needs is the same structure Google reads to understand your page. The descriptive alt text that tells a blind patient what an image shows also tells a search engine what it is looking at. Labeled links and fast, keyboard friendly pages help everyone, human and crawler alike. The AI assistants patients increasingly use to find a doctor lean on that same clean markup.

So the money you put into doing this properly is not pure defense. It also strengthens your healthcare SEO at the same time. That is the opposite of a widget, which adds code that can slow your page down and does nothing for how you show up in search. One approach builds a better foundation. The other rents you a false sense of safety by the month.

How we handle it for practices

When we build or rebuild a site through our websites service, accessibility is part of the build, not an add on we sell you later. That means the structure, the contrast, the labeled forms, the keyboard navigation, and the captions are done in the site itself and checked against WCAG 2.1 AA. When a patient on a screen reader lands on a page we built, the booking form works, because it was made to work, not patched to look like it does.

And because an accessible site is also a cleaner, faster, better organized site, it feeds the rest of the patient acquisition system we run. A site that every patient can actually use, that Google can actually read, that does not leave a legal landmine in the corner, is simply a better front door. If you already have an overlay widget installed, that is not a reason to panic. It is a reason to get the real site under it checked.

Our honest take

We understand why the widgets sold so well. A busy owner wants one problem solved with one click, and the pitch promised exactly that. But a shortcut that a plaintiff's attorney now treats as a confession is not a solution, it is a liability wearing a friendly icon. The practices getting letters this year are learning that the hard way, and the ones who paid for a widget are not any safer for it.

The orthopedic office we mentioned at the top is fine now. We did not argue with the demand letter by pointing at a plugin. We audited the site, fixed the booking form and the structure and the contrast in the actual code, and gave her something she could stand behind. It cost more than the widget subscription. It also did the thing the widget never could: it let the patient book, and it gave her a website she does not have to be afraid of. That is the whole point. Build it right, and the protection is real.