Does the ADA Apply to Mobile Apps? Compliance Guide

Why this question keeps coming up

The ADA was signed in 1990, well before smartphones existed, so the statute does not mention "mobile app" anywhere in its text. That has left business owners, government IT directors, and app developers asking a reasonable question: does any of this actually apply to a native app, or is ADA exposure strictly a website problem?

The short answer is that mobile apps are covered, though the legal path differs depending on whether you are a government entity or a private business — and the technical work required to comply looks different from web remediation even when the underlying legal theory is the same.

The legal theory: "public accommodation" extended to apps

Title III of the ADA prohibits discrimination in the "full and equal enjoyment" of goods and services by places of public accommodation — the category that includes retail stores, restaurants, banks, and other business establishments open to the public. The ADA's implementing regulations did not originally address digital properties at all, so for decades the question of whether a website (or app) counts as a "place of public accommodation," or is merely a communications channel tied to one, has been litigated case by case.

The general legal reasoning that has emerged across several courts: when a business operates a place of public accommodation, the digital tools it uses to deliver goods and services connected to that business — its website, and by extension its app — fall within the ADA's reach because they are an extension of the business's public-facing operations. Courts have not been unanimous on this point (jurisdictions differ, and some circuits have taken a narrower reading of what counts as a "place" of public accommodation), which is exactly why the same due diligence you'd apply to a website should be applied to an app tied to the same business.

This guide will not name a specific mobile-app court case beyond what's already documented on this site, because the safest approach here is to reason from the general, well-established principle rather than attach a citation that hasn't been verified. What's important operationally is this: if the underlying business would face exposure for an inaccessible website, the app it operates carries comparable exposure, because the legal theory turns on the business being a public accommodation — not on which specific piece of software the customer happens to be using.

Where the law is explicit: Title II and government apps

The one place mobile apps are named directly, rather than reasoned into coverage, is ADA Title II. The DOJ's rule for state and local governments requires that "web content and mobile applications" conform to WCAG 2.1 Level AA. That phrase — web content and mobile applications — appears in the rule's own language, so if you run IT or digital services for a government entity, there is no ambiguity: your native apps are in scope on the same timeline as your website. See our guide on Title II compliance for government agencies for the specific deadlines and what a self-evaluation covers.

Private-sector Title III has no equivalent DOJ rule specifying a technical standard for apps (or websites, for that matter) — but the absence of a formal regulation does not mean the absence of legal risk. It means the technical benchmark is set by practice and by what courts and plaintiffs' attorneys point to, which brings us to WCAG.

WCAG 2.1 AA: written for the web, applied to apps

WCAG 2.1 Level AA is a W3C standard, and its official scope is "web content." It was not written with native mobile UI frameworks (UIKit/SwiftUI on iOS, or the Android View system/Jetpack Compose) in mind. So why does it keep coming up in mobile app accessibility conversations?

Two reasons. First, the DOJ explicitly requires WCAG 2.1 AA conformance for government mobile apps, so for that category it is not just a benchmark — it is the literal legal standard. Second, in the absence of any native-app-specific legal standard for private businesses, WCAG 2.1 AA is the most defensible, well-documented technical framework available, and most professional accessibility auditors evaluate apps against it because its underlying principles — perceivable, operable, understandable, robust — translate cleanly to any interactive software, not just web pages.

