Mobile app accessibility: how to build a product that works for everyone

Most accessibility conversations in product teams follow the same pattern. Someone mentions WCAG. Someone else says "we'll run an audit before launch." The meeting ends. Nothing changes.

The cost shows up quietly — not in your support channel, but in your retention data:

• Older users who can't hit buttons crammed too close together.
• Users in bright sunlight who can't read grey-on-grey text.
• Blind users whose screen readers announce "button, button, button" because nobody labeled the icons.

They don't file complaints. They leave.

Designers operate in a bubble. They assume everyone uses a phone the way they do — fast, intuitive, with the same mental models. They don't. Hand your prototype to someone outside your team. Watch them use it for ten minutes without helping. You'll see things invisible from inside the bubble — and most of them are accessibility failures you didn't know existed.

The shift most teams miss: accessibility isn't a feature you bolt on for "users with disabilities." It's a quality standard for the entire product. The same issues that block blind users also frustrate anyone holding a phone in the rain, walking down stairs, or reading in sunlight.

In the EU, as of June 28, 2025, this stopped being optional. The European Accessibility Act requires most consumer-facing digital products — banking, e-commerce, transport, telecom — to meet WCAG 2.1 AA. New services had to comply from day one; existing ones have until 2028.

Compliance is the floor, not the ceiling. Build accessible products because the product gets better. That's the whole argument.

What follows is a practical list of what needs to happen — with sources, numbers, and the reasoning behind each decision. No fluff.

1. Color contrast is the easiest win — and most apps still fail it

WCAG 2.1 (Level AA, SC 1.4.3) requires a contrast ratio of 4.5:1 for normal text and 3:1 for large text (18pt regular or 14pt bold). For UI components and meaningful graphics: 3:1 minimum (SC 1.4.11). That’s the compliance floor. AAA requires 7:1 — aim higher whenever possible.

The fix is mechanical and should never reach production, and these requirements help users with low vision and other visual impairments:

• Stark or Contrast plugin in Figma — real-time checks as you design.
• Able plugin for full-screen audits.
• Native tools: macOS Digital Color Meter, iOS Accessibility Inspector.

Two patterns cause most failures.

First: a tendency toward washed-out pastels — pale mint on white, light grey on light grey. This is a color contrast problem, not just a missed check. These fail contrast checks and read as weak design, not refined minimalism. High contrast isn’t heavy-handed. It’s decisive.

Second: following the brand palette without adapting it. Most brand colors were built for print, packaging, or billboards — not for body text on a 5” screen at 50% brightness. The brand red that pops on a poster might sit at 3.2:1 on white in your UI — which fails AA. Digital products need an extended palette: the brand color stays for hero moments, but text, icons, and states use tuned variants to present information more clearly on small screens and in difficult lighting. This is a conversation to have with whoever owns the brand. Not a fight — a clarification.

Source: W3C ,WCAG 2.1 ,SC 1.4.3

2. Touch targets are bigger than you think they need to be

This is where the most damage happens in real projects. A designer creates a 24×24 icon. The engineer ships it at exactly 24×24. The result: a button that’s unreliable to hit — especially for users with motor impairments, but also for anyone holding the phone with one hand on the bus.

What the standards actually require: there are specific target size requirements for touch inputs on mobile devices.

• WCAG 2.2 SC 2.5.8 (Level AA, legal minimum): the target size criterion requires 24×24 CSS pixels, or 24px spacing around the target.
• WCAG 2.2 SC 2.5.5 (Level AAA, better target): 44×44 CSS pixels.
• Apple HIG: 44×44 points minimum for any tappable element.
• Google Material Design: 48×48 dp minimum, with 8dp spacing between targets.

The practical standard: 48dp / 44pt minimum, regardless of platform. The visual element can be smaller (a 24×24 icon inside a 48×48 hit area is correct), but the touch area must be large enough to tap reliably across devices and meet platform recommendations.

Two practical fixes:

In Figma, wrap every interactive icon in a container at the platform minimum and lock it as a component. If you can’t see the hit area, you’ll forget it exists — and engineers without an explicit spec will ship the visual size.

The 8dp spacing rule from Material exists for a reason: fingertips aren’t precise. Two buttons sharing a border produce mistaps. Test these mobile-specific interactions on real hardware, not just the canvas.

Sources: WCAG 2.2, SC 2.5.8, Apple HIG — Layout, Material Design 3 — Accessibility

3. Stress-test your layout at 200% text size

WCAG 2.1 SC 1.4.4 requires text to scale to 200% without losing content or functionality. iOS and Android expose this through Dynamic Type (iOS) and Font Scale (Android). Many older users are already running at 150–200% by default.

