Building Accessible Mobile Apps: Lessons from a Real Audit
We considered ourselves reasonably good at accessibility going into a formal third-party audit for a healthcare client subject to ADA compliance requirements. The audit came back with 34 findings, and the gap between what we thought we'd covered and what an actual screen reader user encountered was humbling. VoiceOver and TalkBack testing by our own team, done by sighted engineers toggling the feature on briefly, had missed problems that only showed up in real extended use.
The single biggest category of findings was focus order. Our custom components — a multi-step form wizard and a card-based dashboard — had visually logical layouts that read in a confusing order to VoiceOver because we'd relied on view hierarchy order rather than explicit accessibility sorting. We fixed this using accessibilityElements ordering on iOS and explicit traversal groups with accessibilityTraversalBefore/After on Android, which required actually testing with eyes closed rather than just running an automated linter.
Automated tools (we use Accessibility Scanner on Android and Xcode's Accessibility Inspector) caught obvious things like missing labels and insufficient contrast, but they cannot catch semantic issues — a button labeled only 'icon' that automated tools accept because a label exists, even though it tells a screen reader user nothing useful. About half the audit's findings were of this semantic-but-technically-labeled variety, which is why we now require a manual pass with VoiceOver/TalkBack enabled for a full task flow, not just a labeling check.
Dynamic Type and font scaling broke more layouts than we expected. Several screens used fixed-height containers that clipped text at larger accessibility text sizes (up to 310% on iOS with the largest accessibility sizes enabled), because they'd only been tested at the default size. We now include the largest Dynamic Type setting and Android's largest font scale as a standard state in our QA test matrix, the same way we'd test a small-screen device.
Color contrast findings were the easiest fixes but the most numerous — 11 of the 34 findings were contrast ratios below WCAG AA on secondary text and disabled-state buttons that our design system hadn't audited closely. We now run every color token pairing in the design system through a contrast checker before it ships, not just the primary text-on-background combination.
Post-remediation, we built accessibility checks into our standard QA checklist rather than treating it as a pre-launch audit item, because the findings made clear that accessibility regresses quietly with every new feature unless someone is explicitly checking for it.
