Mobile Apps Are in the Rule Too: Title II Accessibility for the Apps in Your Municipal Portfolio

The Half of the Rule Nobody Scanned

Run the accessibility workflow this series has built — the seven-step toolkit, axe DevTools, WAVE, Lighthouse, a keyboard pass, a screen-reader spot check — and you have covered the websites in your municipal portfolio. You have covered exactly none of the mobile apps.

That is not a small gap. The DOJ's Title II rule covers mobile applications on the same terms, to the same standard, on the same dates as web content. The 311 reporting app, the utility-payment app, the parking app, the meeting-agenda app — if a public entity provides or makes any of them available, directly or through a contract with a vendor, the rule reaches it. And the tools you have been running do not. A browser extension cannot test a native iOS app. Lighthouse does not open an APK. The entire automated layer of the standard accessibility workflow stops at the edge of the web, and the mobile side of the portfolio has been sitting in a blind spot.

This post closes that gap. What the rule actually says about apps, how the web standard gets translated to native code through a W3C document most contractors have never opened, the testing stack that replaces your browser scanners, the failure modes that show up in municipal apps specifically, how the third-party component problem mutates when the components are embedded SDKs instead of iframes, and what your VPAT and your contract have to say about all of it. There is already a DOJ settlement enforcing this against a government app. Start with that.

Service Oklahoma: The Enforcement Precedent

In January 2024, the Department of Justice executed a settlement with Service Oklahoma over the state's mobile ID application. The facts are the kind every contractor with an app in their portfolio should sit with for a minute.

A blind Oklahoman tried to use the OK Mobile ID app. He could not photograph his physical ID because the app gave him no accessible way to know whether the document was framed in the camera. Then the app asked him to complete a liveness check — the now-common "connect the dots with your eyes" or "follow the moving target" routine that confirms a real person is present — with no audio feedback and no accessible alternative. A sighted user breezes through it. A blind user is stopped cold at the identity gate, locked out of a state-issued digital credential.

DOJ investigated and Service Oklahoma settled. The agreement requires the agency to conform any mobile app it creates, administers, or maintains to WCAG 2.1 Level AA. This was part of DOJ's broader Tech Equity Initiative, and it landed before the Title II rule's compliance dates were even on the calendar — which is the whole point. The mobile-app obligation does not wait for April 2027. It flows from the underlying Title II duty that, as this series has said in every post since the IFR, never moved at all.

Two details matter for contractors specifically. First, the failure was not exotic. Unlabeled camera controls and an inaccessible liveness check are ordinary, reproducible defects that a single VoiceOver pass would have surfaced in minutes. Second, the liveness check was almost certainly not Service Oklahoma's own code — identity-verification routines are overwhelmingly third-party SDKs dropped into the app. Which means the precedent already contains the inheritance problem this post returns to later: the agency was held responsible for the accessibility of a component it licensed rather than built. The contractor who integrated that SDK is exactly the party who, under modern procurement language, would be standing next to the agency when the tender of defense arrives.

What the Rule Actually Says About Apps

The mobile coverage is not an interpretation or an inference. It is in the regulatory text.

28 CFR Part 35, Subpart H — the web-and-mobile subpart added by the 2024 final rule — requires public entities to ensure that the mobile apps they provide or make available, "directly or through contractual, licensing, or other arrangements," are readily accessible to and usable by people with disabilities. The definitions section, 28 CFR 35.104, defines a mobile app as software downloaded and designed to run on mobile devices such as smartphones and tablets. The technical standard in 28 CFR 35.200 is WCAG 2.1 Level AA — the same standard for apps as for web — incorporated by reference to the specific June 2018 W3C Recommendation.

Three consequences follow directly.

The "directly or through contractual, licensing, or other arrangements" language is the vendor hook, and it is broader for apps than most contractors realize. A municipality does not have to have written an app to be on the hook for it. If the city makes a vendor's parking app or payment app available to residents as a way to access a city service, that app is inside the obligation, and the contract that put it there is the mechanism that flows the obligation toward whoever integrated or delivered it.

