The European Accessibility Act began enforcement on June 28, 2025 — and for the first time in the EU, mobile apps are explicitly in scope alongside websites. In the US, the DOJ's Title II rule, finalized in 2024, formally confirmed that mobile applications must meet WCAG 2.1 AA, and private-sector lawsuits under Title III have been targeting apps for years based on precedent alone. Your mobile app is no longer a legal gray area.
The challenge is that most accessibility tools — the wcag compliance checker tools your team already uses for web — were built for browsers, not native apps. When you scan a website, tools like ADAGuard run against the live rendered DOM. When you test a native iOS or Android app, there is no DOM. You need to use the platform's own assistive technologies: VoiceOver on iOS and TalkBack on Android. This guide explains exactly how to do that.
Why WCAG 2.2 Applies to Mobile Apps (Even Native Ones)
In May 2025, the W3C published "Guidance on Applying WCAG 2.2 to Mobile Applications" (WCAG2Mobile), providing the first authoritative interpretation of how the web standard maps to native iOS and Android development. The document confirms that all 50 WCAG 2.2 Level AA criteria apply to mobile — adapted for touch targets, gestures, and platform-specific UI patterns.
Key criteria that require mobile-specific interpretation include:
- 2.5.3 Label in Name — on-screen label text must be contained in the accessible name
- 2.5.5 Target Size (AAA on web, but ADAGuard includes it) — minimum 44×44 points on iOS, 48×48dp on Android
- 2.5.8 Target Size (Minimum) — new in WCAG 2.2 — at least 24×24 CSS pixels with adequate spacing
- 1.4.3 Contrast (Minimum) — 4.5:1 for normal text in both light and dark mode
- 2.4.7 Focus Visible — focus indicators required on all interactive elements, including touch focus
Automated tools catch 20–40% of WCAG violations in mobile apps. The remaining 60–80% require screen reader testing — which is why VoiceOver and TalkBack matter.
iOS VoiceOver Testing: A Step-by-Step Workflow
VoiceOver is used by approximately 71% of mobile screen reader users. Enabling it on a real device (not just a simulator) is the only way to catch gesture conflicts, swipe-order issues, and focus trap bugs.
To enable VoiceOver on iOS: 1. Go to Settings → Accessibility → VoiceOver → toggle On 2. Or use the Accessibility Shortcut: Settings → Accessibility → Accessibility Shortcut → select VoiceOver (then triple-click the side button)
Core VoiceOver gestures to test: - Single-finger swipe right/left — moves to the next/previous element - Double-tap — activates the focused element - Two-finger swipe up — reads the entire screen from top - Three-finger swipe — scrolls
What to verify during VoiceOver testing:
Test every interactive element by navigating to it with swipes. For each element, listen for: Is the label meaningful? Does double-tapping trigger the expected action? Does a modal trap focus inside it? Does focus return to the trigger element when the modal closes?
Run VoiceOver through your app's most critical flows: authentication, onboarding, core task completion, and checkout (if applicable). A wcag compliance checker on your web admin panel won't surface the issues in your app's native screens — you need eyes (and ears) on the real device.
Android TalkBack Testing: A Step-by-Step Workflow
TalkBack is used by approximately 28% of mobile screen reader users. Because Android device implementations vary by manufacturer, test on at least two hardware types — a Samsung device and a stock Android (Pixel) device behave differently in meaningful ways.
To enable TalkBack on Android: 1. Go to Settings → Accessibility → TalkBack → toggle On 2. Or press Volume Up + Volume Down simultaneously (on most devices)
Core TalkBack gestures to test: - Swipe right — moves to next element - Swipe left — moves to previous element - Double-tap — activates focused element - Swipe down then right — opens TalkBack menu
What to verify during TalkBack testing:
The same focus-order and label checks apply. Pay special attention to custom views — Android's accessibility API requires that custom-drawn UI components explicitly set contentDescription and importantForAccessibility. Any component that uses canvas.draw* methods bypasses the standard view hierarchy and becomes invisible to TalkBack unless explicitly annotated.
Common WCAG 2.2 Failures in Mobile Apps
| Failure Type | WCAG Criterion | iOS VoiceOver Symptom | Android TalkBack Symptom | Fix Effort |
|---|---|---|---|---|
| Unlabeled icon buttons | 4.1.2 Name, Role, Value | VoiceOver says "button" with no label | TalkBack reads nothing or reads resource ID | Easy — add accessibilityLabel (iOS) / contentDescription (Android) |
| Keyboard trap in modal | 2.1.2 No Keyboard Trap | Cannot swipe out of modal | Focus cycles within modal indefinitely | Medium — scope focus to modal, restore on close |
| Touch target too small | 2.5.8 Target Size | Difficult to activate; no VoiceOver issue | Same | Easy — increase tap area via padding or hitTestInsets |
| Missing form labels | 1.3.1 Info & Relationships | VoiceOver reads placeholder text only | TalkBack reads "edit text" | Easy — associate label via accessibilityLabel |
| Color contrast failure | 1.4.3 Contrast Minimum | No symptom in screen reader | No symptom in screen reader | Medium — update color tokens |
| Focus not restored after modal close | 2.4.3 Focus Order | Focus drops to top of screen | Focus drops to unknown element | Medium — manually restore focus to trigger |
| Gesture-only interactions | 2.5.1 Pointer Gestures | Swipe-to-dismiss has no VoiceOver alternative | Same | Hard — provide explicit button alternative |
What to Do When You Find Violations
Mobile WCAG violations fall into two buckets: issues your developer can fix in the app code with a targeted update, and issues that require a ticket to a third-party SDK vendor with the specific WCAG criterion number and test reproduction steps.
Before your developer starts fixing, run an ADAGuard scan on your app's associated web properties — your marketing site, login page, and account portal — at adaguard.io. ADAGuard covers 22 automated check categories across WCAG 2.2 AA, catching contrast failures, unlabeled form fields, missing alt text, and ARIA errors in your web surfaces while your team handles the native app work in parallel.
When filing tickets for SDK vendors, include: the WCAG criterion number (e.g., "2.5.8 Target Size Minimum"), the platform (iOS/Android), the specific screen and interaction, and the screen reader behavior you observed. Vendors respond faster to criterion-specific reports than to vague "it's not accessible" descriptions.
Automated + Manual = Complete Coverage
Automated wcag compliance checker tools are not optional, but they are not sufficient. Use them to establish a baseline — catching the high-volume, easy-to-detect failures like missing alt text and contrast ratios. Then layer manual screen reader testing on top to surface the interaction-layer issues that automation will never see: focus traps, announcement order, gesture conflicts.
A practical testing cadence for mobile teams:
- Every PR: Run automated checks against any web surfaces touched (ADAGuard on the staging URL)
- Every sprint: One VoiceOver pass and one TalkBack pass through the sprint's changed flows on real devices
- Every release candidate: Full screen reader regression across all critical user paths
The EAA's enforcement is active, and the W3C's WCAG2Mobile guidance gives regulators a clear framework for evaluating mobile violations. If your app is in the EU market, enforcement isn't hypothetical — it's a matter of when, not whether.
The 30-Second Fix
You can check your app's web surfaces right now. Paste your URL at adaguard.io — no signup required — and get a full WCAG 2.2 AA accessibility report in under 30 seconds. ADAGuard's 22 automated check categories cover ~78% of detectable WCAG violations, giving you a baseline scan while your team schedules the VoiceOver and TalkBack rounds.