Set It and Forget It Was Never the Whole Story: Our Honest Reckoning With Web Accessibility

Posted on August 28, 2026August 28, 2026 ADA Compliance

Henry Bramwell

Every agency has a few decisions it would make differently with the benefit of hindsight. This is the story of one of ours. We’re writing it down—publicly—because we think the honest version is more useful to our clients than a tidy one, and because the questions we’re grappling with now are ones many business owners are about to face.

For the past few years, roughly a dozen of our clients have relied on the AccessiBe accessibility widget to help them comply with the Americans with Disabilities Act (ADA) as it applies to their websites. We recommended it and stood behind that recommendation. Now, in light of a federal enforcement action and a growing chorus of criticism about accessibility “overlays” in general, we’re doing something uncomfortable but necessary: rethinking it out loud.

This isn’t a hit piece. AccessiBe remains a partner of ours, and we don’t think the people who use overlay tools are foolish or careless. We were among them. But the writing on the wall has become hard to ignore, and pretending otherwise wouldn’t serve anyone. So here’s where we started, what we believed, what changed, and where we’re going.

How We Got Here: A Demand Letter and a Wake-Up Call

Our accessibility journey didn’t begin with a strategy deck. It began with a scare.

A few years ago, one of our clients received a demand letter from a law firm asserting that their website was inaccessible to people with disabilities and, therefore, out of step with the ADA. Here’s the detail we can’t leave out: that client’s site already had an accessibility overlay previously installed when the letter arrived. An automated widget was in place, yet it did not prevent the legal threat from landing. If you’ve never seen one of these letters, they are jarring. They arrive without warning, cite legal standards most business owners have never heard of, and carry the implicit threat of a lawsuit that would cost far more to fight than to settle.

That letter taught us something we should have internalized sooner: website accessibility is not an abstract “nice to have.” It is a real obligation with real consequences, and the businesses most exposed are often small and mid-sized companies who never saw it coming. We learned firsthand and under pressure that you need a formal program to address accessibility—not a one-time fix, not a scramble after a letter lands, but an ongoing, documented approach. The overlay already on that client’s site was an early hint that a script alone doesn’t add up to such a program—a hint it took us longer than it should have to fully act on.

The problem was that we absorbed the right lesson and then, understandably but mistakenly, let the wrong motivation drive it.

Why We Reached for an Overlay for Web Accessibility

Here is the honest calculus we ran at the time.

Most of our existing clients had established websites—dozens, sometimes hundreds of pages built over years. Retrofitting every one of those pages to comply with the Web Content Accessibility Guidelines (WCAG) by hand is a significant undertaking. It costs money. It takes time. And for a business that just received a threatening letter, “significant undertaking” can feel like a luxury they can’t afford while the clock is ticking.

Overlays like AccessiBe offered something that felt like relief: a single line of JavaScript you can place on your site that promises to detect and automatically remediate accessibility issues. The pitch was seductive precisely because it was simple. Install the script, and your site becomes accessible. No page-by-page audit, no developer backlog, no months of work.

We knew—even then—that overlays were not as effective as native remediation. We understood that fixing accessibility at the source, in the actual code and content, produces a genuinely better result than a script layered on top at runtime. But we made a judgment call: for a large existing site facing legal exposure, an overlay seemed like a reasonable, defensible way to demonstrate proof of effort while buying time.

And there’s the confession. Somewhere along the way, “proof of effort to avoid a lawsuit” quietly became our top priority. That is exactly backwards. Accessibility and user experience should drive a website’s strategy; legal risk should be a byproduct you manage, not the tail that wags the dog. When you optimize for looking compliant rather than for usability, you can check a box and still fail the very people the law exists to protect. That was our biggest lesson, and it’s one we’re not too proud to admit we learned the hard way.

The “Set It and Forget It” Problem

There’s a phrase that kept rattling around in our heads as we thought this through. Anyone who watched late-night television in the ’90s remembers Ron Popeil selling the Showtime Rotisserie with his unforgettable slogan: “Set it and forget it!” You loaded the chicken, closed the door, walked away, and dinner took care of itself.

That is, essentially, how automated overlays are marketed. Drop in the script and—presto—your website is compliant. Set it and forget it.

But accessibility is not a rotisserie chicken. Websites change constantly. Content is added, layouts are updated, and third-party tools are embedded, and each change can introduce new barriers. A dynamic script can smooth over some issues, but it cannot understand context, intent, or nuance the way a human remediation team can. It can’t write a meaningful alt description for an image it has never seen in context. It can’t restructure a confusing form flow. It can’t decide what a screen reader user actually needs to accomplish on your page.

We suspected this. But the moment it really clicked for us came from an unexpected place: AccessiBe itself.

What Their Own Service Told Us

Here’s where our thinking sharpened. Alongside the widget, AccessiBe offers a custom remediation service called MTCR, positioned as a blend of AI and human expertise. It pairs expert manual testing of a site’s core user journeys with custom-built fixes and tailored adjustments to the accessWidget script, aimed at helping a site adhere to WCAG and comply with regulations. The company’s framing is candid about why it exists: the things that make a website distinctive often call for a deeper approach to accessibility, so it combines automation with hands-on human expertise to deliver the testing and tailored fixes a site actually demands.