The five Subpart H exceptions apply to apps just as they do to web — archived content, preexisting conventional electronic documents, third-party content not posted under contract, individualized password-protected documents, preexisting social-media posts. Note the trap in the third one: third-party content is only exempt when it is not under a contractual arrangement. A payment SDK the city pays for is under a contractual arrangement. It is inside the obligation, not exempt from it — the same boundary the third-party content post drew for embedded web widgets.

And the dates are identical to web. The April 20 Interim Final Rule amended only the two compliance dates in 35.200(b), moving them to April 26, 2027 for entities serving 50,000 or more and April 26, 2028 for smaller entities and special districts. It said nothing app-specific because it did not need to — apps and web were always on the same clock. So is the snap-back risk from the NFB lawsuit: if the District of Maryland vacates the extension, the mobile deadline reverts right alongside the web deadline.

WCAG2ICT: Translating a Web Standard to a Native App

Here is the conceptual problem at the center of mobile accessibility, and the document that solves it.

WCAG 2.1 was written for web content. It assumes a browser — what the spec calls a "user agent" — sitting between the content and the user, exposing structure to assistive technology through web APIs. A native iOS or Android app has no browser. It talks to the platform's accessibility services directly. So success criteria written in terms of "web pages" and "user agents" do not map cleanly onto a SwiftUI view or an Android activity without translation.

That translation is W3C's "Guidance on Applying WCAG 2 to Non-Web Information and Communications Technologies" — WCAG2ICT. The current version, published as a W3C Group Note in October 2024, covers WCAG 2.0, 2.1, and 2.2 and provides plain-language substitutions for the web-specific wording in each success criterion. "Web page" becomes, roughly, the software program or a screen within it. The handful of criteria that depend on "sets of web pages" get reinterpreted for the app context. A small number of criteria that assume a user agent or a specific web mechanism do not translate cleanly and are flagged as such.

Two things a contractor needs to take from this.

WCAG2ICT is informative, not normative. It does not impose requirements — the DOJ rule does that, by incorporating WCAG 2.1 AA. WCAG2ICT is the interpretive bridge that tells you how to apply that standard to a native app. When you write an ACR for an app, this is the document you cite to explain how each web-worded criterion was read for the mobile context. That explanation belongs in the ACR's remarks, and a reviewer who knows what they are doing will look for it.

And map against 2.1, not 2.2. There is a newer draft — "Guidance on Applying WCAG 2.2 to Mobile Applications," informally WCAG2Mobile — and it is genuinely useful reading. But it is a working draft, not a finished standard, and the DOJ rule mandates WCAG 2.1 AA, the 2018 version. For a federal Title II deliverable, 2.1 is the target and WCAG2ICT is the translation layer. (Washington is the exception that proves the rule, and we get to it below.)

The Testing Stack That Replaces Your Scanners

Everything in the toolkit post about the automation ceiling is more true on mobile, not less. Automated mobile tooling catches somewhere in the range of 30 to 40 percent of WCAG issues; the rest is manual. The single biggest mistake a contractor can make here is to assume that because a website had a browser scanner, an app has an equivalent one-click tool. It does not. Mobile accessibility testing is screen-reader-first by necessity.

Here is the stack, by layer.

iOS, manual. VoiceOver is the test that matters — turn it on (triple-click the side button once you have set the accessibility shortcut) and operate the entire app by swipe and double-tap, with the screen curtain on so you cannot cheat by looking. Pair it with the Accessibility Inspector that ships in Xcode, which surfaces each element's label, traits, and value, runs an audit, and shows you the accessibility hierarchy. Test Dynamic Type by cranking the system text size to its largest setting and confirming the layout survives. Test Switch Control if the app has complex interactions.

Android, manual. TalkBack is the VoiceOver equivalent — enable it and operate by swipe. The Google Accessibility Scanner runs on-device and flags touch-target size, contrast, and missing labels as you move through screens. Accessibility Insights for Android and the Espresso accessibility checks cover the automatable layer in a test pipeline.

Cross-platform and automated. axe DevTools for Mobile, Appium-based suites, Evinced, and BrowserStack's app accessibility tooling all push the automatable share higher and fit into CI. Xcode 15 added an accessibility audit you can call from an XCTest, which is the cleanest way to fail a build on a regression. Use these to catch the binary failures early; do not mistake them for the evaluation.

