Can Everyone Use Your AI-Built App? A Plain Guide to Accessibility

When you build an app with AI, you test it the way you use it: your screen, your eyes, your steady two-handed grip on a laptop. The trouble is that a real chunk of the people who’ll open your app don’t use it that way. Someone zooms their phone text to twice the normal size. Someone can’t tell your red error message from the black text around it. Someone is holding a baby and tapping with one thumb. App accessibility is simply whether those people can still get through — and it’s a question most AI-built apps never get asked.

You don’t need a degree or a compliance team to handle it. You need to know the four or five places apps usually shut people out, and how to ask your builder to fix them. Let me show you the common ones with stories, because they’re easier to spot once you’ve seen them.

Why does my app’s layout break when someone zooms in?

Because most AI-built apps are designed at one fixed text size, so when someone makes their phone or browser text bigger — something a lot of people do, especially anyone over sixty — buttons overlap, columns collapse into a scrambled stack, and controls slide under each other.

A maker I know built a tidy little appointment app for her mum’s hair salon. Looked great. Then her mum opened it, and the first thing she did — like a lot of people over sixty — was pinch to zoom the text bigger. The layout fell apart. Buttons overlapped, the “Book” button slid under the menu, and a column of times turned into a scrambled stack you couldn’t read.

This is the most common accessibility break in AI-built apps, and it’s invisible until someone zooms. Ask your builder: “Make sure the layout still works when text is zoomed to 200%. Nothing should overlap or get cut off.” Then test it yourself — on your phone, bump the system font size to its largest setting and open your app. If it shatters, that’s your first fix.

Why shouldn’t my app use color alone to show status?

Because about one in twelve men sees color differently, most commonly red and green — so a status shown purely as a red dot versus a green dot looks the same to them, and they genuinely can’t tell “paid” from “overdue.”

A freelancer built an invoice tracker that showed status purely by color — green dot, red dot. One of his clients, who happened to be red-green colorblind, kept paying invoices that were already paid because the two dots looked identical to him. The information was there. It just wasn’t there for him.

The fix is a habit, not a feature: never use color as the only way to say something. Add a word, an icon, or a shape alongside it. “Overdue” next to the red. A checkmark next to the green. An asterisk and the word “required,” not just a red outline. Color can stay — it just can’t be carrying the message alone.

Why do screen readers just say “button” instead of naming it?

Because an unlabeled icon button — a trash can, a pencil, a magnifying glass with no words — has no text for the screen reader (the software blind and low-vision people use to have the screen read aloud) to announce, so it reads out, literally, “button.” Not “delete.” Not “edit.” Just “button.”

AI builders love clean icon buttons because they look modern. But imagine using an app where every control is named “button” and you have to guess. You don’t have to add visible text to every icon — you have to make sure each control has a name underneath, even an invisible one the screen reader can announce. Ask your builder: “Give every icon button an accessible label — a trash icon should be announced as ‘Delete,’ a pencil as ‘Edit.’” It’s a small change and it’s the difference between an app a blind user can navigate and one that’s a wall of anonymous buttons.

How big should tap targets be on a mobile app?

The rough rule designers use is that anything tappable should be about 44 pixels — roughly the size of a fingertip — with real spacing so two tappable things aren’t jammed edge to edge.

Watch someone use your app one-handed on a bus. Thumbs are wide and imprecise, the bus is moving, and your “X” to close is a 16-pixel speck in the corner. They miss it twice, hit the thing behind it once, and give up. Small, crowded tap targets are an accessibility problem, not just an annoyance — they hit people with tremors, larger fingers, or a moving environment hardest. Ask your builder: “Make tap targets at least 44 pixels and add spacing between them so people don’t hit the wrong one.” Then test it: open your app on your phone and try the main action one-handed, walking around. If you keep mis-tapping, so will everyone else.

How do I test my app for accessibility in five minutes?

You can find most of this yourself without any tools, with three quick checks on the screen people use most:

1. Zoom it. Bump your phone or browser text to its biggest setting and open the main screen. Does anything overlap, vanish, or get cut off?
2. Drain the color. Look at every place your app uses color to mean something — status, errors, required fields. If you imagine it all in gray, can you still tell what’s going on? If not, add a word or icon.
3. Turn on the screen reader for two minutes. Both iPhone (VoiceOver) and Android (TalkBack) have one built in. Turn it on, close your eyes, and try to do the main thing your app is for. You’ll hear instantly which buttons are nameless.

None of this requires you to be a developer. It requires you to stop testing as yourself for five minutes and test as someone whose hands, eyes, or screen don’t match yours.

You don’t have to fix everything at once. Pick the one screen people use most — the booking form, the sign-up, the main list — and make that one work when it’s zoomed, drained of color, and read aloud. That single screen, done right, covers more people than a whole accessibility audit of the corners nobody visits. Start there, and the next person who opens your app with one thumb and a zoomed screen gets to be a user instead of a bounce.