Mobile Accessibility: Guidelines, WCAG 2.2 Criteria, and Examples

What Is Mobile Accessibility?

Mobile accessibility is the practice of making mobile websites and native iOS and Android apps usable by people with visual, hearing, motor, and cognitive disabilities, including people who rely on screen readers, voice control, magnification, or captions.

The audience is large: the WHO estimates that 1.3 billion people, 16% of the world's population, experience significant disability. There is no separate standard for mobile. W3C states that it does not have separate mobile accessibility guidelines; WCAG applies to mobile web content, native apps, and hybrid apps, with W3C's WCAG2Mobile guidance explaining how.

Why Is Mobile Accessibility Important?

• Legal requirements now name mobile apps - The US Department of Justice's 2024 ADA Title II rule sets WCAG 2.1 Level AA as the technical standard for state and local governments' web content and mobile apps.
• Vision impairment is common - At least 2.2 billion people have a near or distance vision impairment, according to the WHO vision fact sheet, which makes text size, contrast, and screen reader support everyday requirements.
• Hearing loss is widespread - More than 1.5 billion people, nearly 20% of the global population, live with hearing loss, and the WHO projects that over 700 million people could have disabling hearing loss by 2050, so captions and visual alerts matter.
• Accessible apps work better for everyone - Large touch targets, captions, and readable text help anyone using a phone one-handed, in sunlight, or with the sound off.

Which WCAG 2.2 Criteria Matter Most on Mobile?

All of WCAG applies, but these success criteria describe problems that show up most often on small touch screens. Three of them, 2.4.11, 2.5.7, and 2.5.8, are new in WCAG 2.2, according to W3C's summary of what is new in WCAG 2.2.

To see how a real page measures up, I ran axe-core against the TestMu AI ecommerce playground at a 390 x 844 touch viewport, similar to a current iPhone, on Chrome on the TestMu AI cloud, with WCAG 2.0, 2.1, and 2.2 A and AA rules. The page passed 29 rules, including the WCAG 2.2 target-size check, and failed 3: low text contrast on 8 elements, 1 link with no accessible name, and 1 scrolling marquee that users cannot pause. The contrast failures break 1.4.3 in the table, and the marquee breaks 2.2.2 Pause, Stop, Hide.

iOS vs Android Accessibility Features

Your app has to work with the assistive technology built into each operating system. These are the features to test against, named as Apple and Android Accessibility Help name them:

Screen readers depend on every control exposing a name and a role, so an icon button with no label is silent to both VoiceOver and TalkBack. Text scaling breaks layouts that use fixed heights. Voice control depends on visible labels matching the accessible name, so a user can say the word they see on the button.

Designing Mobile Apps for Different Disabilities

• Visual - Label every image and icon button, support system text size, and keep contrast at WCAG levels. See screen reader accessibility testing for how to check announcements.
• Hearing - Caption every video, provide transcripts for audio, and never rely on sound alone for alerts.
• Motor - Use targets of at least 24 by 24 CSS pixels, give every drag or gesture a tap alternative, and avoid short timeouts.
• Cognitive - Keep navigation consistent, use plain labels, offer autocomplete on forms, and pair text with icons where it helps recognition.

Note: Test your app with VoiceOver and TalkBack on real devices. Try TestMu AI Today!

How Do You Test Mobile Accessibility?

Combine an automated scan with manual checks on real devices, then confirm with users who have disabilities. The step-by-step process, tools, and common myths are covered in the guide to mobile accessibility testing.

For native apps, TestMu AI's App Scanner inspects Android and iOS apps screen by screen on the Real Device Cloud, flagging TalkBack compatibility gaps, undersized touch targets, and unlabeled native components with no code required, and the same checks run inside Appium suites for regression coverage. The documentation on screen readers on real devices covers the manual VoiceOver and TalkBack pass.

AI tools now draft alt text and suggest fixes, such as enlarging a tap target, but a person using VoiceOver or TalkBack still has to confirm the fix works. Our Accessibility Testing Suite was launched in April 2025 and recognized as the #1 Product of the Day on Product Hunt.

Best Practices for Mobile Accessibility

• Design for it first - Set minimum target sizes, contrast pairs, and text scaling rules in the design system, so developers inherit them.
• Use native components - Standard iOS and Android controls expose names and roles to VoiceOver and TalkBack by default; custom controls need that work done by hand.
• Put accessibility in the test plan - Give each release accessibility acceptance criteria tied to WCAG success criteria, not a single end-of-cycle audit.
• Cover every disability group - A screen reader pass alone misses caption, target size, and cognitive-load problems.

Conclusion

Start with the WCAG 2.2 table above: measure your smallest tap targets, try every drag and gesture with a single tap, and turn on VoiceOver and TalkBack to hear whether each control is named. Then run the same checks on real Android and iOS devices with TestMu AI's App Scanner and track them release by release.