App Accessibility for Founders Who Have Never Thought About It

Accessibility is the item that sits at the bottom of every first-time founder's list, below marketing and just above "figure out taxes." It sounds like a compliance exercise, it sounds expensive, and there is always something more urgent.

Here is the case for moving it up. Around 1.3 billion people worldwide live with a disability, which is a meaningful share of any audience you are trying to reach. Accessibility lawsuits over inaccessible apps have hit record highs in recent years, and companies of every size, not just large ones, have been targets. And the specific fixes that matter most for a small consumer app are not a project. They are an afternoon.

The deeper reason, though, is that almost everything on the accessibility checklist makes your app better for people without disabilities too. Larger tap targets help everyone using one hand on a train. Good contrast helps everyone outdoors. Clear labels help everyone.

What accessibility actually means on a phone

Not an abstract standard. Concretely, it means your app works for someone who:

• Cannot see the screen, and navigates by a screen reader that speaks each element aloud
• Has low vision, and has turned their system text size up substantially
• Is colour blind, so anything communicated by colour alone is invisible
• Has limited fine motor control, so small or tightly packed buttons are unusable
• Has a temporary or situational limitation: bright sun, one hand occupied, a cracked screen

That last category is worth noticing. Most people are situationally disabled regularly, which is why these fixes pay back far beyond the group they are aimed at.

The five things that matter most

If you do nothing else, do these. They cover the majority of real-world problems in a typical consumer app.

1. Label every interactive element. A screen reader announces what it finds. A button containing only an icon, with no label, is announced as "button," which tells the user nothing. Every icon button, image that carries meaning, and custom control needs a text label describing its purpose ("Add entry," not "plus icon"). This is the single highest-impact fix, and for most apps it is a couple of hours of adding labels.

2. Make tap targets big enough. The accessibility guidelines set a floor around 24 by 24 pixels, but both platforms recommend considerably larger: Apple suggests 44 by 44 points, Google 48 by 48 density-independent pixels. Anything smaller is hard for many people and annoying for everyone. Check your close buttons, your small icons, and anything in a dense row.

3. Fix your contrast. Light grey text on a white background looks elegant in a design tool and is unreadable for a lot of people in a lot of conditions. Run your palette through any free contrast checker and fix what fails. Related: never communicate anything by colour alone. A red border on an invalid field needs accompanying text, because a colour-blind user sees no border change at all.

4. Support larger text. Test your app with system text size turned up. If the layout breaks, text gets cut off, or buttons overlap, that is a real bug for a large group of users, many of them simply over forty. Using the platform's dynamic text support rather than fixed sizes usually solves this.

5. Respect system settings. If the user has asked for reduced motion, do not run large animations. If they have enabled dark mode, honour it. These are preferences people set for real reasons, sometimes medical ones.

How to actually check

You do not need a specialist to find most problems. Three passes, none of which take long:

Turn on your platform's screen reader and use your own app. VoiceOver on iOS, TalkBack on Android. Navigate your core flow without looking at the screen. This is uncomfortable the first time, and it will surface a list of unlabelled elements and traps within minutes. It is the single most informative thing you can do.

Run the built-in scanner. Both platforms ship accessibility inspection tools, and entry-level scanning is now widely available and often free. These catch contrast failures, missing labels, and undersized targets automatically. They do not catch everything, but they clear the easy debt fast.

Do the settings sweep. Text size at maximum, dark mode on, reduced motion on, one-handed. Walk your main flow in each. Note what breaks.

Combined, that is an afternoon, and it will catch most of what matters in a small app.

The legal picture, briefly

This is orientation, not legal advice, and jurisdictions differ significantly.

In broad terms: accessibility is a legal requirement in many places, the number of lawsuits over inaccessible digital products has risen sharply, and small companies are not exempt in practice. Some regions have introduced requirements that reach a wide range of consumer digital services, and the standards these rules point at are generally the WCAG guidelines, which include criteria written specifically for mobile: touch targets, gestures, orientation, and screen reader compatibility.

If you are operating at any real scale, in a regulated space, or selling into regions with strict requirements, talk to someone qualified. For a small app early on, the practical posture is: do the five things above, keep a note of what you have done, and treat accessibility as ongoing rather than a one-off audit.

Why this is also a growth argument

Set aside obligation for a moment.

It is a market. A large group of people is poorly served by most apps in most categories. Being genuinely usable is a differentiator you can state plainly in your store listing, and it is the kind of thing users tell each other about.

It affects retention. An app somebody cannot comfortably use gets deleted, and that shows up in your retention curve without ever explaining itself. Accessibility problems are invisible in your analytics: you see the drop-off, not the reason.

It shows up in reviews. Accessibility complaints are specific, memorable, and public. They are also among the most fixable one-star reviews you will ever get.

It improves the app generally. Every item on the list above is just good mobile design. Bigger targets, better contrast, clear labels, layouts that survive large text. You would want these anyway.

Where to start on Monday

1. Turn on your screen reader and try to complete your app's core action without looking. Write down everything that fails. 2. Add labels to every unlabelled control. This alone will fix most of what you found. 3. Run a contrast check on your palette, fix failures, and remove any place where colour alone carries meaning. 4. Set system text to maximum and fix what breaks. 5. Add these checks to whatever you do before each release, so the debt does not rebuild.

None of this requires an accessibility specialist, a budget, or a separate project. It requires an afternoon and the willingness to notice that some people cannot use the thing you built. Most founders who do the screen reader pass come away slightly embarrassed and then fix it quickly, which is exactly the right sequence.