Why Florida sees so many website accessibility complaints
Title III of the Americans with Disabilities Act requires places of public accommodation to be accessible to people with disabilities. It was written in 1990, it does not mention websites, and no federal regulation has ever set a technical standard for private business sites. That gap is the entire story. Courts have filled it by defaulting to the Web Content Accessibility Guidelines. Plaintiff-side firms have filled it by filing.
Florida sits in the top three states for these cases year after year, alongside New York and California, and the Southern District of Florida has been among the busiest venues in the country for them. This is not because Florida businesses build worse websites than anyone else. Three things stack up here: an enormous base of small hospitality, medical and retail businesses with public-facing sites, several established plaintiff-side practices with a repeatable process, and law that remains genuinely unsettled.
That last point matters more than it sounds. In Gil v. Winn-Dixie, an Eleventh Circuit panel held that a website is not itself a place of public accommodation — a ruling that would have been very good news for Florida defendants. The court then vacated that opinion as moot before the case could be reheard, leaving the circuit with no controlling precedent at all. Unsettled law encourages volume filing, because a defendant cannot rely on a clean early dismissal and the cost of finding out usually exceeds the cost of settling. The Supreme Court had an opportunity to resolve a related question about tester standing in Acheson Hotels v. Laufer and disposed of the case on mootness instead.
The filing counts also understate the problem, because most of these matters never become filings. They begin, and usually end, as demand letters that nobody tallies.
Who actually gets sued here: the Tampa Bay business profile in these filings
The mental image most owners have is a large retailer with a bad checkout. The reality on the local docket looks nothing like that.
The recurring defendant profile is an independent restaurant with a PDF menu and a third-party online ordering widget. A boutique hotel or short-term rental operator with an embedded booking engine. A dental practice, dermatology clinic or med spa with an appointment request form. A specialty retailer on an off-the-shelf ecommerce theme. A gym with a class schedule loaded from an external system.
What these have in common is not size or industry. It is that the site is under fifty pages, was built on a purchased theme or a page builder, leans on three or four embedded third-party widgets, has no developer currently attached to it, and has never been tested with a keyboard or a screen reader. Being small is not protection. These claims typically originate in automated scanning of large numbers of sites for machine-detectable failures, so the qualifying characteristic is simply that your errors are enumerable — and a twelve-page restaurant site is as scannable as anyone else’s.
What a demand letter looks like and what it typically asks for
It usually arrives by email, sometimes by certified mail, from a law firm rather than an individual. It names a plaintiff, commonly described as a person who is blind or has low vision and uses screen reader software. It states a date on which that person attempted to use your site and could not complete a specific task — reading the menu, booking a room, requesting an appointment.
Then it lists barriers, and this is the part owners find unnerving: the list is specific, references numbered WCAG success criteria, and is frequently accurate.
What it asks for is fairly consistent. Remediation of the site to WCAG 2.1 or 2.2 Level AA within a stated window. Adoption of an accessibility policy and a published statement. Ongoing monitoring, often framed as annual audits for a period of years. And payment — under federal Title III, private plaintiffs cannot recover damages, so the money is attorney’s fees plus a negotiated settlement, commonly reported in the low five figures for small defendants, before the cost of the actual remediation work.
None of this is legal advice, and the first call belongs to a lawyer rather than to your web developer. But the technical track runs in parallel and starts immediately, because in nearly every resolution we have seen, the business ends up fixing the site anyway. The businesses that fare worst are the ones that ignore the letter for six weeks and then try to do a year of work in ten days.
The failures that appear in almost every complaint
The barrier lists are remarkably repetitive, because the same handful of errors are both the most common on the web and the easiest to detect programmatically. WebAIM’s annual analysis of a million home pages consistently finds detectable failures on well over ninety percent of them, concentrated in six categories:
- Images without meaningful alt text, or decorative images that should carry empty alt and instead announce a filename.
- Form fields with no programmatic label, where the placeholder text is doing a job it cannot do for a screen reader.
- Empty links and buttons — icon-only controls with no accessible name, so the user hears link and nothing else.
- Insufficient colour contrast, usually light grey body text or a brand colour used for small text on white.
- Keyboard inaccessibility: dropdown navigation that cannot be opened, modals that trap focus, and focus outlines removed in CSS for visual tidiness.
- Missing document language and broken heading structure, including headings that are styled div elements rather than real heading tags.
Add the industry-specific ones that show up constantly in Tampa Bay filings: menus and price lists published only as PDFs, video with no captions, carousels that auto-advance faster than a person can read, and embedded booking or ordering widgets that are inaccessible in themselves. That last category catches owners off guard. Practically speaking, if the widget is on your page, it is your exposure — ask the vendor for their accessibility conformance report, and if they cannot produce one, plan to replace them.
Why the accessibility overlay you installed may make you a target
An overlay is a single script you paste into your site that promises to make it accessible, usually presenting a small toolbar with font size, contrast and spacing controls. It is the most heavily marketed product in this space, and thousands of Florida businesses bought one after hearing about the lawsuits.
It does not fix your markup. It layers heuristic patches over the existing page at runtime, which means the failures a complaint would enumerate are generally still in your source. Hundreds of accessibility practitioners have signed a public statement against overlays, surveys of screen reader users consistently find many of them switching overlays off because they interfere with the assistive technology already running, and the Federal Trade Commission has taken action against an overlay vendor over claims that its product brought customer sites into compliance.
The part that matters for risk: overlay scripts are trivially detectable in page source, and several plaintiff-side practices scan for them deliberately. A site running one is a site whose owner knew about the obligation, spent money, and remained non-conformant — with the original errors still sitting there to be listed. Businesses running overlays have been sued.
The toolbar itself is harmless enough as a convenience feature. It is simply not a remedy, and treating it as one has left a lot of owners believing they were covered.
WCAG 2.2 AA in practical terms for a small business site
Stripped of the specification language, Level AA on a typical service business site comes down to about ten things:
- Every meaningful image describes its purpose in alt text; decorative images carry empty alt.
- You can tab through the entire site, complete every task, and always see where focus is. Nothing traps you, and the focus indicator is never removed.
- Every form input has a real label element associated with it, errors are described in text rather than colour alone, and required fields are identified.
- Body text meets 4.5:1 contrast; large text and interactive controls meet 3:1.
- Headings are real heading elements in order, one h1 per page, no level skipped.
- Every interactive control has an accessible name, including icon-only buttons.
- Video carries captions, and audio content has a transcript.
- Interactive targets are at least 24 by 24 pixels — a WCAG 2.2 addition that mostly bites on mobile navigation and social icons.
- Anything you can do by dragging can also be done another way, and logins do not require solving a puzzle or recalling something you were not given.
- Help and navigation appear in a consistent place across pages, and information you already entered is not demanded again.
And one that is not in the spec but resolves a large share of restaurant and clinic complaints: publish menus, price lists and intake forms as HTML pages rather than PDFs.
The overlap between accessibility fixes and SEO gains
This is the part worth telling your finance person, because most WCAG failures are markup failures — and markup is what search engines and AI systems read.
Alt text gives image search and language models something to work with. A correct heading hierarchy is how passage-level extraction and featured snippets identify what a section answers. Descriptive link text carries anchor signals that click here and read more discard entirely. Semantic landmarks make a page far cheaper to parse. Captions and transcripts convert video into indexable text. Contrast, tap target size and visible focus are measurable conversion factors on mobile, not just conformance items. And removing a third-party overlay script generally improves your interaction and loading metrics, since it is render-blocking weight doing no useful work.
We run most accessibility remediation through the same process as a technical SEO audit for exactly this reason. The findings overlap by more than half, and the work is done once.
Remediate or rebuild: how to decide, and what each costs
The decision turns on one question: are your failures content-level or structural?
Remediate when the underlying markup is semantically sound, the theme is still maintained, and the barrier list is alt text, labels, contrast, link text and a few keyboard issues. An audit that produces a prioritised, testable findings list is a modest cost; the remediation work on a twenty to sixty page brochure site usually lands in the low thousands. This is the right answer more often than agencies pitching a rebuild will tell you.
Rebuild when the failures are baked in. Page-builder output where headings are styled div elements. Navigation that cannot take keyboard focus without being rewritten. Contrast failures originating in a brand palette applied across every template. A theme no longer receiving updates. Or — the most common case — a site you were already planning to replace within eighteen months, in which case patching it twice is the expensive path. Our custom website design work builds to AA as a specification rather than a retrofit, which costs a fraction of what fixing the same issues after launch does; the broader cost picture is in our piece on what a website redesign should cost.
Whichever route you take, accessibility is a state you maintain rather than one you reach. Every new page, uploaded PDF and added widget can reintroduce a failure, so the testing belongs in your publishing checklist alongside the meta description.
If you want to know where you actually stand, the honest first step is small: tab through your own site with your mouse pushed aside and try to book, order or contact yourself. Most owners find their answer within ninety seconds. If you would like it done properly, get in touch and we will run the audit and send you the findings list either way — it is a considerably better document to hold before a letter arrives than after.
