Dev Diary: Why We Chose React Native: Accessibility Over Everything
A behind-the-scenes look at how we build 3mpwrApp.
When we started 3mpwrApp, we had a hard constraint: the framework had to support real, deep accessibility  VoiceOver, TalkBack, Switch Access, and the full spectrum of assistive technology  from day one, not as an afterthought.
React Native was the answer because it exposes the native accessibility APIs of both iOS and Android directly. A web-based hybrid approach would have meant fighting the underlying layer. React Native meant working with it.
The Expo ecosystem accelerated this enormously. Expo Router’s file-based navigation is inherently screen-reader-transparent. The community has deep accessibility expertise. We didn’t have to build the foundations  we stood on good ones.
Technical Details
- React Native exposes native VoiceOver, TalkBack, and Switch Access APIs directly
- One codebase for iOS, Android, and web prevents accessibility quality divergence
- Expo Router’s file-based navigation is transparent to screen readers by design
- React Native’s animation system supports reduced motion preferences natively
- Expo’s a11y linting caught issues before any human tester saw them
In Practice
- VoiceOver and TalkBack integration required native API access that web-only frameworks couldn’t provide
- Switch Access compatibility was built in from day one using React Native’s focus management APIs
- Accessibility scanning in CI caught regressions before they reached beta testers
What We Learned
- Framework choice is an accessibility decision, not just a technical preference
- Building cross-platform from the start prevents future divergence in accessibility quality
- The open-source React Native community’s accessibility depth accelerated our work enormously
Follow Our Development
We believe in building in public  the community we serve has been failed by opaque institutions too many times.
- â GitHub
- 🧪 Join Beta Testing
- 💬 Community Discussion