VPAT for mobile apps: when the ACR only covers the web

A vendor offers a web portal and companion iOS and Android apps. You ask for a VPAT, and the Accessibility Conformance Report that comes back describes the portal. Nobody asks about a VPAT for the mobile apps, and for many residents the app is the product.

In reports we review this is a common gap, and under ADA Title II it is not a technicality. This post covers what the rule says about apps, why web-only reports leave you exposed, and what to ask for instead.

The Title II rule covers mobile apps explicitly

The DOJ's Title II web rule requires a public entity to ensure that both web content and mobile apps it provides or makes available, "directly or through contractual, licensing, or other arrangements", conform to WCAG 2.1 Level AA (28 CFR 35.200). The compliance dates are the same for both: 26 April 2027 for entities of 50,000 or more, and 26 April 2028 for smaller entities and special district governments.

The rule defines mobile apps as "software applications that are downloaded and designed to run on mobile devices, such as smartphones and tablets." The preamble adds that this includes native apps built for a particular platform, such as Apple iOS or Google Android, and hybrid apps that use web components inside a native app.

So a transit app, a parking payment app, a 311 reporting app or a utility billing app is covered whether your staff built it or a vendor runs it under contract.

How WCAG applies to a native app

WCAG was written for web content, and some criteria do not translate to a native app exactly as written. The DOJ acknowledged this in the preamble, and declined to create exceptions for mobile apps. Instead it said entities must generally conform "to the extent those criteria can be applied", and pointed to the W3C's guidance on non-web technology.

That guidance is WCAG2ICT, a W3C Group Note on applying WCAG 2 to non-web documents and software. Two things to know about it:

• It is informative, not a standard. It explains how criteria can be interpreted for software; it does not set requirements of its own.
• It has been updated to cover WCAG 2.1 and 2.2 criteria, so it addresses the criteria the Title II rule actually requires.

There is a trap here worth spelling out. The Revised Section 508 Standards exempt non-web software from four WCAG criteria: 2.4.1 Bypass Blocks, 2.4.5 Multiple Ways, 3.2.3 Consistent Navigation and 3.2.4 Consistent Identification. The Title II rule has no equivalent exemption. A report written to Section 508 may mark those four "Not Applicable" for an app on the strength of the 508 exception. For a Title II purchase, those rows need a real explanation of why the criterion cannot apply to this app, not a reference to a federal exception that does not apply to you. See when "Not Applicable" is legitimate.

Why web-only reports are common

Vendors usually test what they build most of: the web product. Apps may be built by a different team, on a different release cycle, sometimes by a subcontractor. The ACR on the vendor's website may predate the apps entirely.

A web report tells you very little about the apps, even when they share a brand and a back end. Native apps use different controls, different accessibility APIs and different assistive technology. Labels that are correct in the browser can be missing on a native button. Focus order can differ entirely. Text that reflows on the web can truncate in the app when the user increases the system font size.

What to ask for in a VPAT for mobile apps

1. A report that covers each app, by platform

The VPAT 2.5 instructions allow a complex product to be split into multiple reports, provided each report explains the split in its Notes section and says how to reach the others. For a product with apps, the cleanest answer is usually one report per platform: one for the web product, one for iOS, one for Android. A single report covering all three is acceptable only if every remark makes clear which platform it describes.

2. App versions and operating system versions

The report should name the app version tested and the operating system versions it was tested on. App stores push updates frequently, and an app report two major versions old describes software your residents no longer have.

3. Mobile assistive technology in the evaluation methods

The evaluation methods section should name the mobile assistive technology used. At a minimum, expect the built-in screen readers (VoiceOver on iOS, TalkBack on Android). Testing with larger system text sizes, an external keyboard, switch access and voice control is a stronger signal still. A mobile report whose only stated method is an automated scanner is thin.

4. Remarks that describe the app, not the website

Read the remarks on the criteria where native apps most often fail:

Criterion	What to look for in an app
1.1.1 Non-text Content	Icon-only buttons have accessible labels
1.3.4 Orientation	The app works in both portrait and landscape unless essential
1.4.4 Resize Text	Text scales with system font settings without truncation or overlap
1.4.10 Reflow	Content remains usable at large text sizes without two-way scrolling
2.1.1 Keyboard	The app is fully operable with an external keyboard
2.5.1 Pointer Gestures	Multi-finger or path-based gestures have a single-tap alternative
4.1.2 Name, Role, Value	Custom controls expose name, role and state to VoiceOver and TalkBack

A remark that talks about "pages", "browsers" or "HTML" on a native app row is a sign the web report was copied across.

5. Web views and documents inside the app

Many apps open web pages or PDFs inside the app: a payment screen, terms of service, a receipt. Ask which parts of the app are native and which are web content, and whether both were tested. See the post on PDFs and documents for the document side.

6. Target size, if you require WCAG 2.2

Under WCAG 2.1 Level AA there is no minimum target size; 2.5.5 Target Size is Level AAA. WCAG 2.2 added 2.5.8 Target Size (Minimum) at Level AA. If your solicitation requires 2.2, check that row in the app reports specifically. Small touch targets are a common app problem. See the WCAG 2.2 post for the other new criteria.

If there is no app report

If the vendor has no conformance report for its apps, that is a finding in itself, not a reason to assume the apps conform. Raise it in writing during evaluation, ask for a dated commitment to produce one, and consider whether the contract should make it a deliverable. The contract language post has considerations to take to counsel.

In reports we review, a missing app report is a common gap, and the easiest one to fix before award.

---

Sources: 28 CFR 35.104 and 35.200 (the DOJ's 2024 Title II web rule, as amended in April 2026) and the rule's preamble at 89 FR 31320; W3C WCAG2ICT Group Note; Revised Section 508 Standards, E207.2; ITI VPAT 2.5Rev template instructions. This is general guidance, not legal advice.

GOVvpat reviews web and mobile conformance reports against the standard your solicitation names, and flags when an app is not covered at all. Request a quote.