Mobile App Accessibility Guide

Mobile app accessibility is the work of making sure people can use your app with a screen reader, with large text, with one hand, with a switch or voice control, or without perfect colour vision. On a phone that work sits in a few concrete places: labels and roles on every control, layouts that reflow when text grows, touch targets large enough to hit, contrast you can read outdoors, and gestures that have a simpler alternative.

This guide covers which WCAG 2.2 criteria matter on mobile, where the European Accessibility Act and the ADA come in, the platform numbers to design to, and how to test on real devices. If you want a team to design it in from the first wireframe, our mobile app UI UX design services treat WCAG 2.2 AA as the baseline. For general design principles, our mobile app UX best practices guide covers the rest.

Accessibility is far cheaper to design in than to retrofit. A missing label is a one-line fix; a custom control that a screen reader cannot operate, repeated across forty screens, is a rebuild.

Most teams picture a blind user with VoiceOver. That user matters, but the larger groups are quieter: people who set the system text size two steps up, older users with reduced dexterity, people with colour vision deficiency, and anyone using the phone one-handed on a bus.

The assistive technologies to plan for on mobile:

• Screen readers: VoiceOver on iOS and TalkBack on Android. Users move between elements by swiping.
• Text size: Dynamic Type on iOS, font size and display size on Android.
• Switch and voice control: Switch Control and Voice Control on iOS, Switch Access and Voice Access on Android, which rely on the same labels and focus order.
• Display and media: Reduce Motion, increased contrast, bold text, dark mode, plus captions for any video.

Then there are the people who check: enterprise and public-sector buyers ask for an audit during procurement, EU regulators now have a law to point to, and Apple lists accessibility among the things its editors consider, as covered in our post on getting your app featured on the App Store.

WCAG is a web standard, but audits, tenders and regulators use it for apps too. WCAG 2.2 became a W3C Recommendation on 5 October 2023, adding nine success criteria to WCAG 2.1. Level AA is the practical target for almost every commercial app.

European Accessibility Act

The EAA applies from 28 June 2025 to covered products and services placed on the market after that date. Covered services include e-commerce, consumer banking, telecoms, transport (including websites, apps and e-ticketing) and e-books. Dutch government guidance counts marketplaces and hotel or meal booking platforms as e-commerce. If your app sells to EU consumers in one of those sectors, plan as if it applies.

Article 4(5) of Directive (EU) 2019/882 says microenterprises providing services are exempt from the service accessibility requirements. Luxembourg’s official EAA guidance defines a microenterprise as fewer than 10 employees with annual turnover or balance-sheet total of no more than €2 million. Note who the exemption belongs to: the business providing the service. A bank or retailer is not exempt because the agency building its app is small.

United States

For private businesses, DOJ guidance from March 2022 says the ADA’s effective-communication requirements apply to online goods and services, without mandating a specific technical standard. For state and local governments, the ADA Title II rule requires WCAG 2.1 AA for web content and mobile apps, including apps provided through contractors. An interim final rule effective 20 April 2026 moved the compliance dates to 26 April 2027 for entities with a population of 50,000 or more and 26 April 2028 for smaller ones. The technical standard did not change.

Three different numbers get quoted for touch targets. They come from different sources and do not conflict.

• WCAG 2.2 (2.5.8, AA): pointer targets of at least 24×24 CSS pixels, with exceptions for spacing, inline text links, equivalent controls, user-agent defaults and essential cases. This is the audit floor.
• Android: Google’s Android accessibility guidance recommends a touch target of at least 48dp × 48dp for each interactive element, and says larger is better. Material components already enforce it.
• iOS: Apple’s guidelines use 44×44 pt as the default tap size on iPhone.

Design to the platform numbers and the WCAG minimum takes care of itself. Remember that the touch target and the visible icon are different things: a small close icon is fine if its tappable frame is 44pt. In Figma, draw the hit area as its own transparent layer so developers can see it; in code, add padding and a contentShape in SwiftUI, or a 48dp minimum size with sizeIn in Jetpack Compose.

For text, the same Google guidance asks for a contrast ratio of at least 4.5:1 for text smaller than 18sp (or bold text smaller than 14sp) and 3:1 for other text. Check it in design and again on the device: text over photos, pale disabled states and dark-mode colours often break it after handoff. Never use colour alone to show an error, a selected tab or a required field. Add an icon, a label or a change in weight.

A screen reader announces three things for each element: its name (the label), what it is (a role or trait such as button, heading or switch) and its state (selected, disabled, 40%). Native controls provide all three for free. Custom controls provide none until a developer adds them.

The problems that come up most often in mobile audits:

• Icon-only buttons announced as “button” or by an image file name.
• Cards where every text fragment is a separate swipe stop.
• Custom toggles with no state, so the user cannot tell on from off.
• Toasts and inline errors that appear on screen but are never announced.
• Focus that jumps to the top when a sheet closes, instead of returning to the button that opened it.

Larger text is the setting many apps handle worst: truncated buttons, labels clipped by fixed-height containers, tab bars where words collide.

• Use the platform text styles (SwiftUI’s body, headline and the rest; sp units on Android) instead of fixed point sizes.
• Never give fixed heights to containers that hold text.
• At the largest sizes, switch horizontal layouts to vertical: label above value, buttons stacked.
• Do not switch off font scaling in Flutter or React Native to protect a layout. Cap a single oversized element if you must, never the whole app.

Designers can make this cheap by drawing the most text-heavy screens at the largest size during design, so reflow rules are decided before code. Our post on wireframes, mockups and prototypes shows where these annotations belong.

Every gesture needs a simple alternative

Swipe-to-delete, drag-to-reorder and long-press menus are fine as shortcuts, not as the only way to do something. Under WCAG 2.2’s Dragging Movements criterion, anything done by dragging must also work with a single pointer, so add a visible delete button or an edit mode, move-up and move-down actions, and zoom buttons on maps. VoiceOver and TalkBack custom actions can also offer Delete or Archive on a list item without any swipe.

Login without memory tests

In our projects, Accessible Authentication (Minimum) has the biggest product impact of the new AA criteria. Blocking paste into password fields, splitting a one-time code into six boxes that defeat autofill, and image puzzles all work against it. Support password managers and paste, mark fields so the system can autofill them (the one-time code content type on iOS, autofill hints on Android), and offer passkeys or Sign in with Apple and Google where they suit your users.

Treat accessibility as part of each two-week sprint: WCAG 2.2 AA in the definition of done, labels and roles built once into shared components, and the checklist above on every release candidate. If the app is already live, do not start with a full redesign. Audit sign-up, the core task, payment and account settings first, and fix labels, roles and announcements in shared components, which clears issues across many screens at once.

Where the audit shows that custom components are the root cause, replacing them with styled native controls is often cheaper than patching each one. That is the point where an accessibility fix becomes a mobile app redesign of specific flows. For EU-facing products, our page on app development outsourcing Germany covers how EAA questions are settled in discovery.