A business gets an ADA demand letter, panics, and buys an accessibility overlay widget that same afternoon. The little icon in the corner, the “one line of code and you’re covered” pitch, the monthly subscription. Six months later a second letter arrives, and sometimes it cites the widget itself as a new barrier. The site was never actually fixed. The owner paid twice: once for the subscription, once for the settlement.
Compliance lives in your website’s code, not in a plugin bolted on top of it. What follows is the standard in plain English, so you can check your own site before anyone forces the issue.
One thing up front: we build and fix websites. If a demand letter is sitting on your desk, your attorney owns the legal strategy. What follows is the technical side.
Is ADA website compliance actually required by law?
The ADA itself never mentions websites, but courts have repeatedly treated business websites as places of public accommodation, and WCAG 2.1 Level AA is the technical standard regulators and plaintiff attorneys point to. If your site serves customers, the practical assumption is that the standard applies to you.
The Department of Justice has referenced WCAG in settlements and rulemaking for years, and courts in many jurisdictions have let website accessibility suits proceed. Florida sits among the most active states for these filings, and Tampa Bay businesses get named regularly. We wrote about the local pattern in our post on accessibility lawsuits hitting Tampa businesses. The short version: serial plaintiffs file in volume, restaurants and e-commerce stores are frequent targets, and “I didn’t know” has never worked as a defense.
None of that is legal advice, but it explains why the standard below deserves your attention even if a letter never arrives. The same fixes also make your site work for more customers.
What does WCAG 2.1 AA actually require?
WCAG organizes every requirement under four principles: content must be perceivable, operable, understandable, and robust. Level AA is the middle tier of strictness and the one courts and regulators reference. Meet the AA criteria across those four families and you are, in practical terms, ADA compliant.
Here is what each family means on a real website.
Perceivable. Everyone must be able to take in your content, whatever senses they use. In practice: every meaningful image needs alt text that says what the image communicates. Videos need captions. Text needs enough contrast against its background to be readable, and WCAG defines the minimum ratio precisely, so free checkers can give you a pass or fail. Information can’t be conveyed by color alone, so an error state that only turns a border red fails. Text has to survive being zoomed way in without breaking the layout.
Operable. Everyone must be able to navigate and use the site. The big one is keyboard access: every link, button, menu, and form control has to work without a mouse, in a logical order, with a visible outline showing where you are. No keyboard traps where focus enters a popup and can’t leave. No content that flashes rapidly. Page titles and link text that make sense out of context, so “read more” repeated nine times fails and “read the accessibility audit checklist” passes.
Understandable. The site must behave predictably and forms must be forgiving. Inputs need visible labels; placeholder text that vanishes when you click doesn’t count as a label. Error messages have to say what went wrong and how to fix it, in text, next to the field. Navigation stays consistent from page to page. The page declares its language in code so screen readers pronounce things correctly.
Robust. The code underneath has to be clean enough for assistive technology to parse. Valid HTML, correct use of ARIA attributes, and custom widgets (dropdowns, carousels, modals) that announce their name, role, and state to a screen reader. This family is where DIY page builders and old themes fail most often, because the visual layer looks fine while the markup underneath is a mess.
Do accessibility overlay widgets make you compliant?
No. An overlay modifies how a page displays after it loads; it cannot repair missing alt text, mislabeled forms, keyboard traps, or broken markup in your source code. Plaintiff firms sue overlay-equipped sites routinely, and some complaints cite the overlay as an additional barrier.
To be fair, overlays do offer a few real display preferences, like a contrast toggle, and some users appreciate those. But the WCAG failures remain in your code, and screen reader users often report that the widgets interfere with the assistive tech they already run. Treat an overlay as a cosmetic add-on at best, never as the answer to a demand letter.
Should you remediate or rebuild?
Remediate when the foundation is sound: on a well-built site, fixing contrast, labels, alt text, focus states, and media is routine, template-level work. Rebuild when the theme or page builder generates violations faster than you can patch them, because paying to fix output that regenerates broken is a treadmill.
A few signals point toward remediation. The site is on a maintained platform, the issues cluster in content (missing alt text, low-contrast brand colors, unlabeled form fields), and automated scans plus a manual pass produce a finite punch list. Most sites we audit land here.
The rebuild signals are different. The theme is abandoned or heavily customized, interactive elements were built without keyboard support at the architectural level, or the markup is so tangled that assistive tech cannot make sense of the page structure. At that point accessibility becomes one more reason on a pile that usually already includes speed and mobile problems, and a rebuild on a clean foundation costs less than serial patching. An honest audit tells you which side you’re on before you spend anything.
How do I check my own site right now?
Run a free automated scanner, then do three manual tests: navigate with only a keyboard, listen with a screen reader, and zoom the page in your browser. Automated tools catch only a minority of WCAG failures, so the manual pass matters as much as the scan.
The routine we’d give a friend:
- Run WAVE (a free browser extension) or Lighthouse (built into Chrome) on your homepage, a product or service page, and your contact form. Fix what they flag.
- Unplug your mouse. Tab through the same pages. Can you reach every menu, button, and field? Can you always see where you are? Can you escape every popup?
- Turn on the screen reader you already own, VoiceOver on a Mac or the free NVDA on Windows, and listen to your homepage. Unlabeled buttons and meaningless link text become obvious within a minute.
- Zoom your browser way in. If content overlaps, disappears, or requires sideways scrolling, that’s a failure.
- Submit your main form with deliberate mistakes and check whether the error messages identify the field and the fix in plain text.
If that punch list looks manageable, work through it. If it looks endless, or you’d rather have a professional pass with documentation behind it, that’s the job our accessibility remediation service exists for: audit against WCAG 2.1 AA, fix the code, retest with real assistive technology, and keep monitoring as the site changes.
Common questions about ADA compliance
Does the ADA apply to small business websites? Size has not shielded defendants in practice. Small local businesses receive demand letters alongside national brands, partly because settlements are faster when the target can’t afford a long defense. Ask your attorney about your specific exposure.
Is there an official ADA compliance certificate? No. No government body certifies websites, so any vendor selling a “compliance certificate” is selling paper. What holds up is documented conformance: an audit against WCAG 2.1 AA, the fixes, and retest records.
Does WCAG 2.2 change anything? WCAG 2.2 adds a small set of criteria on top of 2.1, mostly around focus visibility and form entry. Everything in 2.1 AA still applies, so it remains the right baseline. Adopt the newer criteria as you go.
Will accessibility fixes make my site ugly? Almost never. Most fixes live in code and labels that sighted users never notice, and the visible ones, like stronger contrast and clearer focus states, tend to improve the design for everyone.