Over 1.3 billion people worldwide live with some form of disability—that's roughly 16% of the global population who might struggle to use your mobile app if it isn't designed with accessibility in mind. Yet most designers I work with are completely confused about which mobile accessibility standards they should be following. Should you stick with WCAG guidelines that have been around for years, or are there specific mobile standards you need to know about?
The truth is, mobile accessibility isn't just about following one set of rules. It's about understanding how people with different abilities interact with touchscreens, voice controls, and gesture-based navigation. What works perfectly on a desktop website might be completely unusable on a 5-inch screen that someone's trying to operate with one hand whilst walking down the street.
Mobile accessibility is not a one-size-fits-all solution—it requires understanding the unique challenges that come with smaller screens, touch interfaces, and mobile contexts
After designing accessible mobile experiences for nearly a decade, I can tell you that the confusion around standards is real. WCAG has been the gold standard for web accessibility, but mobile platforms like iOS and Android have developed their own guidelines that address touch-specific interactions, screen readers, and mobile-only features. Understanding the differences between these approaches—and knowing when to use which—can make or break your app's usability for millions of potential users.
WCAG stands for Web Content Accessibility Guidelines—and yes, I know that sounds quite technical, but stick with me here. These guidelines were created by the World Wide Web Consortium (W3C) to make websites and digital content accessible to everyone, including people with disabilities. Think of WCAG as a rulebook that tells designers and developers how to create websites that work for people who might be blind, deaf, have motor difficulties, or other challenges.
The current version is WCAG 2.1, which builds on the foundation of four main principles. These principles are organised around making content perceivable, operable, understandable, and robust. Each principle has specific guidelines underneath it, and each guideline has testable success criteria at three different levels: A, AA, and AAA—with AAA being the highest level of accessibility.
Now here's where it gets interesting for mobile experience designers: WCAG was originally designed for websites, not mobile applications. While many of the principles still apply to mobile apps, there are some gaps that need filling.
Mobile accessibility standards are quite different from web standards, and there's good reason for that. When we're talking about phones and tablets, we're dealing with touch screens, voice controls, and completely different ways people interact with content. The two main players here are iOS and Android—each has developed their own comprehensive accessibility guidelines that work specifically with their operating systems.
Apple's Human Interface Guidelines cover accessibility features like VoiceOver, Switch Control, and Voice Control. These aren't just nice-to-have features; they're built right into iOS and millions of people rely on them daily. Android's Material Design guidelines work similarly, focusing on TalkBack, Select to Speak, and Live Caption functionality.
The thing is, mobile accessibility isn't just about following rules—it's about understanding how people actually use their devices. Someone might be using their phone one-handed whilst walking, or they might have limited vision and depend on screen readers. The standards account for these real-world scenarios in ways that general web guidelines simply can't.
Both iOS and Android provide free accessibility testing tools built right into their development environments—use them early and often during your experience design process.
Each platform has specific technical requirements that go beyond basic accessibility principles. iOS requires proper accessibility labels and traits, whilst Android focuses on content descriptions and semantic markup that works with TalkBack.
Right, let's get straight to the point—WCAG and mobile accessibility guidelines aren't the same thing, even though they're trying to solve similar problems. WCAG was originally built for websites, which means it focuses heavily on things like keyboard navigation and mouse interactions. Mobile guidelines, on the other hand, were designed from the ground up for touch screens, gestures, and the way people actually use their phones.
The biggest difference is how people interact with content. WCAG assumes you've got a keyboard and mouse; mobile guidelines know you're using your fingers. This changes everything—button sizes need to be bigger (at least 44x44 pixels), touch targets can't be too close together, and you need to think about how someone holds their phone.
Mobile screens are tiny compared to desktop monitors, and people use apps whilst walking, on the bus, or in bright sunlight. Mobile guidelines account for this reality. They push for larger text, better contrast ratios, and simpler navigation patterns. WCAG is getting better at addressing mobile needs—especially in version 2.1—but it's still catching up to guidelines that were mobile-first from day one.
After years of crafting accessible mobile experiences, I've spotted the same problems cropping up time and again. Most designers aren't doing this on purpose—they just don't know what barriers they're accidentally creating for users with disabilities.
The biggest culprit is poor colour contrast. Text that's too light against backgrounds makes reading impossible for people with visual impairments. Then there's the missing alt text on images and buttons; screen readers can't tell users what these elements actually do without proper descriptions.
Small touch targets drive me mad—and they're everywhere! Buttons and links need to be at least 44x44 pixels, but so many apps squeeze them smaller. Navigation that only works with gestures leaves keyboard users completely stuck.
Auto-playing videos without captions exclude deaf users straight away. Complex forms without proper labels confuse screen reader users, whilst content that disappears too quickly (looking at you, toast notifications) doesn't give people enough time to read it.
The most accessible apps are often the most usable for everyone—fixing barriers benefits all users, not just those with disabilities
Focus indicators that vanish when navigating with keyboards make apps unusable for many people. These barriers seem small individually, but together they can make apps completely inaccessible to millions of users.
Right, you've designed your app experience and now you need to test whether it actually works for everyone—including users with disabilities. This is where things get a bit tricky because there's no single "accessibility test" you can run. Instead, you need to check multiple things across different scenarios.
The best approach combines automated testing tools with real human testing. Automated tools like Accessibility Scanner for Android or the Accessibility Inspector for iOS can catch obvious problems quickly—think missing alt text for images or buttons without proper labels. But they won't spot everything.
Here's what we do when testing apps for accessibility compliance:
The real test comes from getting actual users with disabilities to try your app. They'll find issues that no automated tool ever will—like confusing navigation flows or missing context that makes features unusable in practice.
Designing an accessible mobile experience isn't just about ticking boxes—it's about creating something everyone can use. After years of crafting digital experiences, I've learnt that the best approach is to bake accessibility into your design process from day one rather than trying to bolt it on afterwards.
Start with your colour choices. Make sure there's enough contrast between text and backgrounds so people with visual impairments can read everything clearly. Your app should work just as well for someone who's colour blind as it does for someone with perfect vision.
Focus on these key areas when crafting your experience:
Test your app with VoiceOver on iOS or TalkBack on Android turned on. If you can navigate your entire app using only voice commands, you're on the right track.
The beauty of following mobile accessibility standards is that you end up with an app that's better for everyone—not just people with disabilities. Clear navigation, readable text, and intuitive controls benefit every single user.
Designing accessible mobile experiences isn't just about ticking boxes—it's about creating experiences that work for everyone. WCAG gives us the foundation, but mobile accessibility standards help us apply those principles to the unique challenges of touchscreens, small displays, and finger navigation. The two work hand in hand rather than competing against each other.
What strikes me most after years of working with design teams is how often accessibility gets treated as an afterthought. Teams will spend months perfecting animations and visual effects, then scramble to add screen reader support at the end. That approach makes everything harder and more expensive. Start with accessibility in mind from day one—your future self will thank you when you're not rebuilding entire user flows.
The psychology-based design principles and user research foundations we craft become the blueprint that ensures accessibility isn't an afterthought—it's built into the experience from the ground up. Whether your development team uses native platforms, cross-platform tools, or emerging technologies, they need accessibility requirements clearly defined in the experience design. Let's craft accessible experiences that work for everyone.