Mobile App Accessibility: WCAG 2.2 Requirements for iOS and Android

<p>Over <strong>72% of adults with disabilities own a smartphone</strong>, and according to one survey, roughly 86% of screen reader users rely on a mobile device — a higher share than desktop or laptop users. Yet the same organizations that audit their websites religiously often have mobile apps that have never been tested against a single accessibility criterion. That gap is closing fast, driven by evolving regulation, growing litigation, and — most importantly — the W3C's own guidance explicitly mapping WCAG 2.2 to native iOS and Android applications.</p> <h2>Why WCAG 2.2 Applies to Your Mobile App</h2> <p>There is a persistent myth that WCAG is a web-only standard. It is not. <strong>W3C does not have separate guidelines for mobile accessibility</strong> — instead, mobile accessibility is addressed within the existing WCAG framework, and the W3C's Mobile Accessibility Task Force (MATF) has produced dedicated guidance titled <em>Guidance on Applying WCAG 2.2 to Mobile Applications (WCAG2Mobile)</em> that maps every Level A and AA success criterion to native mobile apps, mobile web apps, and hybrid apps.</p> <p>The practical implication is significant. When you read a WCAG success criterion that refers to a "web page," the WCAG2Mobile document replaces that language with "screen" or "view." When a criterion discusses a "user agent," it means the mobile operating system. The four POUR principles — Perceivable, Operable, Understandable, Robust — translate directly to how a user interacts with a SwiftUI view in iOS or a Jetpack Compose layout on Android.</p> <p>From a legal standpoint, the pressure is no longer theoretical. Under Title II of the ADA, updated DOJ regulations released in April 2024 explicitly require state and local governments to make their mobile applications accessible at WCAG 2.1 AA. Healthcare organizations accepting Medicare or Medicaid face similar requirements under HHS rules finalized in May 2024. And although private-sector mobile app lawsuits are still less frequent than website suits, at least one high-volume plaintiff has specifically targeted mobile applications for lack of equitable access under the ADA, with that trend expected to accelerate as Title II compliance timelines arrive in 2026.</p> <p>The European Accessibility Act (EAA), which came into force on 28 June 2025 and relies on EN 301 549 as its presumptive technical standard, also requires conformance with WCAG 2.2 for digital products and services including mobile apps sold or offered in EU markets. For any organization with a global user base, WCAG 2.2 on mobile is not a future aspiration — it is a present obligation.</p> <h2>What Changed in WCAG 2.2 That Matters Most for Mobile</h2> <p>WCAG 2.2, published as a W3C Recommendation in October 2023, adds nine new success criteria and removes the now-obsolete 4.1.1 Parsing. It is fully backwards-compatible: conforming to 2.2 implies conformance to 2.1 and 2.0. Several of the new criteria were written with mobile interaction patterns explicitly in mind, and even those framed around keyboard use have direct analogues in assistive technology for iOS and Android.</p> <p>It is worth understanding the lineage here. After 2018, the Mobile Accessibility Task Force ensured that mobile considerations shaped both WCAG 2.1 and 2.2. Criteria like <strong>1.3.4 Orientation (AA)</strong>, <strong>1.4.10 Reflow (AA)</strong>, <strong>2.5.1 Pointer Gestures (A)</strong>, <strong>2.5.4 Motion Actuation (A)</strong>, and the new <strong>2.5.7 Dragging Movements (AA)</strong>, <strong>2.5.8 Target Size Minimum (AA)</strong>, and <strong>3.3.7 Redundant Entry (A)</strong> all reflect specific mobile usability patterns that were identified through real-world testing with users with disabilities on smartphones and tablets.</p> <p>The nine new success criteria introduced in WCAG 2.2 target specific barriers that real users encounter: login flows that punish anyone with memory issues, interfaces that demand steady hands for precise taps, help features buried on different parts of every screen, and focus indicators that disappear behind sticky navigation bars. Each criterion patches a concrete hole — and nearly all of them have a direct mobile application.</p> <h2>The New WCAG 2.2 Criteria and How They Apply to iOS and Android</h2> <h3>2.5.8 Target Size Minimum (Level AA)</h3> <p>This is arguably the most impactful new criterion for mobile teams. It requires that interactive targets — buttons, links, form fields, checkboxes, toggles — have a minimum size of <strong>24 × 24 CSS pixels</strong>, or that a 24-pixel spacing offset exists between adjacent targets if the target itself is smaller. The rationale is straightforward: users with hand tremors, Parkinson's disease, or limited dexterity find it genuinely impossible to reliably hit a 16-pixel icon button, and even users without disabilities make significantly more errors on small targets.</p> <p>For native mobile development, WCAG 2.2's 24 × 24 minimum is actually a floor, not a ceiling. Apple's Human Interface Guidelines recommend a minimum touch target of <strong>44 × 44 points</strong> on iOS and iPadOS. Google's Material Design recommends <strong>48 × 48 density-independent pixels (dp)</strong> on Android. If your app meets Apple's or Google's platform guidance, you already exceed the WCAG 2.2 minimum — but many apps do not. Those tiny close buttons on modal sheets, the hairline checkboxes in settings screens, and the icon-only toolbar actions that measure 20 × 20 dp are all compliance failures waiting to be surfaced in an audit.</p> <p>A practical note: WCAG's requirement is about the <em>interactive hit area</em>, not the visual size of the icon. A 16-point icon wrapped in 14 points of padding on each side has an effective tap target of 44 × 44 points. This means developers can satisfy the criterion without visually enlarging elements — but they must deliberately set that padding, not rely on the system to do it automatically.</p> <h3>2.5.7 Dragging Movements (Level AA)</h3> <p>This criterion requires that any functionality implemented via a dragging gesture — sliders, drag-and-drop reordering, pull-to-refresh, carousel scrubbing — must also be achievable through a single-pointer action that does not require dragging. On iOS and Android, the platform's own assistive technologies handle certain gestures differently, but the app itself must expose non-drag alternatives for any custom drag behavior it implements.</p> <p>In practice, this means a drag-to-reorder list must offer an alternative such as an "up/down" stepper button. A custom range slider that only responds to a drag gesture must also respond to taps on specific points or provide increment/decrement buttons. The criterion does not apply if the underlying OS or assistive technology provides the alternative automatically, but developers should test this explicitly rather than assuming it will always be handled for them.</p> <h3>2.4.11 Focus Not Obscured — Minimum (Level AA) and 2.4.12 (Enhanced, Level AAA)</h3> <p>These criteria address a pattern that is extremely common in both web and native mobile apps: the focused element being partially or fully hidden by sticky UI — a persistent bottom navigation bar, a floating action button, a top toolbar that overlaps the scroll area. The minimum criterion (Level AA) requires that when a component receives focus, at least part of it remains visible. The enhanced version (Level AAA) requires the entire focused component to be visible.</p> <p>For native mobile, "keyboard focus" is interpreted broadly to include the focus ring used by Switch Control or Switch Access, Full Keyboard Access (iOS 15+), and Voice Control/Access. An app where the focused element slides beneath a bottom navigation bar during a Switch Control sweep fails this criterion, even though there is no physical keyboard involved. App UI should avoid obscuring focused controls with author-created overlays, sticky bars, or transient surfaces.</p> <h3>2.4.13 Focus Appearance (Level AA)</h3> <p>This criterion sets minimum requirements for the visual characteristics of the focus indicator: it must have a minimum area equivalent to the perimeter of the component × 2 CSS pixels, and a contrast ratio of at least 3:1 against adjacent colors. On native mobile platforms, the focus ring for VoiceOver and TalkBack is controlled by the operating system, and developers cannot change what it looks like — which means developers are generally granted an exception for this specific criterion. However, app styling must not actively reduce focus visibility by, for example, overlaying a translucent scrim over focused controls.</p> <h3>3.3.8 Accessible Authentication — Minimum (Level A)</h3> <p>This criterion represents a major step for cognitive accessibility. It requires that authentication processes do not rely solely on a cognitive function test — meaning the user must not be required to memorize a password, solve a puzzle, or transcribe a CAPTCHA — unless the app provides an accessible alternative. On iOS, this means supporting Apple's Keychain and Sign in with Apple to let users authenticate without memorizing credentials. On Android, it means supporting Google's Autofill framework, biometric authentication, and not blocking the use of third-party password managers.</p> <p>More concretely: if your app blocks paste actions in password fields, it is likely non-compliant with 3.3.8. If your two-factor authentication flow requires the user to manually type an OTP code from a notification without providing a copy-paste mechanism, it introduces an unnecessary cognitive burden. Android's Messages app already provides a "copy code" button in OTP notifications for exactly this reason — aligning platform behavior with the intent of the criterion.</p> <blockquote><strong>Key insight:</strong> Supporting biometric authentication (Face ID, Touch ID, Android Biometric API) is not just a UX enhancement — it is a WCAG 2.2 compliance mechanism for users with cognitive disabilities who cannot reliably recall passwords.</blockquote> <h3>3.3.7 Redundant Entry (Level A)</h3> <p>If a multi-screen flow in your app — checkout, onboarding, a healthcare intake form — asks the user to enter the same information more than once, you must either auto-populate the previously entered value or offer a way to select it from previous input. This criterion is directly applicable to native mobile apps. The classic failure mode is a shipping address form that later asks for a billing address with no "same as shipping" option, forcing users with motor impairments or cognitive disabilities to re-type the same text multiple times.</p> <h3>3.2.6 Consistent Help (Level A)</h3> <p>If your app provides a help mechanism — a support chat button, a help icon, a "contact us" link — it must appear in a consistent location across all screens within the app. Users with cognitive disabilities rely on predictable placement of navigation and support mechanisms. Placing the help button in the header on some screens and in the tab bar on others, or burying it inside a settings menu on certain flows, violates this criterion.</p> <h2>WCAG 2.1 Criteria That Remain Critical for Mobile</h2> <p>The new WCAG 2.2 criteria get most of the attention, but several WCAG 2.1 requirements that were introduced specifically with mobile in mind are still routinely failed in native apps, and compliance managers should not overlook them during audits.</p> <p><strong>1.3.4 Orientation (AA)</strong> prohibits locking an app to portrait or landscape orientation unless that orientation is essential to the content's function. Many apps lock to portrait during onboarding flows or in-app video players without justification. This disproportionately affects users with wheelchairs-mounted devices that cannot be rotated. <strong>1.4.10 Reflow (AA)</strong> requires that content can be presented without horizontal scrolling when displayed at 320 CSS pixels wide (the equivalent of 400% zoom), which in mobile terms means supporting Dynamic Type and system text size scaling without breaking layout or truncating content.</p> <p><strong>2.5.1 Pointer Gestures (A)</strong> requires that any functionality that uses multipoint or path-based gestures — a pinch-to-zoom, a two-finger swipe — also has a single-pointer alternative. <strong>2.5.4 Motion Actuation (A)</strong> requires that functionality triggered by shaking or tilting the device can also be operated through standard UI controls, and that users can disable motion-based triggers to avoid accidental activation.</p> <p>For visual presentation, <strong>1.4.3 Contrast Minimum (AA)</strong> requires a ratio of at least 4.5:1 for normal text and 3:1 for large text. Many apps still fail here because placeholder text in input fields, disabled button labels, and text on photographic backgrounds fall below the minimum. Developers should ensure all copy, controls, and content work with Dynamic Type, Bold Text, dark mode, and system-level contrast options on both iOS and Android.</p> <h2>Platform-Specific Implementation Guidance</h2> <h3>iOS and SwiftUI / UIKit</h3> <p>Apple provides extensive native accessibility support through the UIAccessibility API and, in SwiftUI, through accessibility modifiers. For VoiceOver support, every interactive element must have a meaningful accessibility label, hint, and value. Custom controls that do not inherit from standard UIKit components must explicitly adopt an appropriate accessibility trait — <code>.isButton</code>, <code>.isHeader</code>, <code>.isLink</code> — so that VoiceOver announces them correctly. The Xcode Accessibility Inspector can help surface missing labels and trait mismatches during development.</p> <p>For Dynamic Type, UIKit's <code>UIFont.preferredFont(forTextStyle:)</code> and SwiftUI's <code>.font(.body)</code> system fonts automatically scale with the user's preferred text size. Hard-coded font sizes in points that do not use <code>scaledValue(for:)</code> will fail 1.4.4 Resize Text. For target sizes, you can expand the tappable area of a small icon using <code>contentEdgeInsets</code> in UIKit or the <code>.contentShape()</code> modifier in SwiftUI without changing the visual presentation of the element.</p> <pre><code>// SwiftUI: expand tap area without changing visual size Image(systemName: 'xmark') .frame(width: 20, height: 20) .contentShape(Rectangle().size(CGSize(width: 44, height: 44))) .accessibilityLabel('Close') .accessibilityAddTraits(.isButton) </code></pre> <h3>Android and Jetpack Compose / Views</h3> <p>Android's accessibility is surfaced through the AccessibilityNodeInfo API, which TalkBack and Switch Access consume. In Jetpack Compose, the <code>Modifier.semantics</code> block lets you set content descriptions, roles, state descriptions, and merge descendant semantics. For View-based UIs, <code>ViewCompat.setAccessibilityDelegate()</code> allows programmatic manipulation of accessibility properties on any view.</p> <p>For touch target sizing, the Material Design guidance recommends 48 × 48 dp minimum. If a composable or view is visually smaller, you can use <code>Modifier.minimumInteractiveComponentSize()</code> in Compose (introduced in Material3) to automatically enforce a 48 dp minimum, or wrap a small view in a <code>TouchDelegate</code> to expand its hit area in the legacy View system. For text scaling, ensure all text sizes are specified in <code>sp</code> (scale-independent pixels), not <code>dp</code>, so they respect the user's font size preferences set in Android's Display settings.</p> <pre><code>// Jetpack Compose: accessible icon button with minimum size IconButton( onClick = { onClose() }, modifier = Modifier .minimumInteractiveComponentSize() // enforces 48dp minimum .semantics { contentDescription = 'Close dialog' } ) { Icon( imageVector = Icons.Default.Close, contentDescription = null // described by parent ) } </code></pre> <h2>Testing Your App Against WCAG 2.2</h2> <p>Testing mobile accessibility requires a combination of automated tooling and manual testing with real assistive technologies. Automated tools — including Deque's axe DevTools Mobile, Google's Accessibility Scanner for Android, and Apple's Accessibility Inspector in Xcode — can catch missing labels, insufficient contrast, and touch targets that fall below platform minimums. However, automated tools catch only a fraction of real accessibility issues. Manual testing with VoiceOver on iOS and TalkBack on Android is essential to verify correct reading order, meaningful labels, and logical focus management across complex flows.</p> <p>For WCAG 2.2-specific criteria, manual testing is especially important. To test 2.5.8 (Target Size), use your actual finger — not a mouse cursor in the iOS Simulator — to attempt interactions on small controls. To test 3.3.8 (Accessible Authentication), verify that your login flow allows paste in password fields, supports password managers (1Password, Bitwarden, system keychain), and supports biometric authentication. To test 2.4.11 (Focus Not Obscured), navigate your app entirely via Switch Control on iOS or Switch Access on Android, and confirm that no focused element disappears behind a navigation bar, modal overlay, or floating button.</p> <blockquote>A comprehensive accessibility test plan should include testing on at least two physical devices — one iPhone and one Android device — at the user's default font size and at the maximum system font size, with VoiceOver and TalkBack enabled respectively. Simulator-only testing will miss real-world rendering differences and assistive technology behavior.</blockquote> <p>Consider building accessibility checks into your CI/CD pipeline. Both Espresso (Android) and XCUITest (iOS) support writing automated UI tests that verify accessibility properties — content descriptions, traits, and enabled states — so that regressions are caught before code is merged rather than discovered in a production audit.</p> <h2>The Legal and Business Case for Acting Now</h2> <p>Beyond the moral imperative of inclusion, the business case for mobile accessibility is concrete. Companies that lead in disability inclusion generate 1.6 times more revenue and 2.6 times more net income than industry peers. People with disabilities in the U.S. hold nearly half a trillion dollars in disposable income. And given that 69% of disabled online consumers abandon apps and websites they find difficult to use, every accessibility barrier is a conversion that never happens.</p> <p>The legal risk is escalating. Lawsuits targeting companies with digital accessibility failures continue to grow year over year. The DOJ's adoption of WCAG as the technical standard for ADA compliance, Title II enforcement deadlines in 2026, and the EAA's June 2025 entry into force collectively create a multi-jurisdictional compliance requirement that now explicitly encompasses native mobile applications. A prior WCAG 2.1 audit does not automatically demonstrate WCAG 2.2 conformance — authentication flows, form fields, interactive components, and focus management all need re-evaluation against the nine new success criteria.</p> <p>Critically, accessibility in mobile is not a feature that can be retrofitted cheaply after launch. Addressing WCAG failures in a shipped app means updated assets, rebuilt components, revised layouts, re-tested flows, and potentially refactored authentication systems. Teams that build WCAG 2.2 compliance into their design systems and component libraries from the start — enforcing minimum touch target sizes, contrast tokens, semantic roles, and authentication patterns at the component level — pay a fraction of the cost compared to remediating an inaccessible app post-launch.</p> <h2>Key Takeaways</h2> <ul> <li><strong>WCAG 2.2 applies to native iOS and Android apps.</strong> The W3C's WCAG2Mobile guidance maps every Level A and AA success criterion to mobile screens and views, meaning your native app is in scope — not just your mobile website.</li> <li><strong>Touch target size is the most common new failure in mobile audits.</strong> WCAG 2.2's 24 × 24 minimum is the floor; Apple recommends 44 × 44 pt and Google recommends 48 × 48 dp. Expand hit areas with padding and platform-native APIs, not by visually enlarging icons.</li> <li><strong>Blocking paste in password fields likely violates 3.3.8 Accessible Authentication.</strong> Support system keychains, password managers, biometrics, and OTP auto-fill to meet the cognitive accessibility requirements for login flows on both platforms.</li> <li><strong>Manual testing with VoiceOver and TalkBack is non-negotiable.</strong> Automated tools catch only a fraction of accessibility issues. Test on physical devices at maximum font size, with assistive technologies enabled, across every critical user journey.</li> <li><strong>Build accessibility into your design system now, not after launch.</strong> Remediating inaccessible apps post-launch is far more expensive than enforcing accessible component standards from day one. With DOJ, HHS, and EAA enforcement timelines arriving in 2025–2026, the window for low-cost compliance work is closing.</li> </ul>