That framing matters, and it’s to AccessiBe’s credit that they state it plainly—because it’s not the “set it and forget it” story. It’s an acknowledgment, from the vendor best positioned to know, that the automated widget on its own doesn’t fully meet the needs of many real-world sites. When we first noticed the service, it struck us as a quiet contradiction of the original pitch: if placing the script on your site really made it compliant, why sell hands-on, human remediation work at all? In their current positioning, it reads less like a contradiction and more like a concession—automation gets you part of the way, and human expertise does the rest.

We don’t hold that against them; if anything, MTCR is a better choice. But it reframes the entire proposition. If the sites that call for a deeper, human-led approach are the rule rather than the exception—and in our experience, they are—then the widget alone was never going to be the finish line for the clients who needed help most.

The FTC Settlement

In April 2025, the Federal Trade Commission approved a final consent order against accessiBe, requiring the company to pay $1 million. The FTC’s complaint, announced in January 2025, alleged that the company’s claim—that its accessWidget plug-in could make any website compliant with WCAG—was false, misleading, or unsubstantiated because the widget did not, in fact, make all customer websites WCAG-compliant.

There was a second, equally important allegation. According to the FTC, the company formatted third-party articles and reviews to make them appear as independent, impartial opinions, while failing to disclose its material connections to those “objective” reviewers. In plain terms: some of the praise that helped sell the product allegedly wasn’t as independent as it appeared.

The final order bars accessiBe from claiming that its automated products can make any website WCAG-compliant or keep it compliant over time unless it has evidence to support that claim. It also prohibits misrepresenting paid or affiliated endorsements as independent opinions.

We want to be careful and fair. A consent order is a settlement, not a court’s finding of guilt, and companies often resolve these matters without admitting the allegations. AccessiBe has continued to operate, evolve its tools, and serve a large customer base. But for us, the substance of the FTC’s concerns aligned uncomfortably well with the doubts we’d already been forming. When your independent hunch and a federal regulator arrive at the same intersection from different directions, it’s time to pay attention.

What we’re rethinking now

Two things are happening at Visionary in parallel, and they point the same direction.

First, for every new website we build, we’ve moved to native accessibility remediation from the ground up. That means designing and developing with WCAG in mind from the first wireframe—semantic markup, proper heading structure, keyboard navigability, sufficient color contrast, meaningful alternative text, accessible forms, and testing with real assistive technology. Accessibility built into development is dramatically more effective, more durable, and frankly more cost-efficient than accessibility bolted on afterward. It’s also simply the right way to build. Addressed at the source, accessibility improves usability for everyone, not just users of assistive tech.

Second, and this is the genuinely hard part, we’re deciding what to do for our existing clients who are currently running AccessiBe on our recommendation. We don’t take that lightly. These are relationships we value, and we advised them into their current setup in good faith. A few principles are guiding how we approach it:

• No panic, no fear-selling. We won’t stampede anyone into an expensive rebuild by waving a lawsuit in their face. That would repeat the exact mistake we’re trying to correct.
• Honest assessment first. Each site is different. Before recommending anything, we want a clear-eyed look at where a site actually stands—what the overlay is helping with, what it’s masking, and where real barriers remain.
• A path toward native remediation over time. For most clients, the destination is conformant code and content, approached in a prioritized, budget-aware way rather than all at once.
• Accessibility as an ongoing program, not a plug-in. The formal-program lesson from that first demand letter still holds. Whatever tools we use, the commitment has to be continuous.

Where the overlay conversation goes from here

We’re not declaring overlays worthless. Some of their user-facing features—such as letting a visitor adjust contrast, text size, or spacing to their preference—can add genuine value, and there are situations where a tool can be one part of a larger effort. What we reject now is the idea that any single script is a complete accessibility solution or a reliable shield against legal risk. It never was. The vendor’s own move into manual remediation, criticism from accessibility professionals, and the FTC’s action all say the same thing from different angles.

If you’re a business owner reading this and feeling a flicker of the same anxiety that the demand letter gave our client years ago, here’s our plain advice, offered as practitioners rather than attorneys—this is our experience, not legal counsel: don’t buy the “set it and forget it” promise from anyone, ourselves included. Treat accessibility as a real, ongoing part of how your website is built and maintained. Ask hard questions of any tool that promises effortless compliance. And measure success by whether people with disabilities can actually use your site—because that, not a checkbox, is the entire point.

The lesson we’re keeping

The honest takeaway from our journey is a little humbling. We learned the importance of accessibility the right way—through a real client, a real threat, and real stakes. Then we let the fear of litigation, rather than the goal of genuine usability, steer our response. We reached for the fastest-looking fix, and for a while that felt prudent.

It taught us something we won’t forget: accessibility is a practice, not a product. You can’t outsource responsibility to a line of JavaScript any more than you can outsource good judgment. The tools will keep changing. The standards will keep evolving. Unfortunately, the lawsuits aren’t going anywhere. What endures is the commitment to building things that work for everyone—and the willingness to say, out loud, when we’ve learned we can do better.

We’re doing better. And we’ll keep documenting it here, honestly, as we go.

Frequently Asked Questions

Further reading on the FTC action and the broader overlay debate:

• FTC — Final Order Requiring accessiBe to Pay $1 Million
• Seyfarth’s ADA Title III blog — FTC Orders accessiBe to Pay $1M for Misleading Claims
• AccessiGuard — AccessiBe FTC Fine and Overlay Problems
• OECD.AI — Incident record

This article reflects our own experience and opinions. It is not legal advice; for questions about your specific ADA obligations, consult a qualified attorney.