Skip to content
wcagc
←Back to blog
ADAmobile appsTitle IIWCAGSection 508

ADA mobile app compliance: what actually applies

Title II names WCAG 2.1 AA for government apps, with 2027 and 2028 dates. Private apps have no rule, but Title III still reaches them.

P

Pavel Charkasau

The ADA has no single mobile app rule. It has two answers, and which one you get depends on who publishes the app. If a state or local government provides it, the Justice Department's Title II rule names a standard and a date: WCAG 2.1 Level AA, due April 26, 2027 for entities serving 50,000 or more people and April 26, 2028 for smaller entities and special districts (ADA.gov; Federal Register, 91 FR 20902). That reaches apps a vendor runs on the government's behalf.

If a private company publishes the app, no regulation names a standard at all. Courts have applied Title III to apps anyway. The Ninth Circuit did it in Robles v. Domino's Pizza, and the Supreme Court declined to hear the appeal in October 2019 (Supreme Court docket 18-1539).

So the legal question splits by ownership. The engineering question does not: both roads end at WCAG, which was written for web pages. A screen is not a page and VoiceOver is not a browser. Here is how the standard lands on a native build.

Does the ADA apply to mobile apps?

Yes, and it did before anyone wrote a rule about it. The argument was never whether an app can shut someone out, but which words in a 1990 statute reach the software.

The Ninth Circuit answered that in Robles. Domino's argued Title III covered its restaurants, not the software people order from at home. The panel held that "the ADA applies to the services of a public accommodation, not services in a place of public accommodation," and that the website and app "connected customers to the goods and services of Domino's physical restaurants" (Robles v. Domino's Pizza, LLC, No. 17-55504 (9th Cir. Jan. 15, 2019)). Domino's petitioned the Supreme Court. The docket entry for October 7, 2019 reads "Petition DENIED."

Read the opinion closely, because the reasoning has an edge to it. "This nexus between Domino's website and app and physical restaurants," the panel wrote, "is critical to our analysis." Footnote 6 then says: "We need not decide whether the ADA covers the websites or apps of a physical place of public accommodation where their inaccessibility does not impede access to the goods and services of a physical location." A delivery app with a shop behind it sits inside that holding. A purely digital product is a question that court deliberately left open.

For anyone thinking of waiting for regulation, one more line is worth knowing: the panel held Domino's "received fair notice that its website and app must comply with the ADA." The absence of a DOJ standard was not a defense.

What does the Title II rule require of a government app?

A version number and a date, which is more than the rest of ADA practice gives you.

The rule defines its subject plainly: "Mobile apps are software applications that are downloaded and designed to run on mobile devices like smartphones and tablets" (ADA.gov). It covers apps a state or local government "provides or makes available," following the service rather than the org chart. DOJ's own example: "If a city lets people pay for public parking using a mobile app, that mobile app must meet WCAG 2.1, Level AA even if the app is run by a private company" (ADA.gov).

That sentence is the one to bring to a procurement meeting. Contracting the app out does not move the duty. DOJ's first-steps guidance says the same from the buyer's side: "Your public entity needs to make sure that any content or mobile apps a vendor or contractor provides or posts on its behalf complies with WCAG 2.1 Level AA," and it suggests "requiring vendors to provide detailed information about the level of accessibility of their product before signing any contracts" (ADA.gov).

Five narrow exceptions exist, covering archived content, preexisting documents, third-party posts, password-protected individualized documents such as a person's bills, and old social media posts (ADA.gov). None of them excuses the app itself. The dates moved once already, in April 2026, so plan from the current ones rather than from a slide deck made in 2024. I covered that change in what the Title II deadline extension actually did.

Federal agencies are a separate track: their software runs under Section 508, which points at WCAG 2.0 Level A and AA (36 C.F.R. pt. 1194, app. A, cited in Robles n.1).

What applies to a private company's app?

No standard, no deadline, and no shelter. DOJ's web guidance says the department "does not have a regulation setting out detailed standards" and that businesses "have flexibility in how they comply," while pointing at WCAG as helpful (ADA.gov). That guidance does not discuss mobile apps at all.

Litigation volume is real but hard to slice. UsableNet counted more than 5,000 digital accessibility lawsuits filed in 2025 (UsableNet, January 8, 2026). Those trackers count websites, apps and video together, and I have not seen a credible app-only breakdown, so I am not going to invent a percentage for you. Robles shows the simpler point: the app was named alongside the website, and the court treated both the same way.

My view, after reading a lot of these documents: that flexibility is worth less than it sounds. Nobody tells you the target in advance, and nobody agrees you hit it afterwards. Build the app to WCAG 2.2 Level AA. It is a superset of 2.0 and 2.1, so one target answers the Title II rule, the Section 508 standard, and whatever a complaint cites. The level question has its own post: does the ADA require WCAG, and which level.

How does WCAG apply to a screen instead of a page?

This is the part nobody hands you. WCAG 2.2 is written around a web page: the conformance claim, the "set of web pages" language, the assumption of a user agent. A native app has none of that.

