Mobile App Accessibility Under ADA Title II: What Public Entities Need to Know

Many people picture the Title II rule as a website rule. It is not. The Department of Justice’s rule covers web content and mobile apps that state and local governments provide or make available, and it points to WCAG 2.1 Level AA as the technical standard.

Apps are easy to overlook because they are often bought, branded and updated by someone other than the web team: a parking app, a bus tracker, a 311 reporting tool, a recreation booking app, a school communications app. If it is offered in your name, the obligation is yours.

Does the rule really cover apps?

Yes. The rule applies to web content and mobile apps that a public entity provides or makes available, including through a contract with another party. That last clause matters. Hiring a vendor to build or run the app does not move the responsibility to the vendor.

The rule also has limited exceptions, for example for archived web content and for content posted by third parties that is not provided under your arrangement. Whether a particular app or feature falls inside an exception is a question for your counsel. For which compliance date applies to your entity, see our deadlines post rather than relying on any date you remember.

How does WCAG apply to a mobile app?

WCAG was written for web content, but its principles transfer, and the rule applies WCAG 2.1 to apps. In practice, a handful of criteria cause most of the trouble on phones.

Name, role and value (4.1.2). Every control must tell the operating system what it is and what state it is in, so VoiceOver on iOS and TalkBack on Android can announce it. A custom button drawn as a picture with no label is announced as nothing.

Text alternatives (1.1.1). Icons, images and map pins that carry meaning need labels. Decorative graphics should be hidden from assistive technology.

Orientation (1.3.4). Do not lock the app to portrait or landscape unless it is essential. Some users mount a device in a fixed position.

Pointer gestures (2.5.1). Anything done with a multi-finger or path-based gesture, such as a pinch to zoom a map, needs a single-pointer alternative.

Motion actuation (2.5.4). If shaking the phone does something, there must be another way to do it, and a way to turn the shake off.

Label in name (2.5.3). The visible text on a button must be part of its accessible name, or voice control users cannot say what they see.

Contrast (1.4.3 and 1.4.11). Text, icons and control boundaries need enough contrast, in both light and dark modes if you offer both.

Resize and reflow (1.4.4, 1.4.10). Respect the user’s system text size. Layouts that clip or overlap at large sizes fail the people who need them most.

Focus and keyboard (2.1.1, 2.4.3). Switch and external-keyboard users must be able to reach and operate everything in a logical order.

Native app or web wrapper: does it matter?

It matters to how you fix problems, not to whether you must. A native app uses the platform’s accessibility framework directly. A hybrid app wraps web views, and a defect in one shared component can appear on every screen. A fully web-based mobile experience is covered by the web side of the rule.

What is common to all of them is that you cannot see accessibility from a screenshot. It has to be tested with the assistive technology people actually use.

How should you test an app?

1. Turn on the screen reader (VoiceOver, TalkBack) and complete the app’s main tasks without looking at the screen.
2. Increase the system text size to the maximum and look for clipped or overlapping content.
3. Test in both orientations, and with display zoom.
4. Try switch access or an external keyboard if you can.
5. Use the platform’s built-in accessibility scanners as a first pass. They help, but find only part of the issues, as automated scan vs. manual audit explains.
6. Test the whole journey, not just screens: registering, signing in, paying, reporting a problem. A process conforms only if every step does.

Keep a record of what you tested, on which devices and operating system versions, and what you found. Section 508 test evidence is a good model for what a reviewer wants to see.

What should you ask your app vendor?

• Which standard and version the app is built and tested to.
• Whether they test with real screen readers on real devices, not only automated tools.
• Whether they can provide a conformance report, and when it was last updated. What is a VPAT?
• How accessibility defects are reported, prioritised and fixed, and at whose cost.
• What happens to accessibility when the app is updated.

Put the answers into the contract. Writing accessibility into an RFP or SOW has language you can adapt, and the buyer’s checklist covers what to ask before you sign. If the app embeds payment screens or maps from another company, the third-party content problem applies.

Don’t forget language

An app that serves a multilingual community has several accessibility surfaces beyond the English screens. Translated strings must fit their controls at large text sizes. Screen readers need the right language set so they pronounce content properly (the principle behind WCAG 3.1.1 and 3.1.2). Push notifications and in-app alerts need to be accessible and translated, which emergency and public-safety notices discusses. Machine-translated interface text is a particular risk: screen readers and machine translation explains why.

Where Taika fits

We support the content side of app accessibility: reviewing screen labels and accessible names, translating app strings and notifications in context, and verifying the translated experience, alongside document and website work. We do not build apps, and we will say so if what you need is engineering rather than content. We meet and exceed ISO 17100, 9001 and 27001 standards.

Have an app to review? Send us its name and platforms, the main tasks residents use it for, the languages it must support and whether a vendor maintains it, then request a quote. Our ADA website accessibility page explains how we scope Title II work.