Why ignoring app accessibility could cost you millions of users

Accessibility tends to arrive late in most product conversations. It shows up after the visual design is settled, after the components are built, after the budget has been spent on features that felt more exciting. And then someone asks whether the app works with a screen reader, or whether the contrast ratios meet WCAG standards, and the answer is usually a long pause followed by "we'll look at that in the next sprint." The next sprint rarely comes.

Accessibility is a quality signal baked into every design decision from the very first screen.

This pattern has a cost, and the cost is larger than teams typically realise. Accessibility is treated as a courtesy to a small group of users with specific needs, when the reality is that it affects how almost everyone experiences a product at some point. Poor touch target sizing frustrates people on crowded trains. Low contrast fails people in bright sunlight. Complex navigation excludes people who are tired, stressed, or distracted, which describes a significant portion of any app's daily active users.

The argument for building accessible products is sometimes framed as a legal or ethical obligation, and it is both of those things. But it is also a straightforward product quality argument. An app that works for more people, in more conditions, with less friction, retains more users. The accessibility conversation and the retention conversation are the same conversation.

How many users accessibility actually affects

The most common misconception about accessibility is that it serves a small minority of users. The numbers say otherwise. More than a quarter of the world's population has a diagnosed vision impairment, according to the World Health Organization. Around 12% of men worldwide have colour-deficient vision, with women affected at significantly lower rates. And 26% of people in the United States self-report living with at least one disability.

Those figures cover permanent conditions. They do not account for situational impairment, which is where the numbers get genuinely large. A person using their phone in direct sunlight has the same low-contrast problem as someone with a vision impairment. A person holding a baby has the same one-handed navigation constraint as someone with a motor disability. A person in a noisy environment without headphones cannot rely on audio cues. Situational impairment affects nearly every user, on nearly every day they use your app.

The design decisions that serve users with permanent disabilities almost always serve this broader population too. Larger touch targets reduce mistaps for everyone. Clear typographic hierarchy helps users who are skimming in a hurry as much as users who process information more slowly. Plain language reduces cognitive load across the board.

Why accessibility is treated as a legal checkbox

Teams generally know they should think about accessibility. Fewer teams actually build it into their process from the start. A survey of 75 mobile developers found that 60% considered accessibility very important for mobile app development, with only 4% calling it negligible. Yet the same survey found that personal ethics, cited by 39% of respondents, was the most common reason developers gave for engaging with accessibility guidelines at all. Ethics, not process. Ethics, not product strategy.

This tells you something about where accessibility lives in most organisations. It lives in individual conscience rather than shared standards. One developer cares about it and flags issues. Another does not, and those issues ship. There is no structural home for it, so it moves around depending on who happens to be paying attention.

The legal framing compounds this. The ADA requires apps to be accessible to users with disabilities for companies with 15 or more employees. When compliance becomes the goal, teams aim for the floor rather than the ceiling. They run an automated scan, fix the flagged errors, and consider the job done. The problem is that automated testing catches perhaps 40% of real accessibility issues. The rest require human judgement, and that is what tends to get skipped.

What inaccessible design actually costs in users and revenue

The cost of inaccessible design is usually discussed in legal terms, as the risk of an ADA lawsuit or a WCAG compliance failure. The more immediate cost is user drop-off, and it is substantial. Users abandon apps not only because of bugs and slow loading times, but also because of poor design and poor emotional connection, and the two causes are far closer in impact than many developers assume.

These numbers describe the same problem from different angles. A user who cannot read your text because the contrast is too low, who cannot tap your buttons reliably because the targets are too small, who cannot find what they need because the navigation is unclear, is experiencing a design failure. They do not categorise it as an accessibility failure. They just leave.

Design failures and accessibility failures are usually the same failure, seen from different angles.

The revenue consequence follows directly. Users who leave do not convert. Users who convert but later encounter friction do not return. The 88% who are less likely to return after a bad experience are acting on a feeling that the product did not work for them, and they are correct.

Fixing accessibility problems retrospectively costs considerably more than building them in correctly from the start. By the time a product has shipped, the design system is set, the components are built, and the logic is woven through multiple screens. A contrast ratio that should have been caught at the design stage requires changes across the entire product.

The difference between compliance and accessible design

Compliance means meeting the standard. Accessible design means serving the user. Those two things overlap, but they are not the same.

WCAG 2.1 sets a minimum contrast ratio of 4.5:1 for Level AA body text. A product can hit exactly 4.5:1 on every text element, tick the compliance box, and still be genuinely difficult to read on a bright screen in afternoon light. Compliance is a threshold. Accessible design asks what actually works for the person holding the phone.

The same gap exists with touch targets. 84% of mobile apps fail to implement touch targets correctly, which causes mistaps and frustration across the user base. Meeting the minimum recommended target size matters. But a product built around generous, forgiving targets, with clear visual affordances and enough spacing between interactive elements, serves users far better than one that technically meets the spec.

Run your app on the lowest brightness setting your target device allows. If any text becomes hard to read, your contrast ratios are working against you in real conditions, even if they pass automated checks at full brightness.

Accessibility under pressure: lessons from a film industry document portal

We worked on a document portal for the film industry that needed to serve a wide range of users, from production assistants to department heads, all accessing files and documents under significant time pressure on set. The conditions were nothing like a quiet office with a large monitor and a fast connection. People were accessing documents on phones in varying light, often while doing something else, often in a hurry.

Because of this, we made accessibility an active design priority rather than a compliance consideration. The design was large-scale, with generous navigation elements and a clear visual hierarchy that made it fast to orientate within the portal and get to the right document quickly. Every decision was tested against the question of whether someone could find what they needed in under a minute, under pressure, on a small screen.