W3C is working on the mapping. Guidance on Applying WCAG 2.2 to Mobile Applications, a Group Draft Note dated 6 May 2025, makes the substitution directly: "the equivalent unit of conformance for mobile applications is a single screen within the application" (W3C). A draft note carries no legal force, and it is still the most useful page on the subject.

If you also sell into Europe, that mapping already exists in law: EN 301 549 has a whole chapter for software, and I wrote up how it treats apps in EN 301 549 requirements for mobile apps.

Which success criteria actually bite in an app?

Some barely change on mobile. A handful were written for it: WCAG 2.1 added most of the pointer and motion criteria, and 2.2 added target size (W3C, WCAG 2.1; W3C, WCAG 2.2).

CriterionLevelWhat it looks like when it fails
1.3.4 OrientationAAThe app is locked to portrait, so a wheelchair-mounted tablet cannot use it
2.5.1 Pointer GesturesASwipe-to-delete or a pinch-zoom map with no single-pointer alternative
2.5.2 Pointer CancellationAAn action fires on touch-down, so a mis-tap cannot be dragged off and cancelled
2.5.4 Motion ActuationAShake-to-undo with no button that does the same thing
2.5.8 Target Size (Minimum)AAA 16 px icon-only control in a crowded toolbar
4.1.2 Name, Role, ValueAAn icon button with contentDescription = null, announced as "button, unlabeled"

Platform guidance is stricter than WCAG on target size. WCAG 2.2 asks for 24 by 24 CSS pixels; Android tells developers "each interactive UI element" should have a touch target "of at least 48dpx48dp," and Apple asks for "controls that measure at least 44 points x 44 points" (Android Developers; Apple Developer). Follow the platform number. It is what your users' thumbs meet, and it clears the WCAG minimum on the way past.

Contrast is the arithmetic you already run on the web, and Android states it as 4.5:1 for text under 18sp and 3:1 above. Tokens taken from a web palette should carry over; check them anyway with the contrast checker, because app themes drift.

How do you test a mobile app for ADA compliance?

Not with a scanner alone, and that is DOJ's position rather than mine: "You won't be able to use automated testing tools alone, because those tools can't test for all aspects of accessibility, so you'll want to use some combination of automated and manual assessments" (ADA.gov).

The numbers back that up. Automated testing catches roughly 30 to 57% of issues depending on the study, with Deque's analysis of its own rule set landing at 57% (Deque). More on that split in how much automated tools actually catch. Full conformance needs a human review.

A working order for an app team:

  1. Inventory first. DOJ's questions are the right ones: "What mobile apps does my public entity use? Are those apps created and operated in-house, or are they operated by third parties?"
  2. Run the platform checkers on each screen. Android's Accessibility Scanner flags unlabeled elements and small targets on a live device.
  3. Do the main task with the screen reader on, by ear. TalkBack on Android, VoiceOver on iOS, one full purchase or booking, no peeking at the screen.
  4. Fix what blocks the task first, not what the tool reports loudest. An unlabeled checkout button outranks forty decorative images.
  5. Scan the web surfaces the app depends on, starting with the sign-in page in the web view.

Here is our limit, stated plainly. Our scanner reads web pages. It cannot open your .ipa and press buttons, and no automated tool will tell you whether a custom date picker behaves the way a switch-access user expects. That part needs a person with a device.

FAQ

Does the ADA require mobile apps to meet WCAG 2.1 Level AA?

For state and local government apps, yes. The Title II rule makes WCAG 2.1 Level AA the technical standard for web content and mobile apps (ADA.gov). For private companies, no regulation names a standard; DOJ says businesses "have flexibility in how they comply" while pointing at WCAG as guidance (ADA.gov). Settlements still reach for WCAG, because it is the only measurable thing to write into an order.

Is there an ADA deadline for mobile apps?

Only under Title II: April 26, 2027 for public entities serving 50,000 or more people, and April 26, 2028 for smaller entities and special district governments, after DOJ extended both dates in April 2026 (Federal Register, 91 FR 20902). Private apps have no dated deadline. The nondiscrimination duty applies now.

Does the ADA cover an app with no physical store behind it?

Unsettled in the Ninth Circuit, which said so on purpose. Robles rested on the nexus between the app and Domino's restaurants, and footnote 6 declined to decide the case where inaccessibility "does not impede access to the goods and services of a physical location" (9th Cir., No. 17-55504). If your app is the whole business, the answer turns on your circuit and your facts, which is a question for a lawyer.

Do I have to test with both VoiceOver and TalkBack?

Yes, if you ship both platforms. They fail differently: an iOS control with an accessibility label can still be unreachable by swipe order, and an Android element with a content description can still announce its role wrong. One pass each on your primary task takes about twenty minutes.

Check the web half of your app today

The native build needs a device and a person. The web surfaces around it do not, and a lot of app journeys quietly live there: the sign-in page in the web view, the password reset, the account portal. Those you can measure this afternoon, with the exact selector for every failure. Run a free accessibility scan, then take the WCAG checklist to the screens a tool cannot reach.

Written by Pavel Charkasau, founder of wcagc.com. I read the rule text and the opinions directly, so what is here matches the sources rather than the summaries of them.

Last updated: September 3, 2026

Sources