Do You Need a VPAT for a Mobile App?

By Andrew Szigety, DHS Trusted Tester (TT‑2606‑09221). Published October 14, 2026.

Yes, if a buyer asks, and an ACR can cover a native iOS or Android app. WCAG applies to the app as non-web software, using the W3C’s WCAG2ICT guidance, and the VPAT’s software sections cover the rest: Section 508 Chapter 5 and EN 301 549 clause 11. Write one report per platform, or one that scopes each clearly. Checked on October 14, 2026.

Which Standards Apply to an App

WCAG, applied to software. WCAG was written for web content. The W3C’s WCAG2ICT note, a Group Note last published December 11, 2025, explains how each WCAG 2.0, 2.1 and 2.2 success criterion applies to non-web documents and software. It says itself that it’s guidance, not a standard. Most criteria apply as written with “software” in place of “page.” A few change: Resize Text, for example, is read as enlarging text up to what the platform’s text-size settings can do.

Section 508. The Revised 508 Standards require software to conform to WCAG 2.0 Level A and AA (E207.2), with four criteria excused for non-web software: 2.4.1 Bypass Blocks, 2.4.5 Multiple Ways, 3.2.3 Consistent Navigation and 3.2.4 Consistent Identification. Chapter 5 adds rows of its own. 502 asks whether the app works with assistive technology through the platform’s accessibility services, and 503.2 asks whether it follows the user’s platform settings for color, contrast, font type, font size and focus cursor. For a web app those rows are often not applicable. For a native app they’re central.

EN 301 549. Clause 11 of the European standard covers non-web software and names mobile applications directly. Clauses 11.1 to 11.4 mirror the WCAG criteria, 11.5 covers working with assistive technology through platform services, and 11.7 covers user preferences. The version cited in the EU today, V3.2.1, is built on WCAG 2.1. ETSI published V4.1.1, aligned with WCAG 2.2, in September 2026.

ADA Title II. The Department of Justice’s Title II web rule covers mobile apps that state and local governments provide, including through a vendor. In the rule’s explanation, the Department says apps must conform to WCAG 2.1 Level AA to the extent the criteria can be applied, and that public entities may wish to consult the W3C’s non-web guidance to work out how. Testing to WCAG 2.2 covers a 2.1 requirement, as WCAG 2.1 vs 2.2 explains.

How the VPAT Template Handles an App

The ITI template already has room for software. In the INT edition, each WCAG row has separate answer lines for Web, Electronic Docs, Software and Authoring Tool, so an app is reported on the Software line. The Section 508 and EN 301 549 sections carry the Chapter 5 and clause 11 rows that a web-only report usually marks not applicable. The edition still follows the buyer, and which VPAT edition do you need covers that choice.

The template’s instructions ask for the product name and version, a description of the evaluation methods (including testing with assistive technology), and remarks that can name application dependencies such as the operating system. For an app, that’s where the platform and OS versions belong. How to fill out a VPAT walks through each field, and VPAT vs ACR covers why the finished document is called an ACR.

One Report per Platform, or Clearly Scoped

An iOS app and an Android app are separate builds. They talk to different screen readers through different accessibility services, and a control that VoiceOver reads correctly can be silent in TalkBack. So results that hold for one platform don’t carry over to the other.

• One ACR per platform is the cleanest: “ExampleApp for iOS, version 4.2, tested on iOS 26” can’t be misread.
• One ACR for both works if every remark says which platform it applies to and the scope line lists both versions.
• The web app gets its own scope too. If the product is a web app and a mobile app, say which screens of each were tested. A buyer reading a web ACR shouldn’t have to guess whether the app was included.

What App Testing Looks Like

App testing happens on a real device, by hand. Android’s own testing guide recommends manual testing alongside tools, and says the test framework in Android Studio can’t detect issues that only occur on a device. A thorough pass covers:

