A mobile accessibility app is judged by what the screen reader says out loud.
Two different people search for a mobile accessibility app. One wants an app that records whether a building, a venue or a service is usable. The other wants the app they are building to work for somebody using VoiceOver or TalkBack. This page takes the second problem first, because the first one cannot be solved by an app that fails at the second. For the rule by rule version, start with the app accessibility guidelines.
What follows is what the operating system actually reads on a React Native screen, the props that decide it, the contrast and target size numbers a mobile app gets measured against, and what an access survey app has to store if the answers are going to be worth anything a year later.
Hear what the screen reader would sayThe short version
Accessibility is not a screen you add, it is whether your controls have names.
Most accessibility failures in a mobile app are the same failure. A control is on screen, a sighted person can see it and tap it, and the screen reader has no name for it. It reaches the control and can say nothing useful about it. The only way left to find out what it does is to tap it and see what happens.
Fixing that is not a redesign. It is a short list of props on controls that already exist, plus two numbers about colour and size. Accessible app design on mobile is mostly discipline about naming things.
What the screen reader actually reads
React Native builds a separate tree for assistive technology, and your visual layout is not it. By default, all touchable elements are accessible, which is the part most apps rely on without knowing. If a Pressable contains text, the name is assembled for you: the label is constructed by concatenating all Text node children separated by spaces. A button reading Delete draft already announces Delete draft.
Which is exactly why icon buttons are where apps break. A Pressable holding only a bin icon has no Text children, so there is nothing to concatenate, and the reader arrives at an element it cannot name. That is the job of accessibilityLabel, and it is the highest value prop in the whole API. Real screen reader app support is mostly four props: accessible, accessibilityLabel, accessibilityRole and accessibilityState.
accessibilityRole says what kind of thing it is, from a fixed documented list that includes button, link, header, image, imagebutton, switch, checkbox, tab, alert and progressbar. accessibilityState carries the current condition through disabled, selected, checked, busy and expanded. accessibilityHint adds what will happen: VoiceOver reads it after the label if the user has hints enabled in settings, while TalkBack reads it after the label and hints cannot be turned off on Android.
One prop causes as many problems as it solves. Marking a view accessible makes that view the thing focus lands on, and in the documented example focus is available on the child carrying the prop rather than on the parent or the sibling without it. Wrap a whole card in it and the controls inside stop being separately reachable, so use it to group static content and never around something tappable.
React Native, Accessibility props and platform support
Try it
What the screen reader would say
One icon button, five things you can set on it. Switch them on and read what a person using VoiceOver actually gets.
(nothing worth saying)
No label and no Text child leaves nothing to announce. The control is reachable and unidentifiable, and that is the failure this whole page is about.
The numbers a WCAG mobile app gets measured against
WCAG 2.2 is a W3C Recommendation and the dated version is 12 December 2024. It is written for web content, so an app is measured against it by interpretation rather than by a clause that names React Native. Two of its criteria translate cleanly onto a phone screen, and they are the two people get wrong.
Contrast first. Success criterion 1.4.3 requires a contrast ratio of at least 4.5:1 for text, with an exception for large scale text and images of large scale text at 3:1. Large scale means at least 18 point, or 14 point bold. Light grey captions on a white card are the usual failure, and they fail for everyone in sunlight, not only for people with low vision.
Then target size. Criterion 2.5.8 Target Size (Minimum) is new in WCAG 2.2 at Level AA and asks for a target of at least 24 by 24 CSS pixels. The older 2.5.5 Target Size (Enhanced) sits at Level AAA and asks for 44 by 44. Mapping CSS pixels onto density independent points on a phone is the interpretation, and 44 is the safer figure to design to, because a finger is not a mouse pointer.
Neither of these needs a tool to find. A contrast ratio is a pair of colours and a target is a padding value, so both can be settled before the first screen is written rather than found in an audit afterwards.
Where iOS and Android stop agreeing
The props do not all exist on both platforms, and the split is documented. accessible, accessibilityLabel, accessibilityRole, accessibilityHint, accessibilityState, accessibilityValue and accessibilityActions are cross platform. importantForAccessibility, accessibilityLiveRegion and accessibilityLabelledBy are Android only. accessibilityElementsHidden, accessibilityViewIsModal, onAccessibilityTap and accessibilityLanguage are iOS only.
A modal is where that bites. On iOS you stop the reader wandering behind a sheet with accessibilityViewIsModal, and the usual Android equivalent is importantForAccessibility on the views underneath. Same intent, two different props, and a codebase that sets only one has a real bug on the other platform that no simulator screenshot will show you.
Testing is the part almost nobody does, and it needs no tooling. Turn VoiceOver on, swipe through every screen and listen: anything that announces with no name is a bug, and anything you cannot reach at all is a worse one. Then do the same pass with TalkBack, because the two trees are built by different code. This applies to whatever you ship, not to some special category. An employee self service app whose payslip control is an unnamed icon is unusable, and so is an alumni engagement app where the donate button announces nothing.
When the app is the accessibility record
The other meaning of the phrase is an app that records accessibility itself: an access audit of a building, a venue guide for wheelchair users, a site survey against a standard. These get built badly for one consistent reason, which is that a tick box per feature is not a usable record.
A survey entry needs the thing checked, the criterion it was checked against, the measured value where one exists, a photo, the date and who checked it. A doorway is a width in millimetres, not a yes. A ramp has a gradient. A lift either takes a wheelchair with a companion or it does not. Whoever reads the record in a year needs to know which measurement was taken and when, because buildings get refitted and standards move.
Offline comes next, and it is not optional. Surveys happen in basements, stairwells and car parks, so a form that posts on submit will lose an afternoon of work. Write each entry to local storage as it is filled in, sync when there is signal, and keep the photo attached to its entry rather than in a separate upload queue that can finish first and orphan the file.
And the record has to be readable by the people it is about. An access audit app that fails its own screen reader pass is not an irony, it is the whole thing backwards.
What each approach to accessibility actually finds
| Approach | Finds unnamed controls | Judges if the name is useful | Catches contrast and target size | Cost per release |
|---|---|---|---|---|
| Stock components, no props added | No | No | No | nothing spent, nothing found |
| Labels and roles written by hand | where you looked | Yes | No | minutes per screen |
| Lint rule or automated scanner | Yes | No | contrast, sometimes | runs in CI |
| A VoiceOver and TalkBack pass | Yes | Yes | by feel | one pass per screen |
| Audit by an accessibility specialist | Yes | Yes | Yes | days, and paid |
Building one without a specialist on the team
Accessibility is cheap at the start and expensive later, and that is the whole argument. Naming an icon button while you are writing it costs seconds. Retrofitting names onto a finished app after a complaint costs a sprint, and you will still miss the modals, the focus order and the empty states.
Newly is an AI app builder. You describe the app, 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 out: iOS through TestFlight and App Store Connect with your own Apple Developer account, Android to Google Play internal testing from the Deploy tab, and a standalone production APK with the JavaScript bundled if you want one. Its build rules tell the generator to put accessibilityLabel on icon only buttons and on images, accessibilityRole on pressables, hold body text at 4.5:1 and keep touch targets at 44px. That is a sensible default, not an audit. Nothing runs a screen reader over your screens and signs them off, so the VoiceOver pass stays yours. It costs $25 a month and there is no free plan.
Before planning a release around any of it, read what Apple checks at review, because accessibility and App Store review are two different lists and it helps to know which one can actually hold a build back.
Questions people ask about mobile accessibility apps
The phrase covers two things. One is an app built so that people using a screen reader, large text or switch control can operate it, which is a property of every app rather than a category. The other is an app whose subject is accessibility: an access audit tool, a venue guide, a survey app that records whether a place or a service is usable. The second only works if it also does the first.
Describe the app, including who has to be able to use it
Say what the screens do and say that every control needs a name and a role, then do one VoiceOver pass before anybody else sees it.
Start building