ADA Website Compliance for Small Business: What Your Site Needs Before a Demand Letter Arrives

ADA website compliance for small business is no longer optional. Learn the WCAG basics, what demand letters target, and how to fix your site before one arrives.

ADA Website Compliance for Small Business: What Your Site Needs Before a Demand Letter Arrives

A business owner opens the mail and finds a letter from a law firm they have never heard of. The letter claims their website violates the Americans with Disabilities Act. It names specific pages. It quotes specific standards. And it demands a settlement — often between $3,000 and $10,000 — to make the complaint go away.

This is not hypothetical. ADA demand letters targeting small business websites have surged year over year since 2018, and the trend is accelerating. Plaintiffs' firms use automated scanning tools to identify sites with accessibility gaps, then send letters in volume. The targets are rarely large enterprises with legal teams on retainer. They are local shops, service providers, solo founders, and small organizations — businesses that built a website, checked it off the list, and moved on.

The good news: the fixes that prevent these letters are not mysterious or expensive. They are foundational. And if you address them before someone else finds them for you, your site becomes more usable for everyone — which is the actual point.

Why Small Business Websites Are the Target

Large companies have been dealing with digital accessibility litigation for years. Most have dedicated compliance programs. That makes them harder targets. A small business, on the other hand, typically has a website built on a template, maintained infrequently, and never audited for accessibility. The gaps are predictable, well-documented, and easy for automated tools to flag at scale.

Plaintiffs' firms do not need to manually browse your site. They run crawlers that check for missing alt text, insufficient color contrast, form fields without labels, and other machine-detectable violations. When the crawler returns results, the letter follows. The legal theory is straightforward: under Title III of the ADA, a business that serves the public must make its services accessible to people with disabilities. Courts have increasingly interpreted websites as places of public accommodation, and the Department of Justice has issued guidance reinforcing that interpretation.

There is no specific dollar-amount revenue threshold that exempts you. If your website is a channel through which customers interact with your business, it falls within scope.

WCAG: The Standard Behind the Letters

The demand letters almost always reference the Web Content Accessibility Guidelines, or WCAG. These are international standards published by the World Wide Web Consortium (W3C) that define what it means for web content to be accessible. The current benchmark that courts and the DOJ reference is WCAG 2.1 Level AA.

WCAG is organized around four principles, sometimes abbreviated as POUR:

Perceivable

Information must be presentable in ways users can perceive. A visitor who cannot see an image needs a text alternative. A visitor who cannot hear audio needs captions. Content cannot rely on a single sensory channel alone.

Operable

Interface components must be operable through multiple input methods. Every function reachable by mouse must also be reachable by keyboard. Navigation must be predictable. Users must have enough time to read and interact with content.

Understandable

Text must be readable. The interface must behave in predictable ways. Forms should help users avoid and correct mistakes — clear labels, descriptive error messages, logical tab order.

Robust

Content must be robust enough to be interpreted by a wide variety of user agents, including assistive technologies like screen readers. This means clean, valid HTML and proper use of ARIA (Accessible Rich Internet Applications) attributes where needed.

Understanding these four principles matters more than memorizing individual success criteria. When you evaluate your own site, every question boils down to: can someone with a visual, auditory, motor, or cognitive disability actually use this?

A Practical Website Accessibility Checklist

This is not exhaustive — a full WCAG 2.1 AA audit covers dozens of success criteria — but these are the issues that automated scanners flag most often and that demand letters cite most frequently. Addressing them eliminates the low-hanging fruit that makes a site a target.

Images and Media

  • Alt text on every image. Every img element needs an alt attribute. Decorative images should use an empty alt attribute (alt='') so screen readers skip them. Meaningful images need descriptive text that conveys what the image communicates, not just what it shows.
  • Captions on video. Any video with spoken content needs synchronized captions. Auto-generated captions are a starting point, but they require review — accuracy matters.
  • No information conveyed by color alone. If a form field turns red to indicate an error, there must also be a text label or icon communicating the same thing.
  • Full keyboard operability. Tab through your entire site using only a keyboard. Can you reach every link, button, and form field? Can you see where the focus is? If the focus indicator is invisible (a common problem with CSS resets), fix it.
  • Logical tab order. Focus should move through the page in a sequence that makes sense. If your tab order jumps from the header to the footer and back to the sidebar, the underlying HTML structure needs work.
  • Skip navigation link. A hidden link at the top of each page that lets keyboard users skip past the main navigation and go directly to content. Most screen reader users expect it.
  • No keyboard traps. If a modal, dropdown, or embedded widget captures keyboard focus and offers no way to escape, that is a trap. Users must be able to close or dismiss any component with the keyboard.

Forms and Interactive Elements

  • Every form field has a label. Placeholder text inside an input field is not a label. Placeholders disappear when the user starts typing, leaving no context. Use a visible label element associated with each field.
  • Error messages are specific and adjacent. Telling a user "There was an error" is not helpful. Telling them "Email address is required" next to the email field is.
  • Buttons are buttons, links are links. A div or span styled to look like a button but lacking the proper element or ARIA role is invisible to assistive technology. Use semantic HTML.

Typography and Color

  • Minimum color contrast ratio of 4.5:1 for body text. This is a WCAG AA requirement. Light gray text on a white background may look elegant, but it fails. Free tools like the WebAIM Contrast Checker can verify any color pair in seconds.
  • Text can be resized up to 200% without breaking the layout. If zooming in on your site causes content to overlap, disappear, or require horizontal scrolling, the CSS needs adjustment.