• The screen reader. VoiceOver on iOS, TalkBack on Android. Is every control announced with a clear name and role? Can you reach every element by swiping, finish each main flow, and hear alerts when they appear? Those questions come straight from Android’s checklist.
• Larger text. Turn on the largest text sizes, Dynamic Type on iOS or the font size setting on Android, and check that nothing is cut off or overlaps. Apple’s Human Interface Guidelines suggest letting people enlarge text by at least 200 percent.
• Orientation. WCAG 1.3.4 asks that content work in portrait and landscape unless one orientation is essential, and WCAG2ICT applies it to software on hardware people turn in normal use.
• Touch targets. WCAG 2.2’s 2.5.8 asks for targets of at least 24 by 24 CSS pixels or enough spacing, and WCAG2ICT applies it to software as written. The platforms ask for more: Apple’s default control size is 44 by 44 points, and Android recommends at least 48 by 48 dp.
• Keyboard and switch access. WCAG 2.1.1 applies to software, so everything should work through a keyboard interface where the platform has one. Check Full Keyboard Access and Switch Control on iOS and Switch Access on Android, and make sure every swipe or drag has a plain button alternative.
• Platform settings. Section 508 503.2 and EN 301 549 11.7 ask the app to respect the user’s color, contrast and font settings. Change those settings on the device and check that the app follows them.

Hybrid and WebView Apps

A hybrid app is a native app that shows web content inside it, usually in a web view. DHS’s 508 testing page defines it the same way. The newest EN 301 549, V4.1.1, settles how to report it: a web view embedded in a mobile app doesn’t meet the definition of a web page, so the clause 11 software requirements apply, and where there’s doubt, clause 11 takes precedence. WCAG2ICT also lists iOS web views among the markup software uses internally to build its interface.

In practice, test web view screens on the device with VoiceOver or TalkBack like any other screen, and report them on the Software lines. Apps built with cross-platform frameworks are judged the same way: Section 508 502 and EN 301 549 11.5 ask whether each control reaches assistive technology through the platform’s accessibility services, whatever it was built with. A mobile website opened in the phone’s browser is different. That’s web content, and it’s reported as web.

What Buyers Check in an App ACR

• Scope. Which platform, OS version, app version and screens. A report that says “mobile” without naming them is hard to rely on.
• Method. How it was tested and with which assistive technology. The template asks for this in Evaluation Methods Used.
• The software rows. Chapter 5 and clause 11 answered for the app, not marked not applicable as they would be for a web product.
• Remarks that match the app. “The date picker on the booking screen isn’t announced by TalkBack” tells a reviewer something. A remark copied from the web report doesn’t.
• The right credentials claimed. The DHS Trusted Tester process is for web content. DHS publishes separate iOS and Android test processes and says they haven’t been updated since 2017. A report on an app shouldn’t be presented as a Trusted Tester evaluation.

How procurement reviewers read an ACR more generally is in how buyers review an ACR, and a full sample VPAT/ACR shows what a finished report looks like.

Each row was read from the page or document it links to on October 14, 2026. The Apple figures are from its Human Interface Guidelines on accessibility, and the Android target size from its guide to making apps more accessible.

How Harbor Does It

Harbor’s audits lead with websites and web applications. If a buyer needs your app covered in the ACR as well, say so on the free 15-minute call, and its screens are scoped like any other screen in the product. The report says which platforms, versions and screens were tested, and how.

Every engagement is tested and signed by a DHS Trusted Tester, Andrew Szigety (certificate TT‑2606‑09221) or an additional tester he selects as needed, and whoever signs is named on the ACR. That certificate covers web testing, so a report cites it for the web product, not for the app. The ACR comes in the INT edition, with visual fix guides, follow-up reviews and a re-issued ACR after each, and a ready-to-publish accessibility statement written from the same findings. Harbor doesn’t publish a fee. It’s set on the call and fixed in writing before you commit.

Harbor provides technical audits and conformance documentation, not legal advice. VPAT® is a registered service mark of the Information Technology Industry Council (ITI).

• VPAT vs ACR
• How to Fill Out a VPAT
• Which VPAT Edition
• Read the Sample VPAT/ACR
• Book the 15-Minute Call