So you’re ready to audit your app for accessibility? Love to see it.
But here’s a key question we always ask first:
“How was your app built?”
Because the way your app is built directly affects how you audit for accessibility, and what kinds of issues are even possible.
Native? Web-wrapped? Flutter? React Native?
Each one comes with its own quirks, tools, and landmines.
This article breaks it down. No fluff. No bias. Just real insights into what to look for, how to test it, and how to actually fix it, based on your tech stack.
Let’s go.
1. 🧱 Web-Wrapped Apps (a.k.a. “The Website-in-a-Box”)
Examples: Cordova, Ionic, WebView-based apps
What they are:
You built a responsive web app, then wrapped it in a mobile shell to get it into the App Store.
What breaks:
- Accessibility issues from the web version leak into mobile
aria-labels might not read properly in screen readers- Layouts don’t adapt well when zoomed
- Tap targets are often too small
How to test:
- Run both web and mobile audits
- Use Lighthouse + AXE for web accessibility
- Then test on actual phones with VoiceOver (iOS) and TalkBack (Android) to catch mobile-specific issues
What’s tricky:
These apps look like mobile apps, but behave like websites, and often fail both worlds if not built carefully.
2. 🔄 Cross-Platform Apps (Flutter, React Native, Xamarin, etc.)
Examples: Most apps made with budget in mind but needing native features
What they are:
One codebase that compiles to both iOS and Android. Efficient? Yes. Tricky for accessibility? Also yes.
What breaks:
- Inconsistent behavior between platforms
- Some components don’t expose themselves properly to screen readers
- Focus order can get weird if custom navigation is used
- You may fix an issue on iOS… and break it on Android
How to test:
- Test on both platforms separately
Flutter especially needs physical device testing, emulators miss subtle things - Use platform-native tools (VoiceOver + TalkBack)
- Tap every interactive element and verify:
- It can be reached
- It reads out loud correctly
- It makes sense out of context
Pro tip:
Use platform-specific wrappers or accessibility bridges to make sure React Native/Flutter elements behave like true native ones.
3. 🍏📱 Native Apps (Swift, Objective-C, Kotlin, Java)
Examples: Custom-built apps for iOS/Android from the ground up
What they are:
You’re building straight from the SDK. Maximum power, maximum flexibility.
What breaks:
- Custom components that skip native accessibility hooks
- Missing
accessibilityIdentifiers orcontentDescriptions - Animations with no “reduce motion” fallback
- Unintentionally locked views (screen readers can’t escape modals or nav bars)
How to test:
- Use real devices with platform tools:
- VoiceOver rotor on iOS
- Accessibility Scanner on Android
- Manually navigate the app like a user with no sight or fine motor control
- Check things like:
- Logical swipe order
- Button grouping
- Dynamic content announcements
- Response to font resizing
What’s great:
Native gives you full control, which means you can fix almost anything… if you know what’s wrong.
TL;DR: Here’s the Stack-to-Audit Playbook
| App Type | What to Watch For | Testing Tools |
|---|---|---|
| Web-Wrapped (Cordova/Ionic) | Inherited web issues, broken touch targets | Lighthouse, AXE, VoiceOver, TalkBack |
| Cross-Platform (Flutter, React Native) | Inconsistent behavior, focus order, labeling gaps | Manual testing, platform screen readers |
| Native (Swift, Kotlin) | Custom views, modals, missing identifiers | Accessibility Inspector, real device tests |
The Smart Move? Audit Based on How You Built It
Most accessibility audits fail because they assume every app is the same.
They’re not.
Your tech stack determines how issues show up, and how to fix them.
That’s why we tailor our accessibility audits based on:
- How your app was built
- What devices and OS versions you support
- What kinds of real citizens use your app (vision, mobility, tech literacy)
Want Help? We’ll Tailor the Audit to You
If you’re not sure what kind of audit you need, just ask.
We’ll do a quick review, figure out how your app was built, and run the right kind of audit for it.
👉 Book a free accessibility audit: customized to your app’s architecture
P.S. Already read our starter guide?
This is part two. If you missed part one, check out Making Mobile Apps Accessible: How Our Audits Help Public Sector Teams Comply and Improve for the why behind all this.