What website ADA compliance actually means
The Americans with Disabilities Act is a civil rights law. Title III applies to "places of public accommodation" — the businesses ordinary people use every day. Courts and the Department of Justice have generally treated the websites of those businesses as an extension of the business itself. So when people talk about website ADA compliance, they mean this: can a person with a disability actually use your site to do what your other customers do?
Concretely, that covers a few groups. A blind visitor using a screen reader needs your images to have text descriptions and your buttons to announce what they do. A person who can't use a mouse needs to reach every menu, form field, and link using only the keyboard. A low-vision visitor needs enough color contrast to read your text. A deaf visitor needs captions on your videos. None of this is exotic. It's the difference between a customer who can request a quote and one who hits a wall and leaves.
The measuring stick almost everyone uses is the Web Content Accessibility Guidelines (WCAG) 2.1, Level AA. It's a set of testable success criteria published by the World Wide Web Consortium, the international body that sets web standards. The ADA statute itself doesn't name WCAG for private businesses. But plaintiffs' attorneys, courts, and the settlement agreements that resolve most of these disputes all point to WCAG 2.1 AA as the working definition of "accessible." WCAG 2.2 AA is the newer version, published in 2023, and it's the safer target if you're building fresh — it folds in everything from 2.1 plus a handful of newer criteria. If your Hillsville storefront, your Roanoke restaurant, or your Richmond service business has a website, this is the bar to aim for.
One clarification worth making early: accessibility is not a look. A site can be plain or polished and still be accessible or not. It's about how the site is built underneath — the HTML, the labels, the keyboard behavior — not whether it has a fancy design. That's why you can't eyeball compliance, and why a good-looking site built by someone who never thought about screen readers can fail badly.
There is no small-business exemption
This is the single most common misunderstanding, so it's worth stating plainly. The famous "15 or more employees" threshold belongs to Title I of the ADA, which governs employment. Website accessibility for businesses open to the public falls under Title III — and Title III has no employee minimum and no revenue floor.
A two-person plumbing outfit in Wytheville is covered on the same terms as a national chain. And small businesses are frequent targets, not rare ones. The reason is simple: a small business site is the least likely to have been fixed, which makes it the easiest to file against. You don't have to be big to be worth a demand letter — you just have to have a website with barriers on it.
The way this typically plays out is not a government inspector knocking on your door. It's a demand letter or a filed complaint from a plaintiff — or the law firm that recruited them — who visited your site, hit a barrier, and now seeks a settlement plus attorney's fees. These cases usually settle rather than go to trial, because fighting one costs more than resolving it, and you generally end up paying for the remediation you'd have needed anyway on top of the legal bill.
A related trend worth knowing: filings by individuals representing themselves, without an attorney, have grown, and it's now easier than ever to generate a complaint template. The practical takeaway is that "we're too small to be noticed" is not a plan. What protects you is the state of your site, not the size of your company.
To be clear about what we're not saying: this is not a reason to panic or to buy the first thing a salesperson pitches you. The businesses that get hurt here are usually the ones who did nothing, then bought a shortcut after a letter arrived. The businesses that are fine are the ones whose sites were built right in the first place. That's the whole game.
Title II vs. Title III — which one applies to you
There's real regulatory news in this area, and it's easy to misread, so here's the clean version. In April 2024 the Department of Justice finalized a rule that formally requires state and local governments to meet WCAG 2.1 AA on their websites and mobile apps. That rule sits under Title II of the ADA, which covers public entities. The compliance deadlines run by size: larger public entities, meaning those serving populations of 50,000 or more, generally have until April 2026, and smaller entities and special districts have until April 2027.
Here's the part that trips people up. That rule is for governments — a Virginia county, a town, a public school district, a water authority. It is not a private-business rule. If you run a private company, the DOJ has not issued a formal technical regulation that names a specific WCAG version and a deadline for you.
Do not read that as a loophole. Your obligation under Title III to be accessible already exists and is actively enforced through litigation — it simply hasn't been reduced to a single numbered regulation with a date for private sites. In practice, everyone building or defending a private site treats WCAG 2.1 AA as the standard anyway, because that's what courts and settlements use. So whether you're a Virginia municipality working toward a hard deadline or a private business with no formal one, the technical target is effectively the same. The difference is only how the obligation reaches you: a regulation with a date, or a lawsuit without one.
Why spell this out? Because a lot of the marketing around accessibility leans on the 2024 government rule to scare private business owners into thinking a specific deadline applies to them. It doesn't. Your reason to act isn't a deadline — it's that the underlying duty is already live and already enforced. The date is a distraction. The duty is the point.
Why accessibility overlay widgets don't fix it
If you've searched for a solution, you've seen the pitch: paste one line of JavaScript, get an "accessibility" button in the corner of your site, and you're compliant. These tools are called overlays. They do not make you compliant, and buying one can leave you worse off than doing nothing.
The problem is structural. An overlay is a script that tries to detect and patch accessibility problems on top of a site it didn't build. It can't reliably write meaningful alt text for your photos, fix a form that traps a keyboard user, or repair a broken heading structure — those live in the underlying code and content, which the widget can only guess at. Screen-reader users, the people this is supposedly for, have publicly and repeatedly reported that overlays interfere with the assistive technology they already rely on.
The legal reality caught up with the marketing when the Federal Trade Commission announced action against a leading overlay vendor for misrepresenting its widget as delivering ADA compliance, with a monetary penalty in the millions. The lesson from that case isn't just "that one vendor got caught" — it's that "install this and you're compliant" was never true, and a federal regulator said so on the record.
Overlays also don't stop lawsuits. Sites running a well-known widget have still been sued, and the widget in the corner can actually flag a site as a target, because its presence signals an owner who bought a shortcut instead of fixing the underlying problems. You're advertising the gap, not closing it.
The only durable fix is to build accessibility into the site's actual code and content: real semantic HTML, keyboard-operable menus, genuine alt text, sufficient contrast, labeled form fields. That's a core part of how we approach web design — accessibility handled in the build, not bolted on after. It takes more work up front than a widget subscription, and it's the only version that actually holds up.
The barriers that get Virginia sites sued
You don't need to memorize every WCAG criterion to close most of your risk. A short list of issues shows up in the large majority of complaints. Walk your own site against these:
- Missing alt text on images. Every meaningful photo, logo, and graphic needs a text description a screen reader can announce. Decorative images should be marked so assistive tech skips them instead of reading a filename aloud.
- Unlabeled form fields. Your contact form, quote request, and search box each need programmatic labels — not just gray placeholder text that disappears the moment someone starts typing.
- Keyboard traps and unreachable controls. Try navigating your whole site with only the Tab and Enter keys. If you can't reach the phone number, open the menu, or trigger the "Request an Estimate" button, neither can many disabled visitors.
- Low color contrast. Light-gray text on white, or white text laid over a pale photo, fails the contrast requirement. As a rule of thumb, normal body text needs a 4.5:1 ratio against its background.
- No captions on video. A background hero video with speech, or an embedded testimonial, needs captions so deaf and hard-of-hearing visitors get the same information.
- Poor heading structure and vague link text. "Click here" links and pages with no logical heading order make a screen reader nearly useless, because those are the tools blind users navigate with.
Free tools like WAVE or Google's built-in Lighthouse audit will surface a chunk of these automatically, and running one on your homepage is a reasonable first move. But automated scanners only catch part of the picture — they can tell you an image has no alt text, but not whether the alt text you wrote is actually useful, and they can't judge whether your keyboard order makes sense. Those require a person. If you're not sure where you stand, our web design work includes auditing an existing site against WCAG 2.1 AA, by hand and not just with a scanner.
How to actually get compliant — and stay there
Compliance isn't a certificate you earn once and frame on the wall. Content changes, someone adds a new page, a plugin updates, and gaps reopen. Treat it as an ongoing process with a few clear steps.
Start with an honest audit. Combine an automated scan with real manual testing — keyboard-only navigation, and ideally a pass with an actual screen reader. That gives you your true starting position instead of a scanner's partial one, and it tells you which problems are cosmetic and which ones actually block a customer.
Fix the code, not the symptoms. Remediate at the source: correct the HTML, label the forms, add real alt text, and fix contrast in the design system so it holds across every page instead of one at a time. This is where a rebuild sometimes beats patching. An old template built with no thought to accessibility can cost more to retrofit than to replace, especially if the underlying structure is the problem.
Write an accessibility statement. A short page describing your commitment and giving visitors a clear way to report a barrier is good faith you can point to. It is not a legal shield, and no one should sell it to you as one, but it's genuinely useful and it's cheap to do.
Build it into new content. Whoever adds pages, photos, or PDFs needs a simple habit: alt text on images, headings in order, captions on video. Scanned PDFs are a common blind spot — a photo of a document is invisible to a screen reader, so a menu or price list saved that way isn't accessible no matter how the rest of the site is built.
Recheck on a schedule. Re-audit after any major redesign, and at least once a year otherwise. Sites drift as they grow, and a page that was fine last year may not be after a season of updates.
On cost: honest accessibility work is priced by scope, not by a flat sticker. Auditing and fixing a small brochure site is a very different job from remediating a large site full of forms and video, so we quote it in a written proposal after we've seen your site rather than throwing out a number that doesn't mean anything. If you'd rather have this handled properly from the ground up than duct-taped after a demand letter arrives, that's the kind of build we do at Webb Flow — get started here and we'll tell you honestly where your site stands.