React Native Accessibility Checklist: Screen Readers, Focus, Contrast, and Dynamic Type

Overview

This is a working React Native accessibility checklist, not a theory piece. The goal is simple: help you ship interfaces that remain usable with VoiceOver, TalkBack, larger text sizes, keyboard-like navigation patterns, and reduced visual assumptions.

In React Native, accessibility problems often come from ordinary UI decisions: wrapping text in touchable containers without labels, building custom buttons that do not expose the right role, opening a modal without moving focus, or hard-coding text sizes that break when users increase system font scale. None of these issues are dramatic in isolation, but together they make an app harder to navigate and trust.

A useful rule is to review accessibility at three levels:

• Component level: Does a button, input, image, or card expose the correct semantics?
• Screen level: Is the reading order logical, and can a user complete the main task without visual guesswork?
• Flow level: Do navigation, authentication, forms, errors, toasts, and modals behave clearly across the whole app?

If your team already has a design system, treat this checklist as an extension of that system. The more accessibility decisions you bake into shared react native components, the less rework you will need later.

Checklist by scenario

Use these scenario-based checks during development and before each release. They are grouped by the places where accessibility regressions usually appear.

1. Interactive elements: buttons, links, cards, toggles

• Make sure every interactive element is actually exposed as interactive. Custom wrappers should not behave like buttons visually while remaining anonymous to assistive tech.
• Set clear accessibility labels when visible text is missing, abbreviated, or ambiguous.
• Use accessibility roles where appropriate, such as button, link, switch, checkbox, tab, or header.
• Provide accessibility state for selected, checked, disabled, expanded, or busy conditions.
• Avoid nested touchables that create confusing focus stops or duplicate announcements.
• Ensure tap targets are comfortably sized and spaced. Tiny icons are a common failure point.
• Do not rely on color alone to communicate state. Pair color with text, icon shape, or explicit state messaging.

A common example is a settings row that opens a detail screen. If the entire row is pressable, the row should expose a single, clear label and role rather than forcing the screen reader to read several decorative child elements one by one.

2. Text, headings, and reading order

• Preserve a logical visual and reading hierarchy. Screen titles should be identifiable and easy to reach.
• Use headings consistently so long screens are easier to scan with screen readers.
• Keep text concise where possible. Very long labels make screen reader navigation slower.
• Make sure adjacent labels and values are grouped sensibly. Users should hear content in the order it makes sense.
• Do not split one sentence across multiple decorative text nodes unless you have a good reason. Fragmented announcements can sound unnatural.

This also matters for list rows and summary cards. If a product card, profile card, or order summary is meant to be scanned quickly, its announcement should be short, predictable, and not overloaded with repeated decoration.

3. Forms, validation, and error messaging

• Every input should have a persistent label, not just a placeholder.
• Use placeholders as hints, not as the only identifier.
• Mark required fields clearly and consistently.
• Associate validation messages with the relevant field as closely as possible.
• When validation fails, move the user to the first problem in a predictable way and announce what happened.
• Ensure error text remains visible and understandable at larger font sizes.
• For password fields, OTP inputs, and custom pickers, test both semantics and focus transitions carefully.

Form screens are one of the best places to combine accessibility and product quality. If your team is refining validation patterns, it is worth pairing this checklist with React Native Forms Compared: React Hook Form, Formik, and Zod Validation Patterns.

4. Screen reader support: VoiceOver and TalkBack

• Test key flows with both iOS and Android screen readers. Similar UI can behave differently across platforms.
• Listen to full announcements, not just whether an element receives focus.
• Check that icons, badges, counters, and decorative images are either meaningfully labeled or hidden from announcement when purely decorative.
• Confirm that loading states, success messages, and destructive actions are announced at the right time.
• Review swipe order for the entire screen. A correct layout can still produce a confusing reading sequence.
• Make sure repeated controls have distinguishing labels, such as separate “Edit billing address” and “Edit shipping address” actions.

This is where many react native screen reader issues surface: duplicate labels, unlabeled icon buttons, and announcements that are technically present but not useful in context.

5. Focus management for navigation, modals, and overlays

• When a new screen opens, make sure the user lands in a sensible place, usually the screen title or the first primary element.
• When a modal or bottom sheet opens, move focus into it.
• When the modal closes, return focus to the element that triggered it when possible.
• Prevent focus from drifting to background content while an overlay is active.
• For snackbars, toasts, and banners, avoid stealing focus unnecessarily, but ensure important updates are announced.
• Review back navigation and dismiss gestures so users do not lose context.

React native focus management deserves explicit testing anytime you add custom navigation patterns, bottom sheets, or layered UI. Teams using advanced navigation stacks should also review their screen transitions alongside React Native Testing Strategy: Unit, Integration, and E2E Tools Compared.

6. Dynamic type and text scaling

• Verify that text respects user font scaling unless you have a strong, deliberate reason not to.
• Test common screens at larger accessibility sizes, not just one step above default.
• Check line wrapping, truncation, clipped buttons, and broken row heights.
• Make sure input fields, chips, tabs, and segmented controls can grow without overlapping or becoming unreadable.
• Prefer flexible layouts over fixed heights for text-heavy components.
• Review empty states, onboarding slides, and permission prompts, which often have tightly constrained copy.

Many teams treat react native dynamic type as a text-only concern, but layout resilience is the real challenge. Large text often exposes hidden assumptions in spacing, alignment, and button width.

7. Color contrast, themes, and dark mode

• Check text contrast against every supported background, including disabled and placeholder states.
• Review icon contrast, border contrast, and focus indicators, not just body text.
• Test success, warning, and error colors in both light and dark themes.
• Make sure selected and unselected states remain distinct without relying only on subtle tint changes.
• Recheck contrast after brand refreshes or token updates.

