An inaccessible website can get you sued.
· 7 minute read
Yes, an inaccessible website can lead to a lawsuit. It can also stop a customer before they ever reach the part where they give you money.
The second problem usually arrives first. A visitor cannot read the text, reach the menu with a keyboard, understand an image, complete a form, hear a video, or tell where the current focus is. The website is open. The website is also closed to them.
The legal risk is real, but fear is a poor maintenance plan. A better plan is to make the site usable, test it, fix what fails, and keep doing that when the site changes.
What the law says.
Title III of the Americans with Disabilities Act requires businesses that are open to the public to provide people with disabilities full and equal access to their goods and services. The U.S. Department of Justice has long taken the position that this includes goods and services offered through a website. Its web accessibility guidance names common barriers and tells businesses to make online offerings accessible.
The exact legal analysis can change with the kind of business, the website's connection to a physical location, the state, and the federal court hearing the case. That is one reason an internet argument that begins with “the ADA always” or “the ADA never” tends to age badly. Your lawyer gets the final word on your situation.
What a lawsuit can ask for.
A private plaintiff can bring a Title III case seeking a court order to correct the barrier. Federal law also lets a court award reasonable attorney fees to a prevailing party. The Department of Justice can bring its own enforcement action in qualifying cases and may seek broader relief, including damages for affected people and civil penalties. State and local laws can create additional claims or monetary remedies.
In plain language: even when the federal claim is mainly about fixing the site, the process can still involve lawyers, deadlines, outside audits, settlement terms, and a repair project happening on somebody else's schedule. The relevant federal enforcement provisions are in 42 U.S.C. § 12188.
What inaccessible looks like.
Accessibility failures are usually ordinary website decisions with consequences. The button was built as a clickable box instead of a button. The designer removed the focus outline because it looked untidy. The form error turns red but never explains itself. The product image has no text alternative. The menu only opens with a mouse.
- Text has too little contrast or breaks when enlarged.
- Navigation, dialogs, and forms cannot be used from a keyboard.
- Images that carry information have missing or useless alternative text.
- Video has no captions and audio has no transcript.
- Headings are selected for size instead of structure.
- Form labels, instructions, errors, or status messages are missing.
- Motion cannot be paused or makes the content difficult to use.
None of these requires a dramatic redesign. Most require somebody to notice, understand the reason, and repair the underlying page.
WCAG is the working map.
The Department of Justice does not currently publish a detailed technical regulation for private business websites. It points businesses toward established standards, including the Web Content Accessibility Guidelines. WCAG turns broad accessibility goals into testable criteria for the content and code.
The World Wide Web Consortium encourages teams to use the latest version, WCAG 2.2. Many organizations use Level AA as a practical target. That is a useful engineering decision, not a promise that a checklist creates immunity from every claim. Legal requirements and contract terms still need their own review.
The menu helps. The page still has to work.
There is an accessibility menu at the bottom of this screen. Try it. It lets a visitor adjust text size and spacing, increase contrast, highlight links and headings, pause motion, hide images, use a larger cursor, and turn on a reading guide. We built it, and we can implement it on your site.
The menu is one useful layer. It is not a legal force field. It cannot invent a missing form label, repair a broken heading structure, add captions nobody wrote, or make a mouse-only checkout work from a keyboard. Those repairs belong in the website itself. The controls give visitors choices. Accessible code gives those choices somewhere solid to land.
A serious accessibility pass includes people.
Automated scanners are good at finding some failures quickly. They do not understand every interaction, every alternative description, or whether a page makes sense when read in a different order. The Department of Justice warns that a clean automated report does not necessarily mean a website is accessible. W3C says the same thing more directly: no tool alone can determine accessibility.
A useful review combines several kinds of work:
- Automated checks across representative pages and templates.
- Keyboard testing for every control and interaction.
- Screen reader checks for structure, names, instructions, and updates.
- Zoom, contrast, reduced-motion, and small-screen testing.
- Manual review of images, captions, forms, documents, and error states.
- Testing with people with disabilities when the scope allows it.
Fix it before the demand letter.
Start with the tasks that can block a person completely: navigation, purchasing, booking, account access, forms, documents, and contact information. Repair the shared templates and components so the same mistake does not reappear on forty pages. Keep a record of what was tested, what was fixed, and what remains. Then include accessibility in every future content and design change.
The goal is not a scanner score with a nice green circle. The goal is a website a person can use. The reduced legal risk is useful. So is not turning away customers for reasons the code can fix.