Every founder we talk to has thought about GDPR at some point, even if only in passing. Almost none of them have thought about accessibility. That gap matters, because AI app accessibility failures are quietly becoming one of the most common legal exposures we see in vibe-coded products, and the tools that built these apps were never trained to care about it.
We’re not talking about a nice-to-have here. We’re talking about lawsuits, and they’re already happening to companies far smaller than you’d expect.
What accessibility means and who it’s for
Accessibility means your app works for people who don’t interact with a screen the way you do. That includes people using screen readers because they’re blind or have low vision, people who navigate entirely by keyboard because a mouse doesn’t work for them, people with motor conditions who need larger click targets and more time to complete actions, and people with cognitive differences who need clear language and predictable layouts.
It’s a much bigger group than most founders assume. The World Health Organisation estimates over a billion people live with some form of disability. Add temporary situations (a broken arm, eye strain, a noisy environment where audio isn’t an option) and nearly everyone benefits from accessible design at some point. This isn’t an edge case you can defer. It’s a baseline expectation, and increasingly, a legal one.
Why AI-built UIs fail it
AI coding tools are optimised to produce something that looks right and functions on the happy path. They are not optimised to ask “can a screen reader user complete this checkout flow?” That question requires a kind of judgement these tools don’t have, and it shows up in the same handful of ways every time we open a vibe-coded codebase.
Form inputs with no associated labels. The AI generates a text box with a placeholder that vanishes the moment you click into it, so a screen reader announces nothing useful, and a sighted user loses their reference point too. We covered this same pattern of AI cutting corners on fundamentals in our piece on the most common bugs in AI-generated code, and labels are one of the most frequent offenders.
Colour contrast that fails outright. Vibe-coded interfaces love a soft grey-on-white palette because it looks modern in a screenshot. Put it in front of someone with low vision, or anyone using their phone outdoors in daylight, and it’s unreadable. WCAG sets a minimum contrast ratio for exactly this reason, and most AI-generated design systems never check it.
Keyboard traps. Modals, dropdowns and custom date pickers get built as visual components without keyboard logic behind them. A mouse user opens a modal and closes it without noticing anything wrong. A keyboard user tabs into that same modal and can’t tab back out, effectively locked on the page. We see this constantly in AI-generated admin panels and settings screens.
Missing alt text on images that carry actual meaning, like a chart showing pricing tiers or a screenshot demonstrating how a feature works. The AI treats the image as decoration when it’s actually content, and a screen reader user gets nothing where sighted users get the whole point of the page.
None of these are exotic problems. They’re the default output of tools trained to prioritise visual polish over semantic correctness, and they compound across a full app fast.
The legal reality
This is where accessibility stops being an ethics conversation and becomes a legal one, and it’s the part founders consistently underestimate.
In the US, the Americans with Disabilities Act (ADA) has been applied to websites and apps for years through case law, even though the ADA itself predates the web. Thousands of ADA digital accessibility lawsuits are filed annually, and the targets are increasingly small and mid-sized businesses, not just large retailers. A demand letter over an inaccessible checkout flow can arrive well before you’ve hit meaningful revenue.
In the EU, the European Accessibility Act (EAA) became enforceable in mid-2025 and applies directly to digital products including e-commerce sites, banking apps and other consumer-facing software. If you have European users, this isn’t optional, and the compliance clock has already started.
WCAG (Web Content Accessibility Guidelines) is the technical standard both frameworks lean on. Level AA is the practical target most regulators and courts reference. It’s specific and testable, which is actually good news, because it means “are we compliant” has a real answer rather than a vague one.
We’ve walked founders through a similarly overlooked compliance gap before in our GDPR guide for vibe coders, and the pattern is the same here: the legal exposure exists whether or not you knew about it, and “the AI built it this way” is not a defence anyone has successfully used.
A checklist anyone can run
You don’t need to be a developer to spot the worst offenders. Here’s what we’d check on your own app right now.
Tab through every page using only your keyboard, no mouse. Can you reach every button, link and form field? Can you see clearly where focus currently is? Can you always get back out of a modal or menu?
Turn on your screen reader (VoiceOver on Mac, Narrator on Windows) and try to complete your signup flow. Does it announce what each field is for? Does it read button labels that make sense, or just “button, button, button”?
Run your key pages through a free contrast checker and compare your text and background colours against WCAG AA thresholds.
Check that every meaningful image has descriptive alt text, and that decorative images are marked so screen readers skip them.
Resize your browser text to 200% and check nothing breaks or overlaps.
If you want a fuller walkthrough of how to sanity-check AI-generated code without writing any of it yourself, our guide on reviewing AI-generated code as a non-developer covers the same approach in more depth, and it pairs well with the broader pre-launch checklist we recommend before anything goes live.
The cost of getting it wrong
The direct cost is legal: settlements for ADA digital accessibility claims commonly run into five figures even for small businesses, and that’s before your own legal fees. The EAA carries penalties that vary by member state but are structured to actually bite.
The indirect cost is worse in some ways. Every user who can’t complete your signup flow, can’t read your pricing page, or gets stuck in a broken modal is a lost customer who never files a complaint, they just leave. You never see that churn in your analytics as an accessibility problem. It just looks like a slightly worse conversion rate that nobody can quite explain.
Retrofitting accessibility after launch is also considerably more expensive than building it in from the start, because by then it’s woven through every component rather than addressed at the design stage.
Worried your app excludes users, or invites a lawsuit? Get a free assessment and we’ll tell you exactly where the gaps are.