Skip to content

Can I Get Sued if My App Isn't Accessible? (ADA and WCAG for Beta)

6 min read

Short answer: yes, an inaccessible app can get you a legal demand, and small startups are targeted more often than you would expect. In the US, courts treat many websites and apps as "places of public accommodation" under the ADA, and the practical standard everyone points to is WCAG 2.1 level AA. You do not need to be perfect for beta. You do need to clear a baseline so you are not the easy target.

Why this happens

Accessibility lawsuits are not usually about a specific victim who tried your app. There is a steady industry of firms that scan thousands of sites with automated tools, find the same handful of failures, and send demand letters. The failures they find are the ones an AI agent leaves behind by default: images with no alt text, form inputs with no labels, buttons that are actually <div>s, and colour combinations no one can read.

Your agent built exactly what you asked. You asked for "a sign-up form," so it made a form that looks right on your screen. You did not ask for "a form a blind user can complete with a screen reader," so it did not add the labels and roles that make that possible. Nothing looked broken in the demo, because you were using a mouse and could see.

How to check

You can get a rough read in about ten minutes.

  1. Run an automated scan. Open your app in Chrome, open DevTools, go to the Lighthouse tab, tick Accessibility, and run it. Or install the free axe DevTools extension and click "Scan." A score under about 90, or a list of "serious" and "critical" items, means you have the common problems.
  2. Try it with only the keyboard. Put your mouse down. Press Tab repeatedly through your main flow: can you reach every button and field, and can you see which element is focused? If the focus outline is invisible or Tab skips your buttons, that is a real failure.
  3. Turn on the screen reader. VoiceOver (Cmd+F5 on Mac) or NVDA (free on Windows). Try to complete sign-up with your eyes closed. If fields are read as "edit text" with no name, they are unlabelled.

Automated scans catch roughly a third to a half of issues. The keyboard and screen-reader passes catch the rest.

The fix

You do not need level AAA or an audit for beta. Aim for WCAG 2.1 AA on your core flows and knock out the common wins first.

  1. Add alt text to every meaningful image, and empty alt="" on decorative ones so screen readers skip them.
  2. Label every form field. A visible <label> tied to its input by for and id, or at minimum an aria-label. "Placeholder text" is not a label.
  3. Use real buttons and links. <button> for actions, <a href> for navigation. If your agent gave you clickable <div>s, they are invisible to keyboards and screen readers.
  4. Fix colour contrast. Body text needs a 4.5:1 ratio against its background. Paste your colours into any "contrast checker" and adjust the greys that fail.
  5. Make focus visible. Do not remove the focus outline in CSS. If your theme hid it, add a clear :focus-visible style back.
  6. Set the page language and a real page title (<html lang="en">), and make sure headings go in order (one <h1>, then <h2>s under it).

Re-run Lighthouse after each pass and confirm the count drops.

The trap to avoid

Do not install an "accessibility overlay" widget, the floating icon that promises instant ADA compliance. They do not fix the underlying HTML, they are widely regarded as ineffective, and a large share of accessibility lawsuits now name sites that were using an overlay. It buys a false sense of safety while the real failures sit untouched underneath. Fix the markup instead.

Where this fits

Accessibility is one of those things that is invisible in your own demo and obvious to a scanning bot, exactly the gap that turns into a demand letter after launch. The free Readiness Report runs these checks against your real app and tells you which pages fail and why, in plain language. If you want the fixes handed to you in order rather than hunting them yourself, that is what the Finishing Pass is for. It sits alongside the other paperwork you need before real users arrive, like whether you need a privacy policy for a beta app and whether GDPR applies to your small app.