Vibe-coded app UX: the 7 defects AI ships every time

Vibe-coded apps ship a predictable set of UX defects: gray-on-white text, dead focus states, ARIA that lies, silent errors, and edge states nobody generated. Predictable is the good news. You built the app in a weekend; you can catch its worst UX problems in an afternoon, because they are the same problems every AI frontend has.

This is not a lecture about vibe coding. Shipping fast is the correct move, and you are in large company: for a quarter of YC’s W25 batch, 95% of the code was AI-generated. This is a field guide to vibe-coded app UX: what Lovable, Bolt, v0, and Cursor reliably get wrong, why they all get the same things wrong, and how to check your own app before your users do it for you.

Why AI frontends fail the same way every time

AI frontends fail identically because the models learned frontend from the public web, and the public web fails identically. The WebAIM Million (2026 edition) found detectable WCAG failures on 95.9% of the top million home pages, averaging 56.1 errors per page. Low-contrast text sits on 83.9% of them; 51% have unlabeled form inputs. Train on that, and low-contrast unlabeled output is not a bug in the model. It is the curriculum.

The second cause is what the model optimizes for: looking right in a screenshot. A W4A 2025 study found ChatGPT and Claude “primarily replicate existing design patterns,” perpetuating hard-to-read text, poor contrast, and small touch targets. And a 2025 comparison study found LLMs often beat human code on basic checks like contrast and alt text, yet consistently fail on ARIA: the invisible layer a screenshot can never show. Everything a quick glance validates, the model does fine. Everything it can’t, the model fakes.

The sharpest evidence is a real audit. Axess Lab tested a Lovable-built site in May 2026. It scored 100% on Lovable’s own automated accessibility check, which runs axe under the hood. Then a blind screen-reader user tried it.

Hold onto that case. It anchors everything below: automated scores measure what a machine can see, and vibe-coded apps fail precisely in the places machines and screenshots don’t look.

The 7 defects, and the 2-minute check for each

1. Gray-on-white text that fails contrast

The AI ships tasteful, muted, illegible gray. It learned the look from the low-contrast pages WebAIM keeps flagging as the web’s most common failure. The 2-minute check: squint at your app, or step 2 meters back. Anything that disappears is below the WCAG 1.4.3 threshold of 4.5:1 for normal text. For receipts, pull your actual text and button hex values into this:

The default above is the exact gray an AI generator loves. Fix: replace the muted-text token in your theme once, and every instance inherits it. ⚡ Quick win · ~1 hr.

2. Focus states that don’t exist, modals you can’t leave

Generated CSS routinely strips focus outlines because they look untidy in a screenshot, and generated modals rarely trap focus correctly, so Tab wanders behind the overlay, exactly what the Lovable audit found. The check: unplug your mouse and Tab through your money flow. If you ever can’t see where you are, or can’t get out of a dialog, that is the defect.

3. ARIA that lies

This is where LLMs fail hardest per the 2025 human-vs-LLM study: attributes that look diligent and are wrong. Labels that don’t match visible text, menu buttons that never announce open or closed, live regions that shout over the screen reader. Wrong ARIA is worse than no ARIA, because it confidently tells assistive tech a false story. The check: in devtools, compare each button’s aria-label to what it visibly says; they must match.

4. Errors that fail silently

You prompted for the happy path, so that is what got built. When the API call fails, the generated catch block logs to a console no user will ever open, and the button just... finishes. The user thinks the form submitted. It did not. The check: open devtools, switch the network to offline, and click save. If the UI shrugs, so will your users, right before they churn.

5. Empty states and loading states nobody generated

The AI built your dashboard around demo data, so it has never been empty. A real new user gets a blank void with no hint of what to do first, and slow connections get layout jumps instead of loading feedback. The check: create a fresh account and throttle the network in devtools. Rules: Nielsen #6 (recognition rather than recall) for the empty state, Nielsen #1 (visibility of status) for the loading one. Fix: one empty state per core screen that names the first action, plus skeletons on anything async. ⚡ Quick win · ~1 hr per screen.

6. Touch targets under 24px

Dense little icon buttons look precise in a screenshot and miserable under a thumb. WCAG 2.5.8 (AA, new in 2.2) sets the floor at 24×24 CSS pixels or equivalent spacing. The check: on your phone, tap every icon in your main list view with your thumb, not your index finger. Every miss is a finding. Fix: pad the hit area, not the icon. ⚡ Quick win · ~1 hr.

7. Forms that re-ask what they already know

Each generated screen was born in a separate prompt, so nothing shares state: the checkout re-asks the email from signup, billing re-asks shipping. WCAG 3.3.7 Redundant entry (Level A) says don’t ask for the same information twice in a session. The check: run signup through checkout and count every field you type twice. Fix: auto-populate or offer “same as above.” ⚡ Quick win · ~1 hr.

The 20-minute pre-launch pass

Run this on the one flow that makes you money, in order. It combines all 7 checks and needs nothing you don’t already have.

1. Keyboard-only walk-through (6 min). Unplug the mouse. Signup to paid action using only Tab, Shift+Tab, Enter, and Escape. You must always see where focus is, and always be able to leave a modal.
2. Contrast pass (3 min). Squint test on every screen, then run your body text, muted text, and primary button through the checker above. 4.5:1 for text, 3:1 for large text and UI components.
3. Screen-reader smoke test (5 min). VoiceOver is Cmd+F5 on a Mac; NVDA is a free download on Windows. Tab through the money flow and listen: does every button announce what it visibly says, and does the menu say when it is open?
4. Error-state hunt (4 min). Submit every form empty. Then go offline in devtools mid-save. Every silent failure is a Blocker.
5. Fresh-eyes finish (2 min). New account, phone in hand: is the first screen self-explanatory, and can your thumb hit everything?

Log each miss as a ticket with a severity, the rule it breaks, and an effort tag, same shape as the tickets above. The full method, extended beyond accessibility, is in the founder’s UX audit checklist.

What this pass won’t catch

Be honest about the limits. Automated checkers only see the machine-detectable subset of failures; WebAIM itself cautions that its 95.9% understates the true rate, and the Lovable case shows a perfect automated score coexisting with a product a blind user could not operate. Your 20-minute pass beats any scanner because you actually use the product, but you are still one evaluator who wrote the prompts, testing your own baby. You can also ask the model to critique its own output: ChatGPT fixed 73.4% of its own violations when asked. The catch: the fix rate is worst exactly where the defects live, keyboard-level operable issues. (The how-to is in ChatGPT UX audit prompts.)

One legal footnote, minus the fear-mongering: the EU’s European Accessibility Act has been enforceable since 28 June 2025 for products and services newly sold to EU consumers (baseline incorporates WCAG 2.1 AA), and the US ADA Title II rule holds state and local government sites to WCAG 2.1 AA on deadlines now set for 2027 and 2028. If you sell into the EU, the checklist above stopped being optional last year.

This defect set is also precisely what an agent-based audit catches, because the agent does what the scanner can’t: it signs up, tabs through your modals, kills its own happy path, and files each finding as a ticket citing the rule it breaks, WCAG 2.2 or Nielsen by name. That is what ClapBack does with a URL and no SDK, and what an AI UX audit involves explains where an agent fits next to a human screen-reader tester (short answer: it replaces the scanner, not the human).