If your app supports theming, accessibility review should be part of theme QA. For a broader implementation guide, see How to Build Dark Mode in React Native: Themes, System Sync, and Design Tokens.

8. Lists, feeds, and virtualized content

• Ensure list items expose stable and understandable labels.
• Avoid making users swipe through excessive decorative metadata before reaching the main action.
• Confirm infinite loading states and refresh controls are announced clearly.
• When list content updates dynamically, avoid disorienting jumps in focus.
• Test long lists for both performance and readability. Accessibility can degrade when virtualization interacts poorly with focus.

Large feeds and catalog screens deserve extra care, especially if you are balancing speed and semantics. For rendering tradeoffs, see React Native FlatList and FlashList Benchmarks: When to Use Each.

9. Media, maps, camera, and non-text content

• Provide useful labels for meaningful images and hide purely decorative visuals from assistive tech.
• Offer text alternatives or summaries when charts, maps, or visual previews carry important information.
• For camera and scanning flows, label controls clearly and announce status changes such as permission denial or capture success.
• Do not assume gestures alone are discoverable. Offer visible and accessible fallback actions where possible.

These flows often combine permissions, overlays, and highly visual feedback. Related implementation details are covered in React Native Camera Libraries Compared: Expo Camera, VisionCamera, and Native Options and React Native Maps Guide: Google Maps, Apple Maps, Clustering, and Performance Tips.

10. Authentication, notifications, and app events

• Make sign-in and sign-up flows readable and predictable with screen readers.
• Ensure OTP, magic link, and passkey-related status messages are announced clearly.
• Review push notification entry points so the destination screen has a sensible initial focus target.
• Check permission prompts and post-permission guidance for accessible wording.

Authentication and notifications are high-friction moments, so small accessibility defects can block the whole flow. If those areas are active in your roadmap, review How to Add Authentication to React Native: Email, OAuth, Magic Links, and Passkeys and React Native Push Notifications Guide: Expo Notifications vs Firebase vs OneSignal.

What to double-check

Before merging a feature or cutting a release, run through these higher-value checks again. They catch many issues that slip past normal UI review.

• The accessible name matches the visible name. If a button says “Save” visually but announces “Submit form now,” users may be confused when teammates refer to it during support or QA.
• Custom components preserve semantics. Design system wrappers often accidentally swallow labels, roles, or states.
• Modals and bottom sheets trap attention appropriately. Focus should move in, remain sensible while open, and return on close.
• Error summaries do not replace field-level guidance. Users need both a top-level signal and local context.
• Large text does not cause hidden actions. A clipped primary button is easy to miss in visual QA if testers use default font settings.
• Dark mode and high-contrast combinations still work. Tokens that look fine in Figma can fail on real devices.
• Loading and success states are announced once, not repeatedly. Over-announcing status changes can be as disruptive as not announcing them.
• Platform differences are reviewed explicitly. A control that sounds right in VoiceOver may expose weaker semantics in TalkBack, or vice versa.

If you are building with Expo, it is also useful to align your accessibility checks with your chosen workflow and update cadence. See Expo vs React Native CLI: Which Setup Makes Sense in 2026? for setup context.

Common mistakes

Most accessibility regressions in React Native come from repeatable patterns. If your team knows these in advance, reviews become much faster.

• Using placeholders as labels. Once the field has content, the identifier disappears.
• Making entire complex cards pressable without curating the spoken output. The result is often noisy and redundant.
• Disabling text scaling to protect layouts. This hides a design problem instead of solving it.
• Relying on color alone for validation or selection. This affects both accessibility and general clarity.
• Forgetting accessible names on icon-only buttons. Search, close, filter, share, and back buttons are common misses.
• Ignoring focus after navigation changes. Users can land in the wrong place or lose context entirely.
• Shipping one accessible screen inside an inaccessible flow. Accessibility must hold from entry point to completion.
• Testing only with static mock data. Real-world content lengths often expose broken order, overlap, and truncation.
• Assuming a third-party UI library handles everything. Libraries can help, but they still need app-level review and sensible defaults.

If you use shared state or custom abstractions heavily, accessibility bugs can also spread widely from one wrapper. That is another reason to keep reusable primitives small, inspectable, and well-tested. Teams evaluating architecture choices may find it useful to pair accessibility review with component ownership and state boundaries, as discussed in Best React Native State Management in 2026: Redux Toolkit, Zustand, Jotai, and Context.

When to revisit

Treat this checklist as a living document. Accessibility is not finished after the first audit, because the riskiest changes usually happen later: new design tokens, navigation refactors, component library swaps, or last-minute content additions.

Revisit the checklist in these moments:

• Before seasonal planning cycles when teams reshuffle priorities and older screens get touched again.
• When workflows or tools change, such as moving between Expo and a custom native setup, replacing a form library, or adopting a new navigation pattern.
• After design system updates, especially typography, spacing, color, or component API changes.
• Before major releases, including onboarding refreshes, authentication overhauls, and settings redesigns.
• When adding new content-heavy locales, since longer strings can break both layout and spoken clarity.
• After bug reports from real users, because one report often points to a broader pattern.

A practical release habit is to pick five critical journeys and test them the same way every time: app launch, sign-in, one core task, one form submission, and one settings or account flow. Run those journeys with screen reader enabled, larger text enabled, and both light and dark mode where relevant. Document failures in component terms so the fix improves more than one screen.

If you want this checklist to stay useful, turn it into a shared QA artifact. Add it to pull request templates, story acceptance criteria, and pre-release notes. Accessibility improves fastest when it is visible early, reviewed calmly, and revisited whenever the product changes.