US | Accessibility | 2026-09-06

Mobile App Accessibility Basics for Small Businesses

Screen readers, text size, contrast, touch targets. None of it is exotic, all of it is checkable, and most of it is cheaper to build in than to bolt on. Here is the short list that matters for a business app.

Accessibility tends to get filed under "things big companies worry about," which is a mistake for two reasons. The first is practical: a meaningful share of your customers use larger text, higher contrast, voice control, or a screen reader, and an app that fights those settings loses those customers quietly. The second is legal: in the United States, accessibility complaints against businesses' digital properties have been steady for years, and small businesses are not exempt from them.

The good news is that the basics are genuinely basic. For a typical small-business app, a booking tool, a loyalty program, an ordering flow, the work that gets you most of the way is a few days of attention during the build, not a separate project. This guide lays out what that work is, how to check it without specialist tools, and what to ask for from whoever is building your app.

What accessibility means in a mobile app

At its simplest, an accessible app is one that works when the user changes how they interact with their phone. That includes people who cannot see the screen well or at all, people who cannot use fine touch gestures, people who are colorblind, people who need larger text, and people using the phone one-handed on a moving bus. The overlap between "accessibility" and "just works better for everyone" is large.

Both platforms ship the assistive technology already. iOS has VoiceOver, Dynamic Type, and a set of display accommodations. Android has TalkBack, font scaling, and similar settings. Your app does not have to build any of that. It has to not break it.

The short list

These are the items that account for most real-world accessibility problems in business apps, roughly in order of how often we see them.

• Labels on everything interactive. Every button, icon, and control needs a text label that a screen reader can announce. An unlabeled icon button reads as "button" and nothing else. This is the single most common failure and the easiest to fix.
• Text that scales. When the user turns up their system text size, your app's text should get bigger, and the layout should not clip or overlap. Fixed-size text and fixed-height containers are the usual culprits.
• Contrast. Light gray text on white looks refined in a design tool and is unreadable for a lot of people. Body text and essential controls need clear contrast against their background. The widely used guideline is a ratio of at least 4.5 to 1 for normal text.
• Touch targets big enough to hit. Small tap areas fail for people with motor difficulties and for everyone else in a hurry. Both platforms recommend a minimum size in the neighborhood of 44 to 48 points.
• Meaning that does not depend on color alone. If red means unavailable and green means available, add a label or an icon. Colorblind users cannot tell the difference otherwise.
• Logical focus order. A screen reader moves through the screen in an order. It should match the visual order and make sense. Custom layouts sometimes scramble it.
• Forms that announce errors. When a booking form rejects an input, the error should be attached to the field and readable, not just a red outline.
• No essential information in images alone. A promotional image with the discount code baked into the graphic is invisible to a screen reader. Put the text in text.

How to check without special tools

You do not need an audit firm to catch most of this. Three checks, done on a real phone, find the majority of problems.

Turn on the screen reader and use your app blind. Enable VoiceOver or TalkBack, close your eyes or turn the screen brightness to zero, and try to complete your app's main task. Book an appointment. Place an order. Every place you get stuck is a bug. This takes twenty minutes and is the most revealing test there is.

Turn text size to maximum. Set the system font to the largest setting and walk through every screen. Look for clipped labels, overlapping elements, and buttons pushed off screen.

Use it in bright sunlight. Low-contrast designs fail outdoors. If you cannot read it on a bench at noon, neither can a customer with reduced vision indoors.

Both platforms also include built-in inspection tools. Xcode's Accessibility Inspector and Android's Accessibility Scanner flag missing labels, small targets, and contrast problems automatically. Ask your developer to run them before each release.

Where Flutter fits

Most of the apps we build are Flutter, and it is worth saying that cross-platform frameworks are perfectly capable of accessible apps, with one caveat. Flutter draws its own widgets rather than using the platform's native controls, which means it generates its own accessibility tree for screen readers. The standard widgets handle this well. Custom-drawn widgets need to be given semantics explicitly, or they are invisible to assistive technology. A developer who knows this builds it in; one who does not ships an app where the custom date picker cannot be used with VoiceOver. It is a reasonable thing to ask about when comparing frameworks and studios.

The legal picture, briefly

This is not legal advice, and the specifics depend on your business and your state. The general shape is that the Americans with Disabilities Act has been applied to businesses' websites and apps in a large number of cases, that courts and the Department of Justice have pointed to the Web Content Accessibility Guidelines as the reference standard, and that small businesses with public-facing apps do receive demand letters. An app that has clearly attended to the basics above is in a very different position from one that has not, and the cost of getting there is a fraction of the cost of responding to a complaint.

If your app serves a regulated sector, healthcare, government contracting, education, the requirements may be more specific. Ask a lawyer in that case. For a general small-business app, the short list above is the sensible floor.

What to ask your developer for

If you are commissioning an app, put accessibility in the scope explicitly rather than assuming it. A reasonable ask is:

• All interactive elements have accessibility labels.
• Text respects system font scaling without breaking layout.
• Text and control contrast meets the standard 4.5 to 1 guideline.
• Touch targets meet platform minimums.
• The main flows have been tested end to end with VoiceOver and TalkBack.
• Platform accessibility scanners have been run and their findings addressed.

That is a checklist a studio can say yes or no to, and it belongs in the handoff alongside source code and store accounts. Our guide on what app handoff should include covers the rest of that package.

The case for doing it anyway

Set the legal argument aside and the business argument still holds. Accessible apps work better in bright light, with one hand, with gloves, for older customers, and for anyone whose eyes are tired at the end of the day. Every one of those is a customer you want to keep. The work is small, the audience is real, and the alternative is an app that silently excludes people who were trying to give you money.

If you want an app built with this in from the start rather than retrofitted, get in touch. More product and launch guides are on the blog.