Document Structure

  • Proper heading hierarchy. Screen readers use headings to navigate page structure. Headings should follow a logical order — H1 first, then H2s for major sections, H3s for subsections. Skipping levels or using heading tags purely for visual styling creates confusion.
  • Language attribute set on the HTML element. The lang attribute tells screen readers which language to use for pronunciation. A missing or incorrect language attribute is a common automated-scan finding.
  • Meaningful link text. Links that say "click here" or "read more" tell a screen reader user nothing about the destination. Each link should make sense out of context.

The Overlay Widget Trap

If you have researched ADA website compliance for small business, you have almost certainly encountered accessibility overlay products — widgets that promise to make your site compliant by adding a single line of JavaScript. These tools add toolbar buttons that let users adjust font size, contrast, and spacing.

Here is the uncomfortable truth: overlays do not make a site compliant. They address surface-level presentation issues while leaving the underlying structural problems untouched. A missing form label is still missing. A keyboard trap is still trapping. An image without alt text still has no alt text. The overlay cannot write your alt text for you — it does not know what the image means.

Worse, several high-profile lawsuits have specifically named sites that use overlays. Some accessibility advocacy organizations have published open letters opposing them. Installing an overlay can actually increase your legal exposure by creating a record that you were aware of accessibility obligations but chose a shortcut over substantive remediation.

There are no shortcuts here. The soil work — fixing the actual HTML, CSS, and content structure — is what creates a genuinely accessible site. An overlay is paint on rotten wood.

How to Assess Where You Stand Right Now

You do not need to hire an auditor to get a baseline reading. Start with these steps:

  1. Run an automated scan. Tools like WAVE (from WebAIM), Google Lighthouse (built into Chrome DevTools), and axe DevTools can identify machine-detectable issues in minutes. They will not catch everything — automated tools typically find only 30-40% of WCAG violations — but they surface the most common and most cited problems.
  2. Do a manual keyboard test. Put your mouse in a drawer. Navigate your entire site using only Tab, Shift+Tab, Enter, and Escape. Note everywhere you get stuck, lose your place, or cannot interact with an element.
  3. Test with a screen reader. VoiceOver is built into every Mac. NVDA is free for Windows. Turn one on and listen to your site. You will learn more in fifteen minutes than any report can tell you.
  4. Check your forms. Submit every form on your site with deliberate errors — empty required fields, invalid email formats. Are the error messages clear? Are they associated with the right fields? Can a keyboard user reach and correct them?

Document what you find. Prioritize by severity: issues that prevent someone from completing a core task (making a purchase, submitting a contact form, accessing essential information) come first. Issues that cause confusion but do not block functionality come second. Cosmetic or edge-case issues come third.

It is tempting to frame all of this as risk mitigation — and it is that. But reducing accessibility to a compliance checkbox misses something important.

An accessible website is a more usable website for everyone. Clear labels help all users, not just screen reader users. Sufficient color contrast is easier to read in direct sunlight. Keyboard navigation benefits anyone with a broken trackpad, a temporary injury, or a preference for efficiency. Good heading structure helps search engines understand your content, which means the same fixes that prevent a demand letter can also improve your search rankings.

When we think about brand identity at FigTree, we think about what a brand communicates through every touchpoint — not just the logo and the messaging, but the actual experience of interacting with the business. A website that excludes visitors is communicating something, whether the owner intended it or not. Building accessibility into the foundation is not separate from brand work. It is part of it.

What to Do If a Letter Has Already Arrived

If you have already received a demand letter, do not ignore it and do not panic. A few grounded steps:

  • Consult an attorney experienced in ADA digital accessibility cases. This is a specialized area. A general business attorney may not know the current landscape.
  • Begin remediation immediately and document it. Courts look favorably on businesses that demonstrate good faith effort toward compliance. Timestamp your work.
  • Do not rely on an overlay as your response. As noted above, it can make the situation worse.
  • Develop an accessibility statement and publish it on your site. This statement should describe your commitment, the standard you are working toward (WCAG 2.1 AA), and a way for users to report barriers they encounter.

The strongest legal position is one where you have already done the foundational work. That is always cheaper than responding after the fact.

Related service: Marketing and brand growth services in Tampa Bay — what we build, how we work, and what it costs.

Build the Foundation Before Someone Tests It

Accessibility is not a feature you bolt on. It is a quality of how your site is built — the semantic structure, the content strategy, the design system. When those foundations are right, compliance follows naturally. When they are not, every fix is a patch on top of a deeper problem.

This is the kind of foundational brand and web work we do at FigTree Development. We are a Florida-licensed firm based in the Tampa Bay area, and we work with local and remote clients to build brands and digital presences that are grounded, usable, and designed to last. Not because a law firm might come knocking, but because good work serves everyone who encounters it.

If you are unsure whether your website meets WCAG basics, or if you want to integrate accessibility into a broader brand and content strategy, we would welcome the conversation. Book a free 20-minute discovery call and let us look at where your site stands today — and what it would take to build a foundation that holds.

Ready to Build?

Let's Plant Something Real.

Every project starts with a free 20-minute discovery call — no pitch, just a real conversation about what you're building and where the friction is.

Book a Discovery Call → ← Back to Blog
Start a Project →