The result was a product that worked for the full range of users, across the full range of conditions. That outcome came from treating accessibility as a core design constraint from the beginning, not from running an audit at the end. The environment forced the question early, which is exactly where it belongs.

Before your next design review, list the three most demanding conditions in which real users access your product. Design to those conditions first, and the baseline experience will take care of itself.

When accessibility is a safety issue, not just a usability one

Accessibility conversations usually focus on usability: can users read the text, tap the buttons, navigate the screens. On some products, the question goes further than that. Poor accessibility can create genuine safety risks, particularly in products that involve location data, personal information, or communication with strangers.

We worked on a fitness social app that was originally designed around a map showing users' real-time locations, so people could find workout partners nearby. When we looked at the user research, it became clear that a high proportion of users were female, and precise real-time location sharing carried real security risks. The feature worked from a usability standpoint. It did not work from a safety standpoint.

We redesigned the location feature to use randomised offsets, so users could see only the approximate area where a potential workout partner was located. Users could then review profiles and start a conversation before choosing to share their exact location. The core value of the feature, knowing whether a meetup was physically feasible, was preserved. The safety risk was not.

This kind of accessibility thinking is rarely captured in a WCAG audit. It requires understanding who is actually using the product, in what circumstances, and what could go wrong. Designing for the actual user rather than a hypothetical ideal one surfaces these questions early enough to act on them.

The features that quietly exclude users

Some accessibility failures are obvious. Low contrast text and tiny touch targets are visible problems that show up in audits. Others are quieter, and they exclude users without anyone noticing until the drop-off data arrives.

Colour as the sole means of conveying information is a common one. Around 12% of men have some form of colour vision deficiency. An error state that turns a field red without any accompanying text or icon, a status indicator that uses only green and red, a chart that distinguishes data series by colour alone: all of these fail a significant portion of users without the designer ever intending to exclude anyone.

Typography is another. The W3C recommends that users be able to increase line height to at least 1.5 times the font size without losing content or functionality. Products built on fixed-height containers, where text overflows or gets clipped when system font sizes increase, exclude users who rely on larger text as soon as they change their device settings.

• Status changes communicated by colour only, with no accompanying label or icon
• Fixed-height containers that clip text when system font size increases
• Interactive elements without visible focus states for keyboard and switch access users
• Auto-playing audio or video with no mute control immediately visible
• Time limits on forms or sessions without a warning or extension option

Run your app at the largest system text size available on iOS and Android. If any screen breaks, clips content, or becomes unusable, those are your first fixes.

How to audit your app for accessibility gaps

Automated accessibility scanners are a useful starting point, and they should be part of any audit process. They catch missing alt text, inadequate contrast ratios, and unlabelled interactive elements quickly and consistently. But over 60% of accessibility issues are caught through manual testing rather than automated testing, which means running a scanner and calling it done misses the majority of real problems.

Manual testing means turning on VoiceOver on iOS or TalkBack on Android and attempting to complete your core user journeys using only the screen reader. It means testing at maximum system font size. It means testing one-handed, with the phone held in a single hand and the thumb doing all the navigation. It means testing in bright light and in low light.

1. Run an automated scan and fix every flagged issue before moving to manual testing
2. Complete three core user journeys using only a screen reader, no visual reference
3. Test all screens at maximum system font size on both iOS and Android
4. Check every colour-coded element for a non-colour alternative
5. Test all interactive elements for keyboard and switch access navigation order
6. Test in direct sunlight or bright overhead light to assess real-world contrast performance

The results of this kind of testing are often confronting, particularly if the product has never been tested this way before. A screen that looks polished in a design tool frequently becomes a different experience entirely when navigated by someone who cannot see it.

Building accessibility in from the start versus retrofitting it

Retrofitting accessibility into an existing product is expensive, slow, and produces uneven results. The problems are structural. A design system built without accessible colour pairings, a component library with no focus states, a navigation architecture that made sense visually but has no logical order for screen reader users: fixing these things after launch means revisiting every decision that built on top of them.

We saw a version of this cost on a dating app project where the client chose to skip discovery for the messaging component, focusing the early work entirely on the onboarding flow. What got built was a generic messaging feature that contradicted the product's core premise around verified profiles. It allowed automated and fake messages, which undermined everything the onboarding had been designed to prevent. Rewriting that section cost approximately £15,000 in additional budget and two months of extra work. Skipping the foundational thinking at the start created a structural problem that was much more expensive to fix later.

The same logic applies to accessibility. Decisions made at the design system level, about colour, type scale, spacing, and component behaviour, propagate through every screen. Getting them right at that stage costs very little. Changing them after hundreds of screens have been built around them costs a great deal.

Accessibility belongs in the design brief, alongside colour and typography and layout. The question "does this work for users with different needs and in different conditions" is a design question, and it wants to be answered at the same time as all the other design questions.

Conclusion

Accessibility is a measure of how well your product actually works, in real conditions, for the real range of people who use it. The film industry portal we worked on succeeded because accessibility constraints shaped the design from the start. The fitness app we redesigned became safer and more trusted because we looked honestly at who was actually using it. These were not accessibility projects. They were product quality projects.

The cost of ignoring this is measurable. Users who cannot read your text leave. Users who cannot complete your flows leave. Users who feel the product was not built for them leave. And the 88% who are less likely to return after a bad experience rarely come back to tell you why they went.

The teams that get this right do not treat accessibility as a final checklist before launch. They build it into how they think about design problems from the beginning, and they test it against real conditions rather than theoretical standards. That approach produces products that work better for everyone, retain users more effectively, and cost less to maintain over time.

If you want to talk through where your product stands and what an accessibility-first approach would look like in practice, let's talk about your product.

Frequently Asked Questions