You've probably repeated at least one of these five myths out loud, in a meeting, with total confidence. That's not a knock on you — they all sound reasonable. "We installed a widget, we're covered." "It's mostly a screen-reader thing." "We already fixed that." Each one feels like common sense. Each one is also measurably, expensively wrong.
The good news: busting a myth is a lot cheaper than losing the customers it costs you. Here are the five worth retiring today, each with a real number attached instead of a vibe.
The Stat: 22.6% of ADA website lawsuits filed in the first half of 2025 targeted sites that already had an accessibility overlay/widget installed. (Source: UsableNet, via the Overlay Fact Sheet coalition)
Myth 1: "An overlay widget makes us ADA compliant."
This is the big one, because it's sold as a solution — a script tag, a floating icon in the corner, and suddenly your legal exposure is "handled." It isn't. Overlay widgets typically adjust font size, contrast, and cursor size on top of your existing code, without fixing the underlying markup: the missing labels, the keyboard traps, the broken heading structure a screen reader actually depends on.
The number above isn't a coincidence. Over 800 organizations and accessibility professionals have put their name behind the Overlay Fact Sheet specifically because so many teams install a widget and then quietly stop thinking about accessibility at all. Plaintiffs' attorneys know this. A widget on the page doesn't deter a lawsuit — in a meaningful share of 2025 filings, it was already sitting there when the suit was filed.
What actually works instead: fixing the HTML, CSS, and ARIA at the source — semantic headings, real form labels, visible focus states, alt text that means something. It's less flashy than a widget, but it's the difference between a cosmetic layer and a site that genuinely works with assistive technology.
None of that means widgets are inherently bad — some ship genuinely useful preference controls, like remembering a user's font-size choice. The problem is treating the widget as the whole strategy instead of one small feature bolted onto a site whose underlying code was never actually fixed. If the widget is the only accessibility line item in your budget, that's the tell.
Myth 2: "Accessibility only matters for blind users."
Close your eyes and picture "an accessibility user" and most people picture someone using a screen reader. That's one slice of a much bigger picture. Per CDC's disability and health data, more than 1 in 4 U.S. adults — 28.7%, to be exact — have some type of disability. Vision is just one of six categories the CDC tracks; the others are hearing, cognition, mobility, self-care, and independent living.
That reframes the whole conversation. Captions help people with hearing loss and people watching a video on mute on the train. Clear, jargon-free copy helps people with cognitive disabilities and everyone else skimming on a phone. Large touch targets help people with mobility or dexterity limitations and anyone with a cracked screen and shaky hands. Design for the edges and the middle gets easier too.
Treating accessibility as a single-user, single-sense checkbox is exactly how teams end up fixing image alt text and calling it done, while form errors, timeouts, and confusing navigation — problems that hit cognition, mobility, and hearing — go untouched.
Myth 3: "We'll fix it once and be done."
Accessibility isn't a project with an end date; it's more like brushing your teeth. Skip it for a week and problems creep back in — a new banner without alt text, a form field a designer forgot to label, a "click here" link with no context.
The WebAIM Million — an annual scan of the top 1,000,000 home pages — has found the same six most common failure types for seven consecutive years running: low-contrast text, missing alt text, missing form labels, empty links, empty buttons, and missing document language. Seven years. Despite steadily rising awareness of accessibility as a discipline, the same basic errors keep reappearing, because most teams treat a fix as a one-time event instead of an ongoing practice tied to how they ship code.
The fix for this myth isn't more effort — it's a different rhythm: catch issues in code review, re-scan after every redesign, and treat a regression in contrast or labeling like you'd treat a broken checkout flow.
Myth 4: "WCAG is only a government requirement."
Section 508 does apply to U.S. federal agencies specifically, which is where this myth gets its foothold. But WCAG itself, and the legal exposure around it, reaches much further than government contracts. ADA.gov makes clear that Title III of the Americans with Disabilities Act — the part covering "places of public accommodation" — has been applied by courts to private commercial websites for years now. Retailers, restaurants, banks, and service businesses have all been named in accessibility litigation, well outside any government-contract context.
In other words, "we're not a government site" was never a shield. If your business serves the public online, WCAG-aligned accessibility is a baseline expectation courts have already been enforcing, not a nice-to-have reserved for agencies with a compliance mandate.
That confusion is understandable — Section 508 is the version most people hear about first, since it comes with an explicit federal mandate and a specific acronym attached. But the absence of a government logo on your homepage was never the thing determining your exposure. The determining factor is simpler: do members of the public use your website. If the answer is yes, this myth has already cost some companies real money in settlements and legal fees, regardless of their industry or client list.
Myth 5: "Our automated scanner catches everything."
Automated tools are genuinely useful — fast, cheap, great at catching contrast ratios and missing alt attributes at scale. The myth is treating a clean scan as a clean bill of health. According to Deque's Automated Accessibility Coverage Report, automated tools fully cover roughly 57% of accessibility issues by volume. The rest — things like whether a keyboard tab order actually makes sense, whether an error message is genuinely understandable, whether a custom widget behaves the way a screen reader user expects — requires a human evaluator actually using the site.
A green checkmark from a scanner is a good sign, not a finish line.
Here's a quick-reference on what to actually do about each myth:
- Turn off (or stop relying solely on) any overlay widget as your compliance strategy — audit the underlying code instead.
- Inventory your site by disability category, not just "screen reader users" — vision, hearing, cognition, mobility, self-care, independent living.
- Add an accessibility check to your regular QA or code-review process, not just a one-time cleanup sprint.
- Treat WCAG conformance as standard practice for any public-facing site, regardless of whether you're a government vendor.
- Pair automated scans with periodic manual and assistive-technology testing.
None of these fixes require a redesign. Most of them require someone to actually look — which is exactly what a proper audit does instead of guessing. If you want the real picture instead of a myth, a free automated scan of your homepage is a fast, no-pressure way to see which of these five is quietly true for your site right now.