A demand letter about your website usually shows up without warning. It is a few paragraphs from a law firm, it names a real person who could not use your site with a screen reader or a keyboard, and it cites the Americans with Disabilities Act. Most business owners have never heard the phrase “web accessibility” before that letter lands. By then the question is not whether your site has problems. It is how many, and how much they will cost to fix under a deadline.

This is a diagnostic, not a scare piece. Below is what actually triggers these claims, the specific failures that show up again and again, and a checklist you can run on your own site in about thirty minutes. At the end you get a straight read on whether this is a fix-it-yourself afternoon or a job for someone who does remediation for a living.

Why a website can land you in ADA territory at all

The Americans with Disabilities Act became law in 1990, long before most businesses had a website. Title III of the ADA prohibits discrimination in “places of public accommodation,” which the statute lists as things like stores, restaurants, offices, and service providers. The fight over websites is about whether that phrase reaches online storefronts and booking pages.

Courts have not landed on one national answer, and the rules differ by federal circuit. But a large share of courts have treated a public-facing commercial website as either a place of public accommodation itself or as a service tied to a physical one. In practice, that split does not help a small business much. A plaintiff can file where the law is favorable, and the cost of fighting the jurisdiction question often exceeds the cost of just fixing the site. That is why most of these matters settle.

The federal government has weighed in without ending the ambiguity. The Department of Justice has said for years that the ADA applies to the websites of public accommodations, and in March 2022 it published web accessibility guidance restating that position. In 2024 the DOJ issued a rule setting WCAG 2.1 Level AA as the technical standard for state and local government websites under Title II. That rule targets government, not private business, but it matters here because it puts a specific version of WCAG into federal regulation, which reinforces WCAG as the benchmark everyone else is measured against.

The standard nobody officially set: WCAG 2.1 and 2.2 AA

Here is the gap that traps people. There is no federal regulation that tells a private business exactly what an accessible website must do. So how does a plaintiff prove your site is inaccessible, and how does a settlement define “fixed”? Almost always by pointing to the Web Content Accessibility Guidelines, or WCAG, published by the World Wide Web Consortium (W3C).

WCAG comes in versions. WCAG 2.0 was published in 2008, WCAG 2.1 in June 2018, and WCAG 2.2 in October 2023. Each has three conformance levels: A, AA, and AAA. Level AA is the one that shows up in demand letters, consent decrees, and the DOJ’s own rule. When a settlement requires a company to “conform to WCAG 2.1 AA within twelve months,” that is the target being set.

WCAG is built on four principles, often shortened to POUR: content must be Perceivable, Operable, Understandable, and Robust. You do not need to memorize the guidelines to reduce your risk. You need to understand the handful of AA failures that generate the overwhelming majority of complaints, because that is where automated scanners and human testers look first.

The failures that actually trigger complaints

Accessibility has hundreds of individual checkpoints, but claims cluster around a short list. If your site has several of these, it is the kind of site that gets flagged.

Missing or useless alt text on images

Screen readers announce images using their alt attribute. If a product photo, an infographic, or a “Buy Now” image button has no alt text, a blind user hears nothing useful, or hears a file name like “IMG_4821.jpg.” Decorative images should have empty alt text so they are skipped. Meaningful images need a short description of what they show or do. This is one of the first things a scanner catches.

Low color contrast

Light gray text on a white background looks clean in a mockup and fails WCAG for anyone with low vision. AA requires a contrast ratio of at least 4.5 to 1 for normal text and 3 to 1 for large text. This is one of the most common failures on the web because it hides inside brand palettes and theme defaults that were chosen for looks, not legibility.

Keyboard traps and keyboard-only breakage

Many people cannot use a mouse and navigate entirely with the Tab key. A keyboard trap is a spot where focus enters an element, often a menu, a modal, or an embedded widget, and cannot get back out with the keyboard. The user is stuck. Related failures include navigation menus, sliders, and pop-ups that a mouse can operate but a keyboard cannot reach at all.

Unlabeled forms and controls

A contact form or checkout is where a business loses the most from an inaccessible site, and it is where forms fail hardest. If an input has no programmatic label, a screen reader announces “edit text, blank” and the user has no idea what to type. Placeholder text is not a label. Error messages that appear only as red borders, with no text a screen reader can announce, are a related and frequent problem.

Inaccessible PDFs

Menus, price lists, forms, and reports posted as PDFs are often just scanned images or untagged documents with no reading order. To a screen reader they can be a blank page. PDFs are easy to overlook because they feel separate from the website, but a linked PDF is part of the experience a plaintiff can test.

No visible focus indicator

