Accessibility in React Native: A Practical Checklist

Turn on VoiceOver or TalkBack, close your eyes and try to sign in to your app. Many apps fail at the first screen: the screen reader announces "button, button, image", the password field has no label, and the error message appears silently in red where nobody listening can find it. None of it is hard to fix. It's just invisible until you try.

React Native has solid accessibility support built in, and most of the work is using it consistently. This practical checklist covers React Native accessibility from labels and roles to text scaling, touch targets, contrast, focus, motion, forms and testing, mapped to WCAG 2.2 where it applies.

Key takeaways

• Every interactive element needs a role and a label; icon-only buttons are a frequent failure.
• Let text scale. Never turn off font scaling globally, and test layouts at the largest sizes.
• Touch targets of at least 44 by 44 points on iOS and 48 by 48 dp on Android help everyone, not only users with motor impairments.
• Meet contrast ratios (4.5:1 for normal text) and never rely on colour alone.
• Announce changes such as errors and loading results, and respect reduced motion settings.
• Test with real screen readers on both platforms, and automate what you can in component tests.

Why it matters, and why now

The World Health Organization estimates that 1.3 billion people, about one in six, experience significant disability, and many more use accessibility settings such as larger text, bold text or reduced motion every day. Accessible apps reach more users and usually work better for everyone, for example one-handed or in bright sunlight. There's a legal side too: the European Accessibility Act has applied since 28 June 2025 to many consumer products and services, including e-commerce, banking and transport services, with mobile apps for those services in scope. WCAG 2.2 is the current version of the guidelines most regulations and contracts point to.

Labels, roles and states

Screen readers announce three things about each element: what it is (role), what it's called (label) and what condition it's in (state). React Native supports both its older accessibility* props and ARIA-style props such as role and aria-label.

<Pressable
  onPress={onToggleFavourite}
  role="button"
  aria-label="Favourite"
  aria-selected={isFavourite}
  accessibilityHint="Saves this class to your favourites"
  hitSlop={12}
>
  <HeartIcon filled={isFavourite} />
</Pressable>

• Label icon-only buttons with what they do ("Favourite", "Close", "Search"), not what they look like ("Heart icon").
• Use roles (button, link, header, checkbox, switch, tab, image) so users know how to interact.
• Expose state: selected, checked, disabled, expanded and busy.
• Group related content (accessible on a container) so a card reads as one item rather than six fragments.
• Hide decorative elements from screen readers.

Text that scales

Users set larger text sizes in iOS and Android settings, and React Native respects them by default.

• Don't disable font scaling globally. If a specific element truly can't grow, cap it with maxFontSizeMultiplier rather than turning scaling off.
• Design layouts that wrap: avoid fixed heights on text containers, and let rows become columns at large sizes.
• Test at the largest accessibility text sizes on both platforms. Truncated buttons and overlapping text show up immediately.

Touch targets and gestures

• Minimum sizes: Apple's guidelines recommend at least 44 by 44 points, and Android's at least 48 by 48 dp. WCAG 2.2 sets a lower minimum of 24 by 24 CSS pixels at level AA.
• Use hitSlop to enlarge the touchable area of small icons without changing the layout.
• Offer alternatives to complex gestures. Swipe-to-delete or drag-to-reorder need a button or accessibility action too, which also satisfies WCAG 2.2's dragging movements criterion. React Native supports custom accessibility actions for exactly this.

Colour and contrast

• Text contrast: at least 4.5:1 for normal text and 3:1 for large text (WCAG level AA).
• UI components and icons that convey meaning need at least 3:1 against their background.
• Never use colour alone to show errors, status or selection; add text or an icon.
• Check dark mode separately. A palette that passes in light mode can fail in dark.

Focus, order and announcements

• Reading order follows the component tree, so structure screens in a logical order rather than repositioning elements visually.
• Modals should contain focus: use aria-modal (or accessibilityViewIsModal) on iOS so the screen reader doesn't wander behind the dialog, and return focus sensibly when it closes.
• Announce dynamic changes such as "3 results found", form errors or "Saved" using AccessibilityInfo.announceForAccessibility or live regions.
• Mark headings with the header role, so screen reader users can jump between sections.

