Accessibility in a mobile app is thirty four props and one audit, not a library you install.

Which accessibility props does React Native actually document?

Thirty four, with two more in a separate section for actions. The page lists them in one long run and the table of contents at the bottom is the complete set, which makes it easy to count: nineteen of them work on both platforms, ten carry an iOS tag and five carry an Android tag. Many of the names come in pairs, because React Native supports both its own spelling and an ARIA-style alias. accessibilityLabel and aria-label do the same job, as do accessibilityState and the separate aria-checked, aria-disabled, aria-expanded, aria-busy and aria-selected props.

The one to understand properly is accessible. React Native says it marks a view as discoverable by assistive technology, and that on Android it becomes the native focusable while on iOS it becomes isAccessibilityElement. It also warns that setting it true does not guarantee the screen reader will focus the view, because VoiceOver disallows nested accessibility elements and TalkBack may choose to focus a parent instead. That single sentence explains most of the confusion people hit when a label they set is never read out: the element is nested inside another accessible element and the outer one wins.

Roles are where the long lists live. accessibilityRole takes 29 documented values and the newer role prop takes 28, and React Native says role takes precedence when a component has both. Both lists are careful about one distinction worth repeating: link is for elements that open a URL or a web page in a browser, and anything navigating between screens inside your app should be a button. The grid value exists for ScrollView, FlatList, VirtualizedList and SectionList, which matters once a list gets long enough to need add infinite scroll and a screen reader has to announce entering and leaving it.

React Native, Accessibility, last updated 19 October 2026, read 22 October 2026

Does Apple publish a minimum tap target size?

It does, in the Human Interface Guidelines, and the number is not the one in circulation. The accessibility page of the HIG carries a table under the advice to offer sufficiently sized controls, with a column for the default control size and a column for the minimum control size on each platform. For iOS and iPadOS the default is 44x44 pt and the minimum is 28x28 pt. So when somebody tells you Apple requires 44 points, what they have is the size a standard control already comes out at. The floor Apple asks you to respect is smaller, and the wording around it is strive to meet, not must.

Apple says the same thing a second way elsewhere, which is probably where the confusion starts. The HIG page on buttons states that as a general rule a button needs a hit region of at least 44x44 pt, or 60x60 pt in visionOS. Both statements are Apple's, they were written for different purposes, and 44x44 is the figure to design to while 28x28 is the figure to defend if a control genuinely cannot be bigger. React Native's own number is different again: its View component reference, discussing the hitSlop prop, says typical interface guidelines recommend touch targets of at least 30 to 40 points or density-independent pixels.

Spacing gets a figure too, and it is the one people skip. The same HIG page says to treat the gap between controls as being as important as their size, and suggests roughly 12 points of padding around elements that have a bezel, and roughly 24 points around elements that do not. A row of unbezelled icon buttons crammed together passes a size check and still gets mistapped. hitSlop is how you fix a small control in React Native without redrawing it, and the View docs add one catch: the touch area never extends past the bounds of the parent view, so padding a tiny button inside a tiny container buys you nothing.

The HIG also asks for alternatives to gestures, and gives the example of a swipe that dismisses a view needing a button that does the same job. Worth holding on to when you reach for a gesture that has no visible control at all, which is exactly the shape of add pull to refresh. If pulling down is the only way to get fresh data, somebody who cannot perform that gesture cannot refresh your app.

Apple, Human Interface Guidelines, Accessibility, change log last dated 9 June 2025, read 22 October 2026

Does App Review check whether VoiceOver works?

No, and it is worth being precise about this because the answer gets overstated in both directions. We pulled the App Store Review Guidelines, which carry their own last-updated line of 16 October 2026, and searched the text. VoiceOver appears zero times. Screen reader, Dynamic Type, tappable, tap target, touch target and the number 44 appear zero times each. The word accessibility appears only in phrases like keeping backend services accessible during review, in the requirement for an easily accessible privacy policy, and once as a subject in guideline 3.2.1(ii), which concerns apps that recommend collections of third-party apps for an approved need.

One clause comes close without giving you a number. Guideline 2.5.18 requires interstitial ads to provide easily accessible and visible close or skip buttons large enough for people to easily dismiss the ad. That is as close as the document gets to sizing a control, and it is written in words rather than points. The guidelines also end their submission checklist by telling you to check whether your app follows guidance in other documentation, and the list they give includes the Human Interface Guidelines and App Store Connect Help.

App Store Connect Help is where accessibility becomes a thing you are accountable for. Its page on Accessibility Nutrition Labels describes a section of your product page where you declare support for nine 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 you will be required to share accessibility support details to submit new apps and app updates. It gives no date for that, so treat any deadline you see quoted as somebody's guess.

The bar for ticking one of those nine is higher than it looks. Apple's wording is that to indicate support for a feature, people must be able to complete all of the common tasks of your app using it, and it tells you to write down what your common tasks are before you start evaluating. Each feature has its own criteria page. Larger Text, for instance, is described as increasing text size in the app to 200 percent or more, and the label is not offered on Mac. Apple adds that review guideline 2.3 on accurate metadata applies to these answers and that App Review can contact a developer and ask them to update misleading labels, which is the only route by which accessibility reaches a reviewer. The rest of the submission is covered in publish to app store. Both pages here were read on 22 October 2026.

Apple, Human Interface Guidelines, Accessibility, on evaluating your interface and the labels, read 22 October 2026

How do you check it before you ship?

Turn the screen reader on and try to do one real task with your eyes off the screen. That is the whole test, and it takes about five minutes per screen. React Native documents where the switches are. On iOS or iPadOS, Settings, then General, then Accessibility, then VoiceOver under Vision. There is also an Accessibility Shortcut at the bottom of those settings that toggles VoiceOver with a triple click of the Home button. On Android, Settings, then Accessibility, then TalkBack, then the Use service switch, or hold both volume keys for three seconds once you have enabled the volume key shortcut.

Two gotchas that cost people an afternoon each. VoiceOver is not available in the iOS Simulator at all, and React Native points you at Accessibility Inspector in Xcode to drive macOS VoiceOver through your app instead, while adding that a real device is always better because macOS VoiceOver can behave differently. And Android emulators do not ship with TalkBack, so you need an emulator image that includes the Play Store and then install TalkBack from it. React Native also gives the adb command that flips the service directly if you would rather script it.

Newly writes a real React Native and Expo project that you own, so every prop on this page is one you can set in the code it produces, and two-way GitHub sync means an accessibility pass is an ordinary commit rather than a request to a vendor. It uploads iOS builds to TestFlight, publishes to Google Play internal testing and builds a standalone Android APK, which matters here because the real test runs on a phone and not in a simulator. It costs $25 a month and there is no free tier. It does not press submit on the App Store for you, since Apple requires the owner of the content to submit, and the Accessibility Nutrition Labels are part of what you fill in when you do.

One last piece of advice, from having watched this go wrong. Do not book an accessibility sprint for the end. A label written months after the button it describes is a guess about what the button does now, and React Native's own instruction is to keep descriptions up to date as your interface and content change. Write the label in the same commit as the control, keep hit areas at 44 points because that is what a standard control already is, and the audit at the end turns into a read-through instead of a rewrite.

React Native, Accessibility, on testing TalkBack and VoiceOver support, read 22 October 2026