Most designers never test this. Screens are built at 100% and shipped. Then a user with 180% font opens the app, the "Confirm" button truncates to "Conf…", the price field overlaps with the label, and the whole experience falls apart for users who were already struggling.

What this requires in practice:

• Build with a font-scale variable in Figma. Toggle between 100%, 150%, 200%. Fix layout failures at handoff, not post-launch.
• Use Dynamic Type on iOS and sp units on Android — never hardcoded font sizes.
• Design containers to wrap and grow, not truncate. Truncation should be an intentional decision, not a side effect.
• Test at the worst case: smallest supported screen × largest font setting.

This single practice catches more bugs than any other accessibility check, because it stresses the entire layout system at once.

Source: W3C, WCAG 2.1, SC 1.4.4

4. Screen readers don't read what you designed — they read what you labeled

A data point worth internalizing: in WebAIM’s 2024 screen reader user survey, nearly 86% of respondents said better websites would have more impact on accessibility than better assistive technology. Only 14% pointed to the tools themselves.

Translation: the technology works when implementations are compatible with assistive technologies. The implementations are the problem.

Every interactive element — buttons, icons, images that carry meaning — needs a label that makes sense out of visual context. Not image_24.png. Not btn_primary_2. Something a human would say out loud.

Practical examples:

• A heart icon for “favorite”: label it “Add to favorites” / “Remove from favorites” depending on state. Not “heart.”
• A product image: describe the product. “Blue Adidas Samba sneaker, side view.” Not “product_thumbnail.”
• A chevron next to a menu row: label the action, not the icon. “Open profile settings.” Not “chevron right.”
• Decorative images (backgrounds, dividers): mark them as decorative so screen readers skip them.

The same labeling principles apply to mobile apps, just like they do to websites.

Reading order is equally important. Screen readers follow the view hierarchy, not the visual layout. If your hero text appears below an absolutely-positioned button in the DOM, VoiceOver reads the button first. Test on a real device with the screen reader actually on. The simulator is not reliable.

Heading hierarchy matters too. Sighted users scan visually; screen reader users navigate by headings. Using H1 for everything because it “looks better” makes the app unnavigable for blind users and makes it harder for people with disabilities to access content efficiently.

Sources: NN/G — Challenges for Screen-Reader Users on Mobile, WebAIM Screen Reader User Survey #10, Apple HIG — Accessibility

5. Default font size is larger than most designers assume

WCAG doesn't specify a minimum default font size. It covers scalability (200% growth) and contrast — but not the starting point. That gap is significant. Text that's too small is at least as unreadable as low-contrast text. Most adults eventually develop presbyopia; it's not an edge case, it's a default outcome of getting older.

Platform recommendations:

• Apple HIG: body text at 17pt SF Pro for iOS, with Dynamic Type scaling. Smaller styles (Caption 1, Caption 2) go down to 11–12pt but are reserved for short, supplementary content.
• Google Material Design: body large at 16sp, body medium at 14sp as the default for long-form content.

The "12pt minimum" sometimes cited by designers isn't a standard — it's an informal heuristic. Treat 14sp / 14pt as the absolute floor and target 16–17 wherever feasible. The users who benefit (older eyes, second-language readers, anyone distracted) significantly outnumber those who'll feel the text is too large. And that group can adjust system-wide.

Reading is friction. Larger text reduces friction. The product gets more readable. Users stay.

Sources: Apple HIG — Typography, Material Design 3 — Typography

6. Inclusive language: the part most accessibility audits skip

Accessibility isn't only visual and motor. It's also language. And language is where products quietly signal to users "this wasn't built for you."

Patterns to eliminate:

Forms that assume gender. A signup form with "Mr / Mrs" as required radio buttons excludes non-binary users and frustrates anyone who finds the question irrelevant. If you don't need the data, don't collect it. If you do, make it optional with an open field.

Error messages that blame the user. "You entered an invalid email" reads as accusatory. "We can't recognize this email format" reframes the issue as a system problem. Users with cognitive disabilities, anxiety, or simply a bad day respond differently to tone.

Idioms and jargon. "Knock it out of the park" doesn't translate. Neither does "blue ocean strategy" or "ninja-level skill." If your product serves a global audience or non-native speakers, plain language outperforms clever copy every time.

Unnecessary loaded terms. "Whitelist / blacklist" and "master / slave" carry historical baggage irrelevant to what they describe in software. "Allowlist / blocklist" and "primary / replica" are precise and carry no noise. Same principle applies to "crazy expensive" or "insane value" in marketing copy — a more precise word is usually a more interesting one.

