Skip to content

Does an app you built with AI need to be ADA accessible?

AI app builders and coding assistants ship fast but skip accessibility by default. What the law actually requires from a weekend project, and how to check it without rewriting the app.

· Rampa

You built an app in a weekend with an AI coding tool, shipped it, and a handful of people signed up. Then you see a post about a small app getting a demand letter over accessibility, or a client asks if your product is “ADA compliant,” and you realize you have no idea. The honest answer is that it can apply to you, and the reason has nothing to do with how the app got built.

The law does not care who wrote the code

The ADA (Americans with Disabilities Act, the 1990 US law against disability discrimination) does not mention websites, apps, AI, or code editors. Since 2017, federal courts have applied it to any website or app open to the public, no matter the size of the team behind it or the tool used to build it. More than 4,000 web accessibility lawsuits are filed in the US every year, and small, one- or two-person products are an increasingly common target, because those cases settle fast. If your product also sells into the European Union, the European Accessibility Act (EAA), in force since June 2025, asks for the same thing under a different name.

Why AI-built apps tend to fail the same way

AI page builders and coding assistants are very good at shipping something that looks right, fast: a landing page, a dashboard, a signup flow, a checkout. Making it work for a screen reader (software that reads a page out loud instead of showing it) is a separate instruction, and it is not one most prompts include. The same handful of gaps show up again and again in apps built this way:

  • Buttons that are only an icon, with no name a screen reader can announce.
  • Form fields with placeholder text instead of a real label, so the hint disappears the moment you start typing.
  • Colors picked for a good-looking palette, not contrast, so light gray on white fails the minimum ratio.
  • Custom components — a dropdown, a modal, a toggle — that only respond to a mouse, because keyboard support was never part of the prompt.
  • Icons and images with no description at all.

None of that is a bug in the AI model. “Make it look good” and “make it accessible” are different requests, and only one of them gets asked by default.

Zero users does not mean zero risk

A common assumption is that a side project with no paying customers is not worth suing over. Lawsuits are not about revenue; they are about whether a product is open to the public and fails to work with a screen reader or a keyboard alone. A landing page collecting emails, a waitlist, a free tool behind a signup form: all of those are public-facing, and all of them count. A typical settlement for a small business runs $5,000 to $25,000 plus legal fees, which is real money for a solo builder even before the first paying customer shows up.

What actually fixes it

The fix does not mean rewriting the app. Roughly half of what an automated scan would flag — missing alt text, unlabeled fields, unnamed buttons, low contrast, an undeclared page language — can be found the same fast way the app was built, by pointing a tool at the pages you shipped. The other half needs a short manual pass: keyboard access on custom components, whether a pop-up traps focus once it opens, whether a screen reader announces the right thing when something changes on screen without a page reload. Those are exactly the interactions an AI-generated interface tends to skip, because they rarely show up in a screenshot.

Once you have the list, most of the work is adding an attribute, a label, or a contrast fix to a component the AI already generated for you. It goes fast because the app is small, not because any of this is optional.

One habit worth starting now

Publish a short accessibility statement — a public page stating which standard you are working toward and how to reach you — and keep a dated note of what you checked and fixed. It will not make a lawsuit impossible, but it changes what a demand letter (a letter, usually from a lawyer, threatening legal action unless you fix things or settle) finds when it looks: a project that is actively maintained, not one that never checked. For a solo builder shipping features every week, that same list is the fastest way to catch whether the next AI-generated screen repeats the same gap.

This is general information based on how these laws currently work, not legal advice for your specific app; if a letter has already reached you, a lawyer licensed where you operate is the right next call.

Scan what you shipped, free, no account: https://rampa.solutions/?de=blog-vibe-coded-app-ada-accessibility-lawsuit

Sources

Find out where your site stands, now

Enter your address. In about a minute: every failure on the page explained without jargon, and the corrected code for what we can fix. Free, no account.

One more chance: free scan · no account

Keep reading

Automated testing covers roughly half of WCAG criteria; a full conformance claim also requires manual review. Technical information, not legal advice.