A VPAT for a mobile app should cover the full WCAG 2.1 AA criteria set applied to every screen, flow, and interaction in the app, across both iOS and Android if the app ships on both. The completed document, an Accessibility Conformance Report (ACR), states the conformance level for each criterion (Supports, Partially Supports, Does Not Support, Not Applicable) and includes remarks that describe the actual app behavior. Scope must be defined up front: which versions, which platforms, which user flows. The ACR is only as accurate as the audit behind it.
| Coverage Area | What It Includes |
|---|---|
| Standard | WCAG 2.1 AA (most common request) or WCAG 2.2 AA when specified |
| Platforms | iOS, Android, or both, depending on where the app ships |
| Scope | App version, screens, user flows, and assistive tech environments evaluated |
| Assistive Tech | VoiceOver (iOS), TalkBack (Android), Switch Control, Voice Control, dynamic type |
| Document | ACR based on the WCAG edition of the VPAT, with per-criterion remarks |
| Foundation | A manual accessibility audit of the app, not a scan |
What Standard Should the VPAT Reference?
WCAG 2.1 AA is the standard most procurement teams request today. WCAG 2.2 AA is gaining traction and is the right pick when the buyer asks for it or when the app team wants to be ahead of where requests are heading.
The VPAT edition follows the standard. The WCAG edition of the VPAT is the default for mobile apps sold to private-sector buyers. Section 508 edition applies when selling to U.S. federal agencies. EN 301 549 edition applies when selling into the EU. The INT edition combines all three.
How Should Scope Be Defined?
Scope is the part teams get wrong most often. A mobile app ACR needs a specific version number, a list of platforms, and a clear description of the flows and screens that were evaluated.
If the app has both iOS and Android builds, each should be evaluated separately. The two builds rarely behave identically with assistive technology, and combining them into one ACR without that distinction misrepresents conformance.
Flows worth covering include onboarding, authentication, primary task paths, account settings, search, checkout or conversion steps, notifications, and any in-app messaging. Edge screens like error states and empty states matter too.
Which WCAG Criteria Apply to Mobile Apps?
All WCAG 2.1 AA criteria apply to mobile apps, but they apply through the lens of native mobile patterns. Some criteria translate directly. Others require interpretation against platform conventions.
Examples of criteria that need careful evaluation on mobile:
1.3.1 Info and Relationships: native accessibility traits, labels, and grouping in iOS and Android.
1.4.4 Resize Text: support for dynamic type on iOS and font size settings on Android.
2.1.1 Keyboard: external keyboard navigation, focus order, and switch access.
2.5.1 Pointer Gestures: alternatives for multi-point or path-based gestures.
2.5.3 Label in Name: visible label matching the accessible name announced by VoiceOver or TalkBack.
4.1.2 Name, Role, Value: correct semantics for custom controls and components.
Each criterion gets a conformance rating and a remark grounded in observed app behavior. Vague remarks defeat the purpose of the ACR.
What Assistive Technology Should Be Used in the Evaluation?
The auditor evaluates the app using the assistive technology built into each platform. On iOS, that means VoiceOver, Voice Control, Switch Control, and dynamic type. On Android, TalkBack, Voice Access, Switch Access, and font size and display size settings.
The ACR remarks should reflect what actually happens when these tools are used. A criterion marked Supports should have an audit observation behind it, not an assumption.
Why an Audit Has to Come First
An ACR without an audit behind it is a guess. Mobile app accessibility cannot be measured by a scan. Scans only flag approximately 25% of issues, and most mobile scanning tools are weaker than their web counterparts.
A manual accessibility audit of the app identifies issues against each criterion. Those findings become the source material for the per-criterion remarks in the ACR. VPAT and ACR services from Accessible.org always include the audit as the foundation.
What Should Each Criterion’s Remark Include?
A useful remark is specific. It names the screen or component, describes the behavior with assistive tech, and notes any condition that affects conformance. Generic remarks like “the app meets this criterion” provide no value to the buyer’s procurement review.
If a criterion is rated Partially Supports, the remark should describe what works, what does not, and where the issue appears. If rated Does Not Support, the same applies. The reader of the ACR should be able to picture the issue.
How Often Should the ACR Be Refreshed?
ACRs do not have a formal expiration. The recommendation is to refresh the document after significant product changes: a redesign, a major feature release, a platform version jump that changes accessibility behavior, or a switch in the underlying framework.
Buyers often expect a recent ACR, and “recent” is usually interpreted as within the past 12 to 18 months. A stale ACR raises questions even when the app itself has improved.
Does a single VPAT cover both iOS and Android?
It can, but each platform should be evaluated separately and the remarks should call out platform-specific behavior. If the apps differ significantly, two ACRs may be clearer.
Can a mobile app VPAT be filled out by the developer?
Self-issued ACRs are allowed. Independently issued ACRs carry more weight with procurement teams because the conformance ratings come from a third party who evaluated the app firsthand.
What if the app is part of a larger SaaS product?
The web app and mobile app are separate digital assets and need separate audits and ACRs. Combining them into one document creates ambiguity that buyers will push back on.
Is WCAG 2.2 AA worth using over 2.1 AA for a mobile app?
2.2 AA is the newer standard and a few of its criteria address mobile interaction patterns directly. If the buyer is flexible, 2.1 AA covers most procurement requests today. If the buyer asks for 2.2 AA, use 2.2 AA.
A mobile app ACR is a procurement document. The value comes from accuracy, scope clarity, and remarks grounded in real evaluation work. Cut corners on the audit and the ACR reflects it.
Contact Accessible.org for a mobile app VPAT quote.
