A mature web accessibility programme does not automatically cover your mobile app — and a web accessibility audit using tools like axe or WAVE won’t catch a single issue inside a native app, because native apps don’t have a DOM to scan in the first place.
Web accessibility is governed by WCAG directly; native apps run on platform APIs — iOS’s VoiceOver and Android’s TalkBack — that implement the same principles differently.
Web scanners like axe and WAVE test the DOM; native apps need platform-specific tools such as Xcode’s Accessibility Inspector and Android’s Accessibility Scanner.
WCAG 2.1 added mobile-specific success criteria — motion actuation, target size, orientation — explicitly meant to apply across both contexts.
Teams that run a mature web-accessibility programme often assume it covers their mobile app too — it doesn’t. WCAG’s principles, perceivable, operable, understandable and robust, apply conceptually to native mobile apps, but the actual implementation runs through entirely different APIs, and a web accessibility audit using tools like axe or WAVE won’t catch a single issue inside a native iOS or Android app, because those apps don’t have a DOM to scan.
| Dimension | Web Accessibility | Mobile (Native App) Accessibility |
|---|---|---|
| Governing standard | WCAG applies directly to web content — HTML, CSS, ARIA. | WCAG’s principles apply, but implementation runs through platform APIs — iOS Accessibility/VoiceOver and Android’s Accessibility Service/TalkBack — that don’t map one-to-one onto web ARIA patterns. |
| Assistive technology | Screen readers (JAWS, NVDA, VoiceOver-on-web), browser zoom, browser-level contrast tools. | Platform screen readers (VoiceOver, TalkBack), platform-level text sizing and display accommodations, switch control. |
| Testing tools | Automated scanners — axe, WAVE, Lighthouse — catch a meaningful share of common issues directly in the DOM. | Native UI elements aren’t DOM-based — testing needs platform tools, such as Xcode’s Accessibility Inspector or Android’s Accessibility Scanner, and can’t rely on web scanners at all. |
| Common failure points | Missing alt text, poor focus order, insufficient color contrast, unlabeled form fields. | Unlabeled custom UI controls (icon-only buttons with no accessible name), touch targets below platform minimums, gestures with no accessible alternative. |
| Legal / compliance anchor | WCAG 2.1/2.2 AA, referenced directly by ADA case law and the EAA’s EN 301 549. | Covered under the same legal frameworks (ADA, EAA), but platform accessibility guidelines are the practical implementation reference. |
| Remediation approach | Fix markup, ARIA attributes and CSS directly in the codebase causing the issue. | Fix accessibility labels, roles and touch targets in native UI code — often requiring platform-specific knowledge the web team doesn’t have. |
The conceptual groundwork transfers even though the technical implementation doesn’t. A team that already understands why alt text, focus order and contrast matter for web content can apply the same reasoning to native accessibility labels, VoiceOver and TalkBack navigation order, and touch target sizing. WCAG 2.1 explicitly added success criteria aimed at this overlap — motion actuation, target size, orientation lock — recognizing that mobile and web accessibility needed to converge conceptually even where implementation details diverge.
Treat native mobile accessibility as its own testing stream, not an extension of web QA. Use platform-specific tools — Xcode’s Accessibility Inspector for iOS, Android’s Accessibility Scanner for Android — alongside manual testing with VoiceOver and TalkBack. Train native developers on platform accessibility APIs directly rather than translating web ARIA knowledge, since the implementation patterns genuinely differ even where the underlying principles are shared.
Its principles apply conceptually, and some success criteria, such as target size and motion actuation, were written with mobile in mind, but there’s no direct technical mapping — native apps are tested against platform accessibility APIs, not WCAG’s web-specific techniques.
No — tools like axe, WAVE and Lighthouse scan the DOM, which native iOS and Android apps don’t have. Native apps need platform-specific tools like Xcode’s Accessibility Inspector or Android’s Accessibility Scanner.
Apple recommends at least 44x44 points on iOS; Google recommends at least 48x48 density-independent pixels on Android — both meaningfully larger than many default web click targets.
No — they’re tested, implemented and remediated separately, even though both are ultimately covering the same legal and user-need ground.