Empty states with no direction. A user opens a screen, sees an illustration and the text "Nothing here yet," and doesn't know what to do next. Is something broken? Did they miss a step? An empty state should tell the user why it's empty ("You haven't saved any items yet") or what to do to fill it ("Tap the heart on any product to save it here") — ideally both, with a clear action. Empty isn't a state to decorate. It's a moment where the product should reduce confusion.

This isn't political correctness theater. It's the same core principle as every other accessibility consideration: assume your user is more diverse than you.

Source: Microsoft Inclusive Design Toolkit

7. Test on a cheap Android — not your iPhone 17 Pro

Designers test on the device they own. The device they own is typically the latest iPhone or a high-end Pixel. Their users are on three-year-old budget Androids with smaller screens, slower processors, and OLED panels that render colors differently, so accessible mobile experiences need to hold up across different screen sizes and older hardware.

What this requires:

• Test on a 5.5” screen, not a 6.7” one, and check screen sizes in both portrait and landscape where relevant. Compact iPhone SE dimensions are the worst case for most apps and the most consistently overlooked.
• Test on Android across multiple devices — Material rendering differs from iOS, especially for typography and spacing.
• Test in low brightness. Sunlight kills legibility on low-contrast UIs.
• Test with one hand. Bottom-of-screen actions matter; top corners are unreachable for thumb-only use.

An app that looks precise on the latest iPhone Pro Max gets shipped, and only after launch does anyone discover the primary CTA is cut off on a smaller device with default font scaling. That’s a few minutes of testing replaced by weeks of fixing in real-world use.

Design for the edge case. The middle takes care of itself.

Source: Apple “Designing for iOS”

Three more patterns worth knowing

Respect Reduce Motion. Both iOS and Android expose a system flag for users who experience motion sickness from animations or have vestibular disorders. Parallax effects, sliding transitions, autoplay video — all should respect this flag and fall back to cross-fades or static states, and these accessibility requirements also apply to mobile app interactions, not just general interface animation.

Color is not a standalone communication channel. WCAG 1.4.1 (Use of Color) means: never communicate state with color alone. Red error states need an icon. Green success states need a checkmark. A graph with three lines needs different line styles, not just three different colors. Bottom navigation that marks the active tab only by changing color is a classic failure — add a dot, a filled icon, or a line. Something that survives without color, which is one example of how guidelines WCAG and the web content accessibility guidelines apply to mobile interfaces too. Around 1 in 12 men are colorblind.

Form errors are the most common accessibility gap. Most apps show errors in color only, without explaining what’s wrong, often far from the relevant field. Pair every error with text, place it adjacent to the field, and announce it to screen readers via aria-live (web) or native accessibility announcements. This single fix helps provide error text and announcements so users can understand the requirements and next steps.

What to do this week

Mobile accessibility, like web accessibility, doesn’t get fixed in one sprint. It gets built into the process and compounds over time.

Three concrete actions:

1. Install Stark or Contrast in Figma. Audit one existing screen against WCAG AA, following ada expectations and relevant accessibility requirements where they apply. You’ll find at least two failures. Fix them in the design system — not on that screen — so every future screen inherits the fix.
2. Wrap every interactive element in a 48dp / 44pt hit area as a component. From this point forward, every icon button is a component. Smaller touch areas become structurally impossible to ship.
3. Add “view at 200% text” and “view with VoiceOver” to your design review checklist — alongside “view on smallest device.” Three minutes per screen. These checks help make mobile apps accessible across mobile devices and catch a significant share of what would otherwise ship broken.

If you’re a founder reading this: accessibility isn’t a designer’s internal problem to manage quietly. It’s a product quality decision, and it’s now a legal requirement in the EU, especially for government teams and any organization publishing digital services. Ask your design lead what your WCAG compliance level is. If they don’t have an answer, that’s the conversation to start — not as a punishment, but as a baseline. Keep an internal guide so teams can apply specific standards consistently.

Building accessible mobile products improves mobile accessibility and creates better experiences for people. Those are the products that retain users long-term.

Top AI innovations delivered monthly!

The administrator of your personal data is Miquido sp. z o.o. sp.k., with its ... registered office in Kraków at Zabłocie 43A, 30 - 701. We process the provided information in order to send you a newsletter. The basis for processing of your data is your consent and Miquido’s legitimate interest.You may withdraw your consent at any time by contacting us at marketing@miquido.com. You have the right to object, the right to access your data, the right to request rectification, deletion or restriction of data processing. For detailed information on the processing of your personal data, please see Privacy Policy.

Show more