A prioritization note grounded in who actually uses this. The most recent WebAIM screen-reader survey found that more than nine in ten screen-reader users run a screen reader on a mobile device, that VoiceOver is by far the most common mobile screen reader, and that TalkBack gets regular use as well. Translation for your test plan: a VoiceOver pass on iOS and a TalkBack pass on Android are not optional add-ons after the automated scan. They are the test. If you ship without having operated the app by screen reader, you have not tested the thing the standard is actually about — and the Service Oklahoma defect is precisely the kind a single VoiceOver pass catches and an automated scan can miss.

The Failure Modes That Show Up in Municipal Apps

Native platforms expose accessibility through their own APIs — UIKit and SwiftUI accessibility traits on iOS, content descriptions and the accessibility-services tree on Android. The recurring municipal-app failures cluster in a predictable set, and knowing the set tells you where to look first.

Unlabeled controls are the most common and the most damaging — an icon button that VoiceOver announces as nothing more than "button," with no indication of what it does. This is the Service Oklahoma camera-control failure, and it is endemic to apps built quickly from icon libraries.

Illogical focus and reading order is the next. Screen-reader focus should move through a screen the way a sighted user reads it; instead it jumps by visual coordinates or skips interactive elements. This is especially acute in cross-platform frameworks — React Native has documented cases of reading order following screen position rather than logical order on iOS, and Flutter often needs explicit ordering hints to get it right.

Then the scaling and sizing failures: layouts that break or truncate when the user enlarges system text, and touch targets too small to hit reliably. Use the larger of the relevant minimums — Apple's 44-by-44 points, Android's 48-by-48 density-independent pixels — rather than treating WCAG 2.2's 24-pixel floor as the goal.

And the one that catches contractors hardest: the webview trap in hybrid apps. A great many municipal apps are not fully native. They are hybrid shells — React Native, Flutter, Cordova or Ionic, Capacitor — wrapping web content in a native container, and the seam between the native shell and the embedded webview is where accessibility breaks. There are documented cases where iOS Switch Control treats an entire webview as one undifferentiated element and refuses to enter its content, locking a switch user out of everything inside it. If the municipal apps in your portfolio are hybrid builds — and many 311 and payment apps are — the webview boundary is the first place to test and the most likely place to find a blocking failure.

The Third-Party SDK Problem, Mobile Edition

This series has returned again and again to the contractor's worst structural problem: you are responsible for the accessibility of components you did not build and cannot patch. On the web it is embedded widgets and iframes. On mobile it is worse, and for a specific technical reason.

An embedded web widget at least renders in a DOM you can inspect and partially influence. An embedded mobile SDK is compiled code dropped into your binary. The payment SDK, the map SDK, the analytics overlay, the identity-and-liveness SDK that stopped the blind user in Oklahoma — these ship their own UI, manage their own accessibility (or fail to), and expose almost nothing you can override. When that SDK's screen is inaccessible, you frequently cannot fix it from your code at all. Your only real levers are pressuring the SDK vendor to remediate, or replacing the SDK.

The contractual posture is the same as the web version but the stakes are higher because the failure is less fixable. Read the SDK vendor's own accessibility documentation before you integrate. Inventory every embedded SDK in any municipal app you maintain, the way the inheritance playbook says to inventory web embeds. Draw the boundary explicitly in your scope — what you built and warrant versus what you integrated and disclose. And flow the obligation down in writing wherever the contract structure allows it, using the flow-down language this series has already laid out. An SDK you cannot fix and did not document is an open-ended liability sitting inside a binary with your name on the delivery.

What Your VPAT and Your Contract Have to Say

A mobile ACR is a real ACR, built on the same VPAT 2.5 template as everything else, evaluated against the same kind of procurement checklist — with a few mobile-specific moves.

On the document itself: use the WCAG edition (or the 508 edition for federally adjacent work), and let WCAG2ICT show its work in the explanation column. Where a criterion was written for web and you read it for native, say so in the remarks — name the criterion, the interpretation, and the result. State the platforms and OS versions you tested, because "tested on iOS" without a version is not a scope statement; "tested on iOS 17 with VoiceOver and Android 14 with TalkBack, on these screens" is. The honest "Partially Supports with a dated remediation plan" still beats a wall of unexplained "Supports," and on mobile the Bashin logic is identical: the gap between what your VPAT claims and what your test record shows is the exposure.

