What mobile accessibility testing means for your app
Mobile accessibility testing starts with one question: what should you actually test for? The answer comes from the accessibility guidelines. The goal behind them is straightforward: your app should be usable by everyone, including people who rely on a screen reader, need larger text, can’t distinguish low-contrast colors, or interact with the screen by something other than a precise tap. The guidelines exist to make that goal concrete. They turn “usable by everyone” into specific, checkable requirements you can design, build, and test against.
Those requirements come from a few places. WCAG sets the technical criteria, the Americans with Disabilities Act (ADA) gives them legal weight in the United States, and Apple and Google publish accessibility guidance for their own platforms. They overlap far more than they conflict. This guide is the reference that tells you what mobile accessibility testing has to cover: it walks through each source, what it asks for, and how it maps to real mobile controls, with a brief note on how the testing itself fits at the end.
Accessible vs. inaccessible: try it yourself
Adjust each control to see how a mobile UI passes or fails the WCAG criterion behind it. Pass/fail is shown with a symbol and a word, not color alone.
Touch target size
WCAG 2.5.8 (Target Size, Minimum): 24 × 24 CSS px
Targets below the minimum are hard or impossible to hit for people with motor impairments or tremors.
Color contrast
WCAG 1.4.3 (Contrast, Minimum): 4.5:1 normal text, 3:1 large text
Change the text color, the background color, or both to test any combination.
4.5:1
Text that fails the ratio is unreadable for many low-vision and color-blind users.
What WCAG is and how its conformance levels work
The Web Content Accessibility Guidelines (WCAG) are a set of technical standards that improve the accessibility of digital content for people with auditory, cognitive, neurological, physical, speech, and visual disabilities. WCAG was written for “web content,” but it has become the reference standard applied to native and hybrid mobile apps too, a point the ADA and the platform vendors reinforce in the sections that follow. When someone asks what WCAG for mobile apps means in practice, the answer is that the same criteria apply; only the controls they describe change, from a <button> in a browser to a UIButton or an Android View.
The four POUR principles
WCAG organizes everything under four principles, abbreviated POUR:
- Perceivable. Users must be able to perceive the information: text alternatives for images, captions for video, sufficient contrast.
- Operable. Users must be able to operate the interface: controls reachable without a specific gesture, enough time to act, no seizure-inducing flashes.
- Understandable. Content and operation must make sense: predictable navigation, clear labels, helpful error messages.
- Robust. Content must work with current and future assistive technologies, which on mobile means exposing correct semantics to VoiceOver and TalkBack.
Every success criterion sits under one of these. The numbering follows suit: 1.x criteria are Perceivable, 2.x Operable, 3.x Understandable, 4.x Robust. Once you learn that scheme, a criterion number alone tells you roughly what kind of problem it addresses.
Levels A, AA, and AAA
WCAG sorts its success criteria into three conformance levels. Level A is the minimum, covering the most basic barriers. Level AA covers the biggest and most common barriers and is the level most organizations should target; WCAG 2.1 AA comprises 50 success criteria. Level AAA is the highest and most complex level, and the guidelines themselves note it is not applicable to all content.
If you take one thing from this section, it is that AA is the target. AAA is valuable, but AA is the line regulators and courts have settled on, and some AAA criteria (such as a 7:1 contrast ratio everywhere) can’t be met across an entire product without compromising it.
From WCAG 2.0 to 2.1 to 2.2
WCAG 2.0 (2008) predates the smartphone era and assumes a keyboard and mouse. WCAG 2.1 (2018) added criteria that matter directly to mobile, including screen orientation, pointer gestures, motion actuation, and target size. WCAG 2.2 (2023) is the current recommendation and adds another nine criteria while retiring one. Each version builds on the one before it: conforming to 2.2 means you also meet 2.1, with the single exception of the retired 4.1.1 Parsing criterion. If you are setting a standard today, set it against 2.2 and save yourself a migration later.
How mobile accessibility testing maps to WCAG criteria
WCAG criteria are abstract by design, but each one corresponds to something concrete on screen, which is what makes them the natural checklist for mobile accessibility testing. The most useful way to read the guidelines is issue by issue: what the criterion asks for, and which users are impacted when you ignore it. The table below condenses the mapping, and the subsections that follow explain the ones mobile teams get wrong most often.
| Mobile issue | WCAG criteria | Who is impacted |
|---|---|---|
| Missing accessible name | 1.3.1, 2.4.6, 4.1.2 | Screen-reader users reach an element with nothing announced |
| Poor alt text | 1.1.1 | Users can’t perceive an image’s purpose |
| Undeclared control role | 1.3.1, 3.3.2, 4.1.2 | Custom controls aren’t announced as interactive |
| Duplicate names | 1.3.1, 4.1.2 | Users can’t tell two controls apart |
| Low color contrast | 1.4.3 | Low-vision and color-blind users can’t read text |
| Text won’t resize | 1.4.4 | Enlarged text is truncated or pushed off-screen |
| Small touch targets | 2.5.5, 2.5.8 | Motor-impaired and many touchscreen users mis-tap |
| Locked orientation | 1.3.4 | Users with fixed-mounted devices can’t use the app |
Names, roles, and labels
Assistive technology can only announce what your app exposes. An accessible name (1.3.1, 2.4.6, 4.1.2) must be present on every interactive and non-text element, and it must be meaningful, descriptive, and unique. Without one, a screen reader reaches the element and has nothing to say. Meaningful alternative text (1.1.1) is the same idea for images: the text must convey the content, purpose, and context of the image, not merely note that an image exists. Interactable role (1.3.1, 3.3.2, 4.1.2) covers custom controls. A view that looks like a button but never declares the button role won’t be announced as one, so users never learn it’s tappable. Duplicate names (1.3.1, 4.1.2) quietly erode trust: three buttons all named “Open” leave assistive-technology users guessing which one does what.
Color contrast and text resizing
Color contrast (1.4.3) requires sufficient contrast between text and its background; users with low vision or color blindness can’t read text that fails it. The AA threshold is a 4.5:1 ratio for normal text. Text resizing (1.4.4) requires content to survive being enlarged up to 200% without loss of information or function. On mobile this is the most common Dynamic Type problem: when a user scales text up and the layout isn’t inside a scroll view, the enlarged text moves off-screen, and the information is simply gone. The user never knows it was there.
Touch targets and orientation
Touch target size is governed by two criteria: 2.5.5 (Target Size, AAA) and 2.5.8 (Target Size Minimum, AA). Targets that are too small are difficult or impossible to hit for many touchscreen users, especially those with motor impairments or tremors. Screen orientation (1.3.4) requires that content and operation not be locked to a single orientation. Some users mount a phone or tablet to a wheelchair in a fixed orientation, so an app that only works in portrait becomes unusable for them, and content must not be lost, blocked, or overlapped when the orientation changes.
Label pronunciation pitfalls
Three smaller issues all trace back to how a screen reader speaks a label: capitalization that changes inflection, sentence-like labels that end in a period and get read with a pause, and special characters or emoji inside a control’s name (3.1.6, 3.3.2). Each can distort pronunciation enough to change or lose the control’s meaning. A label like “Go!” or “✓ Done” rarely reads the way you intend.
What WCAG 2.2 adds for mobile apps
WCAG 2.2 is the current recommendation. It keeps everything in 2.1 and adds nine success criteria; several land squarely on mobile:
- Focus Not Obscured (Minimum) (2.4.11, AA). When a component takes focus, it must not be entirely hidden behind sticky headers, toolbars, or overlays. Mobile keyboards and bottom sheets are the usual culprits.
- Dragging Movements (2.5.7, AA). Any function that uses a drag must also work with a single pointer without dragging. Carousels, sliders, map panning, and reorder gestures all need a non-drag path such as buttons.
- Target Size (Minimum) (2.5.8, AA). Pointer targets must be at least 24 by 24 CSS pixels, with defined exceptions for inline and user-agent controls.
- Consistent Help (3.2.6, A). Help mechanisms such as a contact link or chat launcher stay in the same relative order across screens.
- Redundant Entry (3.3.7, A). Users aren’t forced to re-enter information they already provided in the same process, a frequent friction point in multi-step mobile checkouts.
- Accessible Authentication (Minimum) (3.3.8, AA). No step of a login may require a cognitive-function test. This reaches directly into mobile sign-in flows built on puzzles, codes typed from memory, or CAPTCHAs; supporting a password manager or platform biometric satisfies it.
One correction worth making explicitly: 4.1.1 Parsing has been removed from WCAG 2.2 as obsolete. If your checklist was built against WCAG 2.1, drop that criterion, because it no longer applies.
How the ADA turns WCAG into a legal expectation
A note before the specifics: this is a summary of the regulatory landscape, not legal advice. For anything binding, read the primary sources linked here and talk to counsel.
The Americans with Disabilities Act names no technical standard. It requires accessibility but doesn’t say “conform to WCAG.” Over time, WCAG became the yardstick regulators and courts use to decide what accessible means in practice, and recent rulemaking has made that explicit for a large class of organizations.
Title II: state and local government
In April 2024 the Department of Justice finalized a rule under Title II adopting WCAG 2.1 Level AA as the technical standard for the web content and mobile applications of state and local governments. It is the first federal regulation to mandate a specific technical standard for digital accessibility across a broad category of entities, and it names mobile apps directly. This is not a web-only rule.
The compliance dates were extended in April 2026. Entities serving populations of 50,000 or more now have until April 26, 2027; entities serving fewer than 50,000 people, and special district governments, have until April 26, 2028. If you build apps for transit agencies, public universities, courts, or municipal services, this is a hard deadline, not a best practice.
Title III: private business
No federal rule yet sets a technical standard for private businesses under Title III. In practice, courts treat WCAG 2.1 AA as the de facto benchmark for whether a site or app is reasonably accessible, and the Title II rule signals where enforcement is heading even though it doesn’t bind private companies directly.
The exposure is real and growing. Federal web-accessibility lawsuits under Title III reached 3,117 in 2025, a 27% increase over the prior year; counting state-court filings, the total exceeded 5,000, according to the American Bar Association. Mobile apps are named in these filings, not just websites. A compliance testing tool can report an app’s conformance against WCAG, but it can’t replace understanding the standard the courts are measuring against.
The practical takeaway: target WCAG 2.1 AA as your floor and 2.2 AA as your forward-looking standard. Legal risk attaches to your app, not only your website.
iOS accessibility: Apple’s guidelines and APIs
Apple’s Human Interface Guidelines and the UIAccessibility API are, in effect, the concrete implementation of the WCAG criteria above. Get the platform primitives right and you satisfy most of the mapping section by construction.
VoiceOver, Apple’s screen reader, reads four attributes in a fixed order: label, value, trait, hint.
- Label describes the element’s purpose: “Submit order,” not “blue button.” This is the accessible name from criterion 4.1.2.
- Value carries the current state of a stateful control, such as a slider’s setting or a toggle’s on/off state.
- Trait communicates the element type, such as button, link, header, or adjustable, which shapes how VoiceOver navigates and what users expect. This is the interactable role.
- Hint describes the result of acting on the element, and should be supplied only when that result isn’t obvious from the label.
Beyond the four attributes, Apple’s guidance covers grouping related elements so VoiceOver reads them as a unit, ordering focus logically, and marking decorative images as hidden so they don’t clutter the reading order. Dynamic Type is Apple’s text-scaling system: supporting it means text resizes to the user’s chosen size and your layout accommodates the change without truncation, which is the direct mobile expression of criterion 1.4.4. Apple’s guidelines also call for touch targets of roughly 44 by 44 points, the platform’s answer to the target-size criteria.
Android accessibility: Google’s guidelines and APIs
Android mirrors the same ideas with its own vocabulary. Google’s guidance and the TalkBack screen reader cover the same WCAG ground as VoiceOver does on iOS, which is why accessibility testing on mobile devices generally means exercising both screen readers rather than picking one.
- contentDescription provides a text alternative for UI that has no visible text, such as an ImageButton or ImageView. Descriptions should convey purpose and result, stay unique, and stay concise. (Text composables announce their own text, so they don’t need one.) This is the accessible name and meaningful alt text criteria in Android form.
- TalkBack announces content through synthesized speech and performs actions in response to gestures. It is the screen reader those descriptions feed.
- Touch target minimum on Android is 48 by 48 dp (40 dp is allowed in the tighter confines of Wear OS).
- The AccessibilityService API is the framework for exposing UI to, and interacting with, assistive technology; live regions, custom actions, and traversal order all flow through it.
The three target-size numbers are worth holding side by side, because teams conflate them: WCAG sets a floor of 24 by 24 CSS pixels, iOS guidance points to about 44 points, and Android asks for 48 dp. They measure the same intent in three unit systems, so design to the largest that applies to your platform and you clear all three at once.
Where mobile accessibility testing fits
Everything above reduces to a few high-level expectations that mobile accessibility testing has to verify: expose correct semantics to assistive technology, keep content legible and operable, and don’t trap users in a single mode of interaction. WCAG defines those expectations, the ADA makes WCAG 2.1 AA the practical benchmark in the United States, and Apple’s and Google’s platform APIs give you the means to meet them on each device.
Confirming that you’ve met them is a separate activity, and there’s no single way to do it. Most teams use a combination that fits their app and their release process:
- Manual screen-reader passes with VoiceOver and TalkBack, to hear what a screen-reader user actually hears while moving through a flow.
- Automated checks for the issues that scale well, such as color contrast, missing labels, and undersized targets, run early and often.
- Real-device testing, including changing device settings like font size and contrast, to catch what emulators miss and confirm layouts hold up under real conditions.
No one method proves conformance on its own; effective mobile accessibility testing combines them. Start from the criteria in this guide, decide which levels and versions apply to your situation, and choose the mix of manual and automated testing that demonstrates you meet them.
Frequently asked questions
Does the ADA require WCAG for mobile apps?
For state and local governments, yes: the DOJ’s 2024 Title II rule adopts WCAG 2.1 AA for web content and mobile apps, with compliance due in 2027 or 2028 depending on population served. For private businesses under Title III there is no federal technical rule, but courts treat WCAG 2.1 AA as the de facto standard.
What WCAG level do I need, AA or AAA?
AA. It addresses the most common barriers and is the level referenced by regulators and courts. AAA is worth aiming for selectively, but it isn’t realistic to meet in full across an entire app.
What’s the difference between WCAG 2.1 and 2.2 for mobile apps?
WCAG 2.2 keeps all of 2.1 and adds nine criteria, several of them mobile-relevant: focus not obscured, dragging movements, a 24-pixel target-size minimum, consistent help, redundant entry, and accessible authentication. It also removes 4.1.1 Parsing.
What’s the minimum touch target size?
WCAG 2.2 sets a floor of 24 by 24 CSS pixels. Apple’s guidance points to about 44 by 44 points and Android asks for 48 by 48 dp; design to the platform figure that applies.
Do I need to support both VoiceOver and TalkBack?
Yes. They are the primary screen readers on iOS and Android respectively, so mobile accessibility testing has to exercise both; conformance depends on your app exposing correct names, roles, values, and hints to each.
