Most app accessibility guidelines reduce to a dozen numbers and one habit.
Nearly every list of app accessibility guidelines is a rewording of one document: the Web Content Accessibility Guidelines, now at version 2.2. Strip the commentary and what is left is a handful of measurable thresholds, a rule about naming things, and a rule about never letting colour be the only signal. This page is the accessibility part of a wider app development guide, and it stays on what you can actually check on a screen.
Four things follow: the success criteria that decide most of a phone screen, whether any of this formally applies to a native app, why screen reader support is mostly a naming problem, and what happens to your layout when somebody doubles the text size.
See the numbers that decide itThe short version
The rules are published and free, and the numbers are the short version.
WCAG 2.2 at level AA is what almost everyone means by accessible. The parts that bite a mobile screen are a pointer target of at least 24 by 24 CSS pixels, a contrast ratio of at least 4.5:1 for ordinary text and 3:1 for large text, 3:1 for the visible parts of controls, no locking to a single orientation unless it is essential, and content that still works at 320 CSS pixels of width.
The other half is not a number. Every control needs a name a screen reader can read out, every state needs to be exposed rather than merely drawn, and nothing important can be carried by colour alone. Those three habits find more real problems than any scanner.
The criteria that decide most of a mobile screen
WCAG 2.2 is a finished W3C Recommendation, and the version published on w3.org carries the date 12 December 2024. It is organised as success criteria at three conformance levels, A, AA and AAA. Level AA is the practical target, and these are the criteria that come up over and over on a phone.
Target size, criterion 2.5.8, is level AA: the target for pointer inputs is at least 24 by 24 CSS pixels, with exceptions where the target is inline in text or where it is a user agent control the author has not restyled. Criterion 2.5.5 asks for 44 by 44 CSS pixels and sits at level AAA, which is where the familiar 44 figure comes from. Android's own guidance recommends a focusable area of at least 48dp by 48dp, so a design that follows the platform has already cleared level AA with room spare.
Contrast, criterion 1.4.3, is level AA: 4.5:1 for text and images of text, relaxing to 3:1 for large text, which the criterion defines as 18 point, or 14 point when bold. Criterion 1.4.11 then asks for 3:1 between a user interface component or a meaningful graphic and the colours next to it. That is the one people miss. A pale grey border on a text field can fail while the text inside it passes comfortably.
Three more break easily on mobile and are cheap to fix. Criterion 1.3.4 Orientation, level AA, says do not restrict the view to one display orientation unless a specific orientation is essential. Criterion 1.4.10 Reflow, level AA, says content has to present at 320 CSS pixels of width without losing information and without a second scrolling direction. Criterion 2.5.4 Motion Actuation, level A, says anything triggered by tilting or shaking the device must also work through a normal control, and the motion response must be possible to switch off.
W3C, Web Content Accessibility Guidelines 2.2
Try it
Check one control against two criteria
The contrast threshold slides with text size. The target size threshold does not. Put in the numbers from your own design.
Contrast fails, target size fails
At this size criterion 1.4.3 asks for 4.5:1 and you have 3.2:1. Criterion 2.5.8 asks for 24 by 24 CSS pixels at level AA and you have 20. Level AAA asks for 44 by 44, which is where the familiar 44 point rule of thumb comes from.
Does WCAG really apply to a native app
Worth being straight about this, because a lot of pages are not. WCAG is written for web content. W3C's own bridge to phones, Guidance on Applying WCAG 2.2 to Mobile Applications, is a Group Draft Note published on 6 May 2025, and it says of itself that it is informative guidance that does not set requirements. It walks the level A and AA criteria as they apply to native apps, mobile web apps and hybrid apps. So the mapping exists, it is official, and it is not normative.
In practice that changes very little. The laws, procurement rules and audit tools that cover apps point back at WCAG, and the criteria translate cleanly enough that arguing about scope costs more than fixing the labels would. Which law actually binds you depends on where you sell and what the app does, and that is a question for a lawyer rather than a guide like this one. Nobody has ever lost an argument by conforming to level AA.
The stores are a separate and softer gate. Review is mostly checking other things, which is what the app store requirements cover. Apple has since added Accessibility Nutrition Labels to App Store product pages, where you declare whether your app supports nine named features: VoiceOver, Voice Control, Larger Text, Dark Interface, Differentiate Without Color Alone, Sufficient Contrast, Reduced Motion, Captions and Audio Descriptions. Apple says providing the labels is voluntary to start, and that over time developers will be required to share accessibility support details to submit new apps and app updates.
App screen reader support is a naming problem
VoiceOver on iOS and TalkBack on Android read a screen out one element at a time. What they read is whatever name, role, state and value that element exposes. An icon button with no name gets announced as "button", which tells the listener nothing at all, and a tab bar of five of them is a wall of nothing.
In a React Native project the fields are already named for you. accessibilityLabel is the name. accessibilityRole is what kind of thing it is. accessibilityState carries disabled, selected, checked, busy and expanded. accessibilityValue carries a number or a range. accessibilityHint explains what will happen if you activate it. Android adds accessibilityLiveRegion for content that changes on its own and importantForAccessibility for elements a screen reader should skip. iOS adds accessibilityViewIsModal and accessibilityElementsHidden, which are how you stop VoiceOver wandering out of an open sheet into the screen behind it. On Android native the same job is done by contentDescription.
Where this goes wrong is state, and it usually traces back to the data rather than the view. If a row's status lives as a colour name, there is nothing sensible to announce and you end up writing announcement strings by hand in every component. Modelling status as a value with a human label, which is ordinary mobile app database design, means the spoken string and the pixel colour both derive from one field instead of being invented twice.
Then actually use it. Turn VoiceOver on, look away from the phone, and try to finish the main task in your app by listening. It takes two minutes, it needs no tooling, and it finds the class of bug no scanner can see: the screen that is technically labelled and still impossible to operate in order.
Accessible mobile design breaks at 200 percent text
The most common failure in accessible mobile design is not contrast, it is a layout that quietly assumed a font size. Both platforms let people scale text far past the default, and Apple's own description of the Larger Text feature is increasing the text size in the app to 200 percent or more. At that scale fixed height rows clip their last line, two column grids collide, and a button with a set height hides its own label.
The fixes are structural rather than cosmetic. Let containers grow with their content instead of pinning a height. Let a row become two lines when it needs to. Take sizes from the system text scale rather than hard numbers. Reflow, criterion 1.4.10, is the same problem approached from the other side: at 320 CSS pixels of width nothing important should require horizontal scrolling, so test the narrow case and the large text case together.
Two habits close the gap. Never carry meaning in colour alone, so a red field border needs a message beside it and a green dot needs a word. And respect the reduce motion setting, because the parallax transition that reads as polish to you is motion sickness to somebody else. Both of these are choices made once in a shared component, not a hundred times in screens.
What each way of checking actually catches
| How you check | Missing labels | Low contrast | Targets under 24 pixels | Whether the task can be finished |
|---|---|---|---|---|
| Automated scanner in the build | Yes | Yes | sometimes | No |
| Contrast tool on the palette | No | Yes | No | No |
| Turn on VoiceOver or TalkBack | Yes | No | you feel it | Yes |
| Every screen at 200 percent text | No | No | No | for reading |
| Someone who uses a screen reader daily | Yes | Yes | Yes | Yes |
Building it in rather than adding it later
Retrofitting accessibility is expensive because names, roles and states have to be threaded back through components that were written without them, and because the layout decisions that break at large text are the ones buried deepest. Adding the same things while each screen is first written costs close to nothing. That is the entire argument, and it is why the useful moment to read a page like this is before the second screen exists.
Newly is an AI app builder: you describe the app in plain English, it writes a real React Native and Expo project you own, runs it on a cloud iPhone or Android simulator while it builds, and ships it to TestFlight and to Google Play internal testing. Because the output is an ordinary React Native codebase, which you pull down with npm i -g @newly/cli and then newly pull, every accessibility prop above is yours to set directly. It costs $25 a month, there is no free plan, and iOS distribution needs your own Apple Developer account.
Ask for labels, roles and states in the description and you will get most of them. Then check the screens yourself, because no generator knows which of your two grey buttons is the destructive one. If you would rather see these criteria as a working product than as a checklist, here is an accessible app in practice.
Questions people ask about app accessibility
On WCAG, the Web Content Accessibility Guidelines from W3C, currently version 2.2. Almost every checklist, law and store policy you will meet is a restatement of it. Level AA is the normal target, and on a phone the criteria that matter most are target size, text and non-text contrast, orientation, reflow, motion actuation, and exposing a name, role, state and value for every control.
Pick one screen and check it against the numbers
Take the busiest screen in your app, measure the targets and the contrast, then listen to it with the screen reader on. Fix what you hear, and build the next screen with the labels already in place.
Start building