When you Tab through a page, the element you are on should show a visible outline or highlight so a sighted keyboard user knows where they are. A common “cleanup” in custom CSS is to remove that outline because a designer found it ugly. Removing it without a replacement is a direct WCAG failure and makes keyboard navigation nearly unusable.

Other patterns worth knowing

Video without captions, content that only conveys meaning through color, images of text instead of real text, and pages that break when zoomed to 200 percent all show up in complaints. If the six above are clean, these are the next places to look.

Run the 30-minute self-diagnostic

You can get a real sense of your exposure without buying anything. Work through your highest-traffic pages first: home, a main service or product page, your contact form, and your checkout if you have one. Score each item honestly.

1. The keyboard-only test (10 minutes)

Put your mouse aside. Use only Tab, Shift+Tab, Enter, and the arrow keys. Try to reach every link, button, menu, and form field. Then answer:

• Can you see where focus is at every step, or does the highlight disappear?
• Can you open and, more importantly, close every menu and pop-up without a mouse?
• Can you complete the contact form and submit it end to end?
• Did focus ever get stuck somewhere you could not Tab out of?

If you got stuck, lost track of focus, or could not finish the form, a keyboard user cannot use that page. That is a high-severity finding.

2. The contrast check (5 minutes)

Use a free tool like the WebAIM Contrast Checker or your browser’s built-in accessibility panel. Sample your body text, link text, button labels, and any text over a photo or gradient. Anything below 4.5 to 1 for normal text fails AA. Faded gray captions and pale placeholder text are the usual offenders.

3. The image and form scan (10 minutes)

Run a free automated checker such as WAVE (from WebAIM) on each key page. It flags missing alt text, empty links and buttons, unlabeled form fields, and contrast problems in seconds. Automated tools catch roughly a third of issues, so treat a clean scan as necessary, not sufficient. A page full of red icons, though, is a clear signal.

4. The PDF and media pass (5 minutes)

List every PDF you link to and every video you host. For each PDF, can you select and copy the text, or is it a flat image? For each video, are there real captions, not just auto-generated ones you have never checked? Uncaptioned video and image-only PDFs are common findings.

Read your score

Tally the pages where you hit a wall. If one or more of your money pages failed the keyboard test or the form test, or your scanner lit up with dozens of errors, your site is in the risk zone that demand letters target. If everything passed and the scanner was mostly clean, you are in reasonable shape and should keep it that way as the site changes.

Fix it yourself, or get help?

Not every finding needs a developer. The honest split looks like this.

Reasonable to handle in-house

• Adding or correcting alt text on images through your CMS.
• Writing real text labels for form fields and captions for a handful of videos.
• Nudging a few brand colors to hit the contrast ratio.
• Replacing an image-of-text banner with real, styled text.

These are content-level edits. If you or someone on your team is comfortable in WordPress and willing to work through a list, you can close a lot of the easy findings.

Usually worth bringing in help

• Keyboard traps and focus problems that live in the theme or a plugin, not in your content.
• A theme where the focus outline was stripped site-wide and has to be rebuilt correctly.
• Custom menus, sliders, modals, and third-party widgets that fail on keyboard and screen reader.
• A pile of PDFs that need to be remediated or rebuilt as accessible pages.
• Any situation where a demand letter has already arrived and there is a deadline attached.

These are structural. Patching them blind can break layout or introduce new failures, and a scanner will not tell you whether a screen reader can actually complete a task. This is where a developer who builds to WCAG earns the fee, because the goal is not a clean scan report. It is a site a real person using assistive technology can actually use.

A note on accessibility overlay widgets

You will see plug-in “overlay” or “accessibility widget” products that promise instant compliance for a monthly fee. Accessibility advocates and many plaintiffs’ firms are openly skeptical of them, and sites using overlays have still received demand letters. Treat an overlay as a convenience feature at best, not as a substitute for fixing the underlying code and content.

What to do this week

Run the 30-minute diagnostic on your top four pages and write down what failed. Fix the alt text, labels, and contrast you can handle now, because those reduce real risk and are simple wins. For anything structural, the theme, the forms, the PDFs, or a letter already in hand, get a proper WCAG review before you guess at repairs. The worst position is the one most businesses are in right now: no idea whether the site would survive a test, and no plan for the day someone runs one.

Sources

• U.S. Department of Justice, “Guidance on Web Accessibility and the ADA” (March 2022)
• ADA Title III regulations, U.S. Department of Justice (ada.gov)
• Web Content Accessibility Guidelines (WCAG) 2.1, W3C (June 2018)
• Web Content Accessibility Guidelines (WCAG) 2.2, W3C (October 2023)
• WebAIM Contrast Checker and WAVE Web Accessibility Evaluation Tool