Is Your Vibe-Coded App Usable for Everyone?

Quick answer: probably not entirely, and you can't tell by looking at it. AI app builders produce screens that look polished to someone using a mouse and good eyesight, but they regularly skip the parts of a page that people with disabilities rely on: buttons a keyboard can reach, labels a screen reader can announce, text with enough contrast to read, and images with a description. You can find the biggest problems yourself in about 15 minutes by putting your mouse away, zooming the page, and running an automated accessibility check. Fix anything that blocks someone from signing up, logging in, or paying first.

Accessibility sounds like a niche concern until you remember who it covers. It includes people who are blind or have low vision, people who can't use a mouse because of a tremor or an injury, people with color blindness, older users whose eyesight is fading, and anyone reading a phone in bright sunlight. It also covers your power users who navigate entirely by keyboard because it's faster.

When an app ignores them, those people don't file a bug report. They leave. And because the app looks fine to you, you never find out why.

This is part 4 of our series on what vibe-coded apps miss. Start with the overview here.

In short: an app that looks good isn't the same as an app everyone can use. Test it without a mouse, check the contrast, and treat any blocked sign-up or checkout as a real bug, not a nice-to-have.

What it looks like

Accessibility problems are invisible to the person who built the app, which is exactly why they survive. Here is what they look like from the other side.

• A keyboard user presses Tab and nothing visible happens. Focus is moving somewhere on the page, but there is no outline showing where. They can't tell which button they're on.
• A "button" can't be reached at all. It was built as a clickable box rather than a real button, so the keyboard skips over it entirely. If that box is "Continue" or "Pay now," the user is stuck.
• A screen reader announces "button, button, image, link." Icons with no text, images with no description, and links that say "click here" give a blind user nothing to go on.
• Form fields have no labels. The grey placeholder text inside the box disappears the moment you start typing, and a screen reader may not announce it at all. The user doesn't know what the field was asking for.
• Light grey text on a white background. It looks elegant on a designer's bright monitor. On a cheap laptop, a phone outdoors, or for anyone with weaker eyesight, it's unreadable.
• A popup traps you. A modal opens, keyboard focus stays behind it on the page underneath, and there's no way to close it without a mouse.
• The page breaks when zoomed. Someone who sets their browser to 200% sees text overlapping, buttons pushed off screen, or a layout that requires scrolling sideways.

None of these show up in a screenshot. All of them can stop a real person from using your product.

Why AI tools miss it

This isn't carelessness on anyone's part. It comes down to how these tools are judged and how they work.

They optimize for how it looks. You describe a screen, the tool generates it, and you judge the result visually. If it looks right, you move on. Nobody in that loop is navigating by keyboard or listening to a screen reader, so nothing pushes the tool toward getting those parts right.

Clickable boxes work fine with a mouse. A styled box with a click handler behaves exactly like a button when you click it. The difference only appears for keyboard and screen reader users, which the generated preview never tests.

Design trends favor low contrast. Soft greys, thin fonts, and subtle borders are fashionable, and AI tools reproduce what's common. Fashionable and readable are not the same thing.

Accessibility lives in details you never asked for. Labels on form fields, descriptions on images, a visible focus outline, the order things are read in. If your prompt didn't mention them, the tool often doesn't add them, and you have no reason to notice.

Each prompt fixes one screen. You might ask for an accessible sign-up page and get one. The settings page generated three weeks later, from a different prompt, starts from scratch.

Check it yourself

You don't need special software or any code knowledge for most of this. Set aside 15 minutes and go through your most important flow, usually sign-up, login, and whatever counts as the main action in your app (booking, paying, creating something).

• Unplug your mouse. Use only Tab to move forward, Shift+Tab to move back, Enter to press buttons and follow links, Space to tick boxes, and Escape to close popups. Can you complete the whole flow? Can you always see where you are on the page? If you get stuck or lost at any point, that's a blocking problem.
• Zoom to 200%. Press Ctrl and + (or Cmd and + on a Mac) until the browser shows 200%. Does the text still fit? Is anything hidden, overlapping, or only reachable by scrolling sideways?
• Squint test the contrast. Look at your lightest text: placeholder text, small captions, disabled-looking buttons, text on top of images. If you have to lean in to read it, so will your users. Free online contrast checkers will tell you for sure if you paste in the two colors.
• Click the field label. On each form, click the word above the input (like "Email"). If the cursor jumps into the box, the label is properly connected. If nothing happens, it probably isn't, and screen readers may not announce it either.
• Try a screen reader for two minutes. Mac and iPhone have VoiceOver built in, Windows has Narrator, and Android has TalkBack. Turn it on, close your eyes, and try to find your sign-up button. It will feel awkward at first, but you'll quickly hear whether buttons and images make sense.
• Turn off images. Or just look at your icon-only buttons and ask: if this icon didn't load, would anyone know what this button does?

Write down everything that stopped you or confused you. That list is more valuable than any score.

How FlawPilot spots it

Manual testing tells you what it feels like. An automated check tells you how widespread the problems are, page by page, which matters because vibe-coded apps are inconsistent from one screen to the next.

FlawPilot's Site Health check crawls every page of your site and gives each one an Accessibility score, alongside Performance, Best Practices, and SEO. You can run it in Mobile or Desktop mode, which matters because the same page can behave very differently on a phone.

Here is how to read what comes back.

An honest limitation: automated accessibility checks, ours included, catch only part of the problem. They are good at things a machine can measure, like missing labels, missing image descriptions, and color contrast. They can't tell whether your image description is actually helpful, whether the tab order makes sense, or whether a person using a screen reader can finish your checkout. A page can score well and still be hard to use. Use the score to find and prioritize issues across many pages, and keep doing the keyboard and screen reader checks above on the flows that make you money.

What "fixed" looks like

If you hand this to a developer, or prompt your AI tool to fix it, here is what you should be able to verify afterwards.

• Every interactive element is reachable by keyboard and shows a clear, visible outline when focused.
• Buttons are real buttons and links are real links, not styled boxes that only respond to clicks.
• Every form field has a visible label that stays on screen while you type, and error messages say what went wrong in words, not just a red border.
• Images that carry meaning have a short description. Purely decorative images are marked so screen readers skip them.
• Icon-only buttons have a text name a screen reader can announce, like "Close menu" instead of nothing.
• Text passes contrast guidelines, including small text, placeholder text, and text over images.
• Popups move focus inside when they open, close with Escape, and return focus to where you were.
• The layout survives 200% zoom without content disappearing.

Then rerun Site Health and repeat your keyboard walkthrough. The score should go up, and more importantly, you should be able to finish your main flow without touching the mouse.

Urgent or cosmetic?

Not every accessibility issue is equally serious. Prioritize by what it blocks.

There's also a business reason to care beyond lost users. Many countries have rules around digital accessibility, and expectations are rising, especially for businesses selling to the public or to larger organizations that ask about it in procurement. The details vary by location and industry, so if this applies to you, check the requirements for your market with someone qualified rather than relying on a blog post. Either way, fixing the basics now is far cheaper than retrofitting a large app later.

Final Thoughts

The awkward thing about accessibility is that you can't see the problem from where you're sitting. The app looks finished, the demo works, and the people being shut out never tell you. That's why it has to be checked on purpose rather than noticed by accident.

You don't need to become an expert to make real progress. Put the mouse away, walk through your sign-up and checkout, and fix anything that stops you. Use an automated check to find where the problems cluster across your pages, then keep testing the flows that matter by hand.

An app that more people can actually use is, quite simply, an app with more customers. That's worth 15 minutes of your week.