Mobile App Accessibility Under ADA Title II & Title III: Fixes Every US Organization Needs in 2026

When organisations think about ADA compliance, they almost always think about their website. But in 2026, mobile applications are squarely in scope — and most organisations are not ready. The DOJ's Title II rule explicitly covers mobile apps that provide access to government services, and Title III courts have consistently ruled that apps offered by private businesses qualify as places of public accommodation. Mobile app accessibility lawsuits grew 35% in 2025, and the trajectory for 2026 is steeper.

Why Mobile Apps Are Now a Legal Target

• Title II (Government)— The DOJ's April 2024 rule explicitly states that “mobile applications” used to access services, programs, or activities of state and local government entities must meet WCAG 2.1 Level AA.
• Title III (Private businesses)— Courts in multiple circuits have held that apps from businesses offering goods or services are covered under Title III. The Domino's Pizza ruling in 2019 set the precedent, and subsequent cases have reinforced it.
• Lawsuit growth— Mobile app ADA lawsuits increased 35% in 2025 compared to 2024. Plaintiff firms are now systematically testing popular apps with VoiceOver and TalkBack to identify targets.

Common Mobile Accessibility Failures

Based on our audits of iOS and Android applications across government, healthcare, finance, retail, and education, these are the most frequently encountered barriers:

Screen Reader Failures

• Buttons and icons without accessible labels — screen readers announce them as “button” with no context
• Images used as links or actions with no alt text
• Custom UI components that are not exposed to the accessibility API (role, state, and value missing)
• Dynamic content updates (loading indicators, error messages) not announced to assistive technology
• Incorrect reading order — screen reader focuses elements in a confusing sequence

Touch and Motor Accessibility Failures

• Touch targets smaller than 44×44 points (iOS) or 48×48dp (Android)
• Swipe-only gestures with no alternative action (e.g., swipe to delete without a button)
• Drag-and-drop functionality with no single-tap alternative
• Timeouts that do not warn users or allow extension
• Gestures that require multi-finger or precise path movements

Visual and Cognitive Failures

• Low colour contrast on text, icons, and interactive elements
• Text that does not scale when users increase their system font size
• Animations and motion that cannot be disabled (can trigger vestibular disorders)
• Error messages that only use colour (red field borders) without text explanation
• Complex navigation structures without consistent patterns between screens

WCAG Applied to Mobile: What You Must Test

WCAG 2.1 and 2.2 were specifically designed to address mobile and touch accessibility. The criteria that matter most for native apps include:

• 1.3.4 Orientation (AA)— Content must not restrict display to a single orientation (portrait or landscape) unless essential.
• 2.5.1 Pointer Gestures (A)— Multi-point or path-based gestures must have single-pointer alternatives.
• 2.5.7 Dragging Movements (AA, new in 2.2)— Drag-and-drop must be achievable via a single pointer without dragging.
• 2.5.8 Target Size (AA, new in 2.2)— Interactive targets must be at least 24×24 CSS pixels with adequate spacing.
• 1.4.4 Resize Text (AA)— Text must be resizable up to 200% without loss of content or functionality. Native apps must respect system-level font size settings.
• 1.4.10 Reflow (AA)— Content must reflow at 320px width without horizontal scrolling (applies to web views within apps).

Testing Tools for Mobile Accessibility

Effective mobile accessibility testing combines automated scanning with manual assistive technology testing:

• iOS— VoiceOver (built-in screen reader), Accessibility Inspector (Xcode), Switch Control.
• Android— TalkBack (built-in screen reader), Accessibility Scanner app (Google), Switch Access.
• Cross-platform— Axe for mobile by Deque, manual keyboard/switch testing, real-device testing with screen readers.
• Progressive Web Apps— Test as both a website (browser-based screen reader testing) and an installed app (home screen, push notifications, offline mode).

Fixes Every US Organisation Needs in 2026

1. Audit your mobile app against WCAG 2.2 AA— Even though Title II cites 2.1, targeting 2.2 covers the new mobile- specific criteria (Target Size, Dragging Movements) and future-proofs your compliance.
2. Label every interactive element— Buttons, icons, form fields, and links must all have programmatically associated accessible names.
3. Respect system settings— Font size preferences, reduced motion, high contrast mode, and dark mode must all function correctly in your app.
4. Test with real assistive technology— Automated tools miss the majority of mobile accessibility issues. Test with VoiceOver on iOS and TalkBack on Android as part of every release cycle.
5. Provide alternatives for complex gestures— Every swipe, pinch, or drag-and-drop interaction must have a simple tap or button alternative.
6. Include mobile in your VPAT— If you produce a VPAT for your website, extend it to cover your mobile app as well. This is increasingly expected in procurement and provides legal protection.

How We Help

Our IAAP-certified team provides dedicated mobile accessibility audits for iOS, Android, React Native, and Flutter applications. We test with real devices, real screen readers, and real users with disabilities. Every audit includes developer-ready remediation guidance specific to your platform and framework. Start with a free preliminary check to understand your app's accessibility posture before investing in a full audit.