WCAG for mobile apps works the same way as for websites: native iOS and Android apps and mobile sites are judged by the same 2.2 AA bar, and the 2.1 and 2.2 criteria on orientation, gestures, target size and focus target phones directly. There is no separate mobile version of WCAG.
What changes is how you meet and test each criterion. An app has no HTML, so "alt text" becomes an accessibility label, and the screen reader is VoiceOver or TalkBack driven by swipes instead of keys. This guide maps the criteria to app reality and shows how to test on a real phone.
Quick facts
Standard to use
WCAG 2.2 AA, applied to native apps and mobile web alike.
Key mobile criteria
1.3.4, 1.4.4, 1.4.10, 2.5.1, 2.5.2, 2.5.4, 2.5.7, 2.5.8.
Minimum target
24 by 24 CSS px at AA. Apple suggests 44 by 44 points, Android 48 by 48 dp.
Screen readers to test
VoiceOver on iPhone and TalkBack on Android.
Laws covering apps
The EAA, the ADA Title II rule and many public sector rules include apps.
How WCAG applies to apps
Although its text speaks of web pages, the principles fit any interface. W3C has published a note on applying WCAG 2 to software and documents that are not web pages, and regulators rely on it when they put apps in scope. The EU standard EN 301 549 has a separate chapter for software that mirrors the web criteria, and the US Department of Justice rule for public bodies below federal level covers both their websites and their mobile apps.
A few criteria need interpretation. "Page" becomes "screen", "keyboard" includes external Bluetooth keyboards and switch access, and "CSS pixels" are read as the platform's own independent units (points on iOS, dp on Android). The outcome each criterion asks for stays the same.
Mobile web accessibility follows WCAG directly, because a mobile site is still web content. Test it in the phone's browser with the built-in screen reader running.
WCAG for mobile apps: the criteria that matter
These are the WCAG guidelines for mobile apps that cause the most trouble, with what each one means on a phone.
| Criterion | Level | What it means in an app |
|---|---|---|
| 1.1.1 | A | Icon buttons and meaningful images have an accessibility label |
| 1.3.4 | AA | Both screen rotations are supported, except where one is essential (a piano keyboard app, say) |
| 1.4.4 | AA | Text grows with the system font size setting without being cut off |
| 1.4.10 | AA | Mobile web content fits 320 CSS px wide with no sideways scrolling |
| 2.5.1 | A | Pinch, swipe or multi-finger actions have a single tap alternative |
| 2.5.2 | A | Actions fire when the finger lifts, so a slip can be dragged away |
| 2.5.4 | A | Shake to undo or tilt controls have a button too, and the motion feature can be disabled |
| 2.5.3 | A | Saying the words printed on a button presses it |
| 2.5.7 | AA | Reordering or sliders that need a drag also work with taps |
| 2.5.8 | AA | Touch targets reach 24 by 24 units or have space around them |
| 2.4.11 | AA | Sticky bars and the on-screen keyboard do not cover the focused field |
| 3.3.8 | AA | Logins allow paste and password managers; no puzzle tests |
Labels and roles on iOS and Android
Native apps meet the same criteria with platform APIs instead of HTML. The names differ, the ideas match.
| Need | Web (HTML) | iOS | Android |
|---|---|---|---|
| Name for an icon or image | alt or aria-label | accessibilityLabel | contentDescription |
| What kind of control it is | Native element or role | Accessibility traits | Class name or Role semantics |
| Decorative image | alt="" | Not an accessibility element | importantForAccessibility="no" |
| Field label | label for | Label on the text field | labelFor or a hint |
| Live update | role="status" | Posting an announcement notification | Live region on the view |
| Hint text | aria-describedby | accessibilityHint | Tooltip or hint text |
Cross-platform frameworks expose their own props that map to these. Whatever the framework, check the result with the real screen reader on a real device, since emulators hide many problems.
How to test an app with VoiceOver and TalkBack
Testing an app needs a phone, the built-in screen reader and some patience. Learn the basic gestures first: on both platforms, swiping right jumps forward one item and a double tap activates it.
- Turn on VoiceOver on iPhone (Settings, Accessibility, VoiceOver) or TalkBack on Android (Settings, Accessibility, TalkBack).
- Swipe through each screen. Every control should announce a clear name, its role and its state.
- Turn screen reader off. Set the largest system text size and check nothing is cut off or overlapping.
- Rotate the phone. The app should work in both orientations.
- Connect a Bluetooth keyboard or switch and try to reach every control.
- Measure small icons and check the spacing between them.
- Try voice control and say the visible label of a few buttons.
Setup help is on the official Apple VoiceOver guide and the Android TalkBack help page. Our guides to VoiceOver setup on Apple devices and TalkBack on Android go step by step.
Common mobile accessibility failures
Audits of mobile apps keep finding the same handful of failures.
| Failure | Who it hurts | Fix |
|---|---|---|
| Icon buttons announced as "button" with no name | Screen reader users | Add an accessibility label that says the action |
| Text locked at a fixed size | Low vision users | Use scalable text styles that follow system settings |
| Swipe-only carousel or delete | Switch and motor impaired users | Add buttons for next, previous and delete |
| App locked to portrait | People with a mounted tablet or phone | Support both orientations |
| Close button 16 units wide in a corner | Users with tremor or large fingers | Enlarge the tap area, even if the icon stays small |
| Custom PIN pad that blocks paste | Users of password managers, people with memory issues | Allow paste and platform biometrics |
Mobile web: zoom and input types
For mobile websites, one meta tag decides whether users can zoom at all. Blocking zoom fails 1.4.4 and frustrates everyone with low vision.
Fails: pinch zoom is switched off.
<meta name="viewport" content="width=device-width,
initial-scale=1, maximum-scale=1, user-scalable=no">Passes: the page fits the screen and users can still zoom.
<meta name="viewport"
content="width=device-width, initial-scale=1">Use the right input types too. type="email" and type="tel" bring up the matching on-screen keyboard, and autocomplete values meet the input purpose criterion (1.3.5).
Questions people ask
Do native apps have to meet WCAG?
Yes, in most regulated settings. The EU software chapter of EN 301 549 mirrors the web criteria, and the US Title II regulation names mobile apps alongside websites. W3C also publishes guidance on using WCAG 2 for software that is not a web page.
Is there a separate WCAG for mobile?
No. There is one WCAG, and versions 2.1 and 2.2 added criteria aimed at touch screens, for rotation, multi-finger gestures and tap target spacing. Apple and Android publish their own design guidance on top.
What touch target size does WCAG require for apps?
At level AA, a target needs 24 by 24 units minimum, or enough spacing. Level AAA asks for 44 by 44. Apple's guidance suggests 44 points and Android's suggests 48 dp, which are good defaults.
How do I test a mobile app for WCAG?
Use a real phone with VoiceOver or TalkBack, the largest text size, both orientations, an external keyboard or switch, and voice control. Automated scanners for apps exist but miss most issues that need human judgement.
Do WCAG 2.0 rules cover mobile apps?
WCAG 2.0 applies, but it says nothing about rotation, swipes or how big tap areas must be. Test apps against 2.2 so the touch specific problems are covered.