The translation is not always one-to-one. Some WCAG criteria are meaningless in a native context (page titles, for instance, don't exist in a native app screen). Others map directly onto platform accessibility APIs:

• 1.1.1 Non-text Content → every icon, image, and control needs an accessible label (accessibilityLabel on iOS, contentDescription on Android).
• 1.4.3 Contrast (Minimum) → the same 4.5:1 text contrast ratio applies to native UI text and icons.
• 2.1.1 Keyboard → for mobile, this generally maps to switch-access and external-keyboard operability — every interactive element must be reachable without a touch gesture.
• 2.4.3 Focus Order → screen reader focus order (VoiceOver/TalkBack swipe order) must match the logical reading order of the screen.
• 2.5.5 Target Size (Enhanced) / 2.5.8 Target Size (Minimum) → touch targets need adequate size and spacing, which lines up closely with Apple's and Google's own touch-target guidance.

The platform accessibility APIs you actually build against

Native apps are not evaluated with the same tools used for websites. There is no browser DOM to inspect. Instead, each platform exposes its own accessibility tree and assistive technologies:

iOS / iPadOS

• VoiceOver — Apple's built-in screen reader. Swipe gestures navigate between elements; each element needs an accurate accessibility label, trait, and (where relevant) value.
• Dynamic Type — lets users scale text size system-wide; apps built with fixed font sizes break this and create a low-vision barrier.
• Voice Control and Switch Control — alternative input methods for users with motor disabilities.
• Apple's accessibility APIs are documented in the Accessibility section of Apple's developer documentation.

Android

• TalkBack — Google's built-in screen reader, Android's equivalent of VoiceOver, with its own gesture set and focus behavior.
• Font scaling via system display settings — the Android equivalent of Dynamic Type.
• Switch Access — Android's switch-based input alternative.
• Google documents these APIs in its Android accessibility developer guide.

If your app ships on both platforms, testing with only one screen reader is not sufficient. VoiceOver and TalkBack interpret accessibility metadata differently enough that an element correctly labeled for one can still be confusing or silent in the other.

Mobile website vs. native app: two different technical jobs, same legal exposure

This distinction trips up a lot of teams, so it's worth stating plainly:

• A mobile website is your existing website, rendered responsively in a mobile browser. It is the exact same legal surface as your desktop site — same HTML, same WCAG criteria, same DOM-based testing tools (axe-core, WAVE, Lighthouse). If your site is accessible on desktop and genuinely responsive, you are largely covering your mobile web exposure already. See our guide to checking website ADA compliance for that process.
• A native app is a separate codebase built with a platform-specific UI toolkit, distributed through an app store, and evaluated using platform-specific accessibility tools (VoiceOver/TalkBack, Accessibility Inspector on Xcode, Accessibility Scanner on Android) rather than web tools.

A business can be fully compliant on its website and still have a completely inaccessible native app, because the two are built differently and tested differently — even though a plaintiff's underlying legal claim ("your public-facing digital service is inaccessible to me") does not distinguish between the two.

What to do if you ship a native app

1. Inventory what you have. Map every screen and user flow in your app the same way you would map pages on a website. Note which flows are business-critical (account creation, checkout, appointment booking).
2. Run a platform accessibility audit, not just a web scan. Automated web crawlers like our Compliance Checker test websites, not app binaries — for a native app, use Xcode's Accessibility Inspector (iOS) and Android's Accessibility Scanner, then move to manual VoiceOver and TalkBack passes on critical flows.
3. Check labels, roles, and touch targets first. These correspond to the highest-prevalence issues found on the web (missing alt text and labels, insufficient contrast) and are usually the fastest wins.
4. Test Dynamic Type / font scaling. Confirm your layouts don't clip or overlap when users scale text up.
5. Document your standard. Just as with a website, publish (or maintain internally) a record of what standard you're evaluating against — WCAG 2.1 AA is the most defensible choice absent a more specific legal standard for your situation.

Where to go from here

If your organization is a state or local government, mobile app conformance is not optional guidance — it's part of the same DOJ rule covering your website, on the same deadlines. Read our Title II government compliance guide for specifics.

If you're a private business, treat your app the way you'd treat any other public-facing digital surface tied to your business: evaluate it against WCAG 2.1 AA, test with real assistive technology, and don't assume that fixing your website automatically fixes your app.

Ready to take the next step? Grow Wild Agency offers a free preliminary WCAG 2.1 AA scan of your website as a starting point, and can scope a native-app accessibility review alongside it so both surfaces get evaluated against the same standard.