Moving focus where it should be

After navigation, an error or a dialog opening, screen reader focus should land somewhere useful, such as the new screen's heading or the error message. Move it with AccessibilityInfo.sendAccessibilityEvent, which replaces the deprecated setAccessibilityFocus:

const headingRef = useRef<Text>(null);

useEffect(() => {
  if (headingRef.current) AccessibilityInfo.sendAccessibilityEvent(headingRef.current, "focus");
}, []);

// <Text ref={headingRef} accessible role="header">Payment failed</Text>

The target must be accessible. Use focus moves sparingly: moving focus on every render is as disorienting as never moving it.

Motion

Animations can cause discomfort for users with vestibular disorders. Check AccessibilityInfo.isReduceMotionEnabled() or Reanimated's useReducedMotion hook, and replace large movement, parallax and auto-playing animation with simple fades or no animation when it's on.

Forms and errors

• Every input needs a label that stays visible; a placeholder disappears as soon as the user types.
• Errors should be specific, announced and attached to the field they describe, not just shown in red.
• Support autofill and password managers with the right autoComplete and textContentType values. WCAG 2.2's accessible authentication criterion discourages making users remember or transcribe codes and passwords without help.
• Don't time out forms without warning and a way to extend.

From the field: WCAG accessibility is part of the standard I build React Native and web apps to, alongside performance work such as holding stable 60fps animation. In practice, accessibility issues are cheapest to fix when the component library gets them right once: an accessible button, input and card used everywhere fixes hundreds of screens at a time.

Testing accessibility

1. Screen readers: run your main flows with VoiceOver on iOS and TalkBack on Android before every major release.
2. Platform tools: Xcode's Accessibility Inspector and Google's Accessibility Scanner app flag missing labels, small targets and contrast problems.
3. Component tests: React Native Testing Library's getByRole and getByLabelText queries fail when roles and labels are missing, so good tests double as accessibility checks.
4. Linting: an accessibility ESLint plugin catches common mistakes in code review.
5. Real users: if accessibility matters to your market or contracts, test with people who use assistive technology every day.

The checklist

• Every interactive element has a role and a meaningful label.
• States (selected, checked, disabled, expanded) are exposed.
• Decorative images are hidden; meaningful images are described.
• Text scales, and layouts survive the largest sizes.
• Touch targets meet platform minimums.
• Contrast meets 4.5:1 for text and 3:1 for UI components.
• Colour is never the only signal.
• Modals contain focus; headings are marked.
• Errors and dynamic changes are announced.
• Reduced motion is respected.
• Inputs have visible labels and support autofill.
• Main flows tested with VoiceOver and TalkBack.

FAQ

How do I make a React Native app accessible?

Give every interactive element a role and label, expose states, let text scale, meet touch target and contrast minimums, announce dynamic changes, respect reduced motion, and test your main flows with VoiceOver and TalkBack. Building these into shared components fixes most screens at once.

Does React Native support screen readers?

Yes. React Native maps its accessibility props, including ARIA-style props such as role and aria-label, to VoiceOver on iOS and TalkBack on Android. Labels, roles, states, hints, custom actions and announcements are all supported.

What WCAG level should a mobile app meet?

WCAG 2.2 level AA is the usual target, and it's what most regulations and contracts reference. Laws such as the European Accessibility Act apply to many consumer services, including their mobile apps, so check which rules apply in your markets.

How do I test accessibility in React Native?

Use VoiceOver and TalkBack on real devices for your main flows, run Xcode's Accessibility Inspector and Android's Accessibility Scanner, query by role and label in component tests, add an accessibility lint plugin, and test with assistive technology users when you can.

Next steps

If you need an accessibility review of your React Native app, or want accessible components built into your design system from the start, I can help. Get in touch, or see my services.

Sources

• Accessibility, React Native docs
• Web Content Accessibility Guidelines (WCAG) 2.2, W3C
• Disability fact sheet, World Health Organization
• Accessibility, Apple Human Interface Guidelines
• Make apps more accessible, Android Developers
• European Accessibility Act, European Commission
• useReducedMotion, Reanimated docs