On the contract, three mobile-specific clauses earn their place.

App-store update cycles versus remediation SLAs. A web fix deploys when you push it. A mobile fix ships through Apple or Google review and then reaches users only as they update — which many never do promptly. A remediation clause that says "within thirty days" means something different on mobile than on web. Define the SLA in terms of submitting a fixed build, name the review-cycle reality, and do not promise a timeline the app stores control.

OS support windows. WCAG2ICT assumes the platform's accessibility services are present, but those services evolve and older OS versions lack newer APIs. Specify in the statement of work the minimum iOS and Android versions the app supports and is tested against, so "accessible" has a defined surface and you are not on the hook for a six-year-old OS the app was never built for.

Embedded-SDK accessibility warranties. Following directly from the section above: where the app integrates third-party SDKs, the contract should address who owns the accessibility of each one and what happens when an SDK vendor will not remediate. This is the mobile face of the boundary-of-responsibility clause that this series has called the single highest-leverage paragraph in a contractor's template.

Where the Six States Land on Apps

The state-law map this series has maintained applies to apps as squarely as to web — and in two states more strictly than the federal rule.

Massachusetts EOTSS names mobile applications explicitly as covered digital assets, binds any firm that creates, customizes, or configures them, and demands the same ACR discipline as everything else — VPAT-based, no more than twelve months old, product-specific, qualified author, with the overlay ban applying to apps too.

Washington is the one to watch on apps. WaTech's USER-01 standard covers websites and mobile applications together, and its baseline rises to WCAG 2.2 AA for public-facing technology effective July 1, 2026 — which is sixteen days after this post. A contractor delivering a mobile app into Washington state government this summer should be authoring against 2.2 AA, not 2.1, and using the draft mobile guidance accordingly even though the federal floor is still 2.1. This is the single place where "map to 2.1, not 2.2" flips.

Colorado's HB21-1110 reaches all government digital content, apps included, with no carve-out and the $3,500-per-violation private right of action live since July 2025. Virginia's HB 2541 defines digital accessibility to include mobile platforms and handheld devices expressly and ties conformance to 28 CFR 35.200, carrying its vendor-paid third-party ACR and Roadmap requirements onto apps the same as web. Minnesota's standard and its §363A.42 penalty framework cover state IT inclusive of apps. And California's Unruh exposure attaches to inaccessible apps today, with the AB 1757 reintroduction expressly extending website-and-mobile-app conformance obligations and developer liability if it passes.

The synthesis is the same as the web version: a contractor working all six markets is effectively building to the highest applicable standard — Washington's 2.2 AA on public-facing apps after July 1 — with third-party-evaluated ACRs, no overlays, and a documented test record. Build the mobile app to that posture and it clears every state in the map.

What to Do This Week

If you have a mobile app anywhere in your municipal portfolio, four moves.

Inventory the apps the way you inventory websites — every app a public-entity client provides or makes available, whether you built it, maintain it, or integrated it, and for each one note whether it is native or hybrid and what embedded SDKs it carries.

Run a real screen-reader pass on each one. VoiceOver on iOS, TalkBack on Android, screen curtain on, operate every core task — the 311 report, the payment, the permit, the agenda. You will find the Service Oklahoma-class failures in the first ten minutes, and you will know immediately which apps are exposed.

Pull the ACR for every third-party app and SDK in the inventory, and read it like a contractor — date, scope, platforms tested, honest remarks. An app vendor who cannot produce a mobile ACR is a risk you flag to your client in writing before you carry it any further.

And log all of it in the audit defense log, the same structure, the same timestamps. The log that protects you when a website demand letter arrives is the log that protects you when the demand letter names an app — and given the Service Oklahoma precedent and the AI-assisted filing trend, the app demand letter is a when, not an if.

The websites in your portfolio have been getting scanned for months. The apps have not been getting scanned at all. They are in the same rule, on the same dates, under the same enforcement — and the precedent already on the books is a government mobile app, not a government website. Open the app. Turn on VoiceOver. Find out what you are carrying.

---

This post is for informational purposes only and does not constitute legal advice. Consult with qualified legal counsel for guidance specific to your situation.