When a Swipe Becomes a Wall: Why Mobile Accessibility Testing Needs Real Users

I’ve spent years working as an accessibility tester. As someone who relies on a screen reader every day, I can tell you this: mobile accessibility brings its own unique set of hurdles. Many EdTech companies assume that if their app meets WCAG guidelines, it’s good to go. But the reality is, the moment a learner with disabilities tries to use that app, the gaps become painfully clear.

This has become even more important as district and state RFPs increasingly demand WCAG-compliant mobile apps. In this blog, we’ll go over why mobile accessibility matters, the common gaps we see, and how teams can fix them.

Why Mobile Accessibility Matters More than Ever

For users with vision disabilities, mobile is the primary way we access content. Conveniently, mobile strips away the extra clutter of desktop websites. Reading books or even navigating classrooms is more accessible for learners with disabilities. Research shows that more than 60% of learners with disabilities prefer mobile devices over desktops because they’re portable and cheaper than laptops.

When accessibility is overlooked, entire learning journeys become inaccessible for students who rely on assistive technology.

The Basics of Mobile Accessibility Don’t Cut It

Yes, mobile apps require the usual checks: color contrast, headings, and element labeling. But those alone don’t reveal the real-world issues. Here are common barriers that surface during accessibility reviews:

Swipe-All Problem

Imagine opening a login screen with four options: Privacy, Accessibility, Support, and Login. A sighted user can pick one easily. For a screen reader user, a single swipe sometimes reads all four at once and randomly sets focus on just one. This can make something as basic as logging in difficult for users.

Role Labeling Matters

If an element is labeled only as ‘Support’ without identifying it as a button, a screen reader user won’t know it’s clickable. Without proper roles, navigation becomes uncertain.

The Missing Back Button

Some apps take you three or four screens deep, but without a working back button, the only way out is to close and restart the app.

Sliders That Don’t Slide

Video players often use a drag slider for rewinding or fast-forwarding. But with VoiceOver or TalkBack, that slider is unusable. Without alternative buttons like ‘Forward 10 seconds’ or ‘Rewind 20 seconds,’ the feature doesn’t work.

Silent Submissions

After pressing ‘Submit,’ feedback like ‘Login Successful’ should be announced. Too often, no announcement occurs, leaving users unsure whether the action was successful.

These aren’t edge cases; they’re blockers that make an app completely unusable. Identifying these barriers is just the first step. While many edtech teams rely on automated testing to check accessibility, that approach alone leaves most real-world issues undiscovered.

Why Automated Testing Isn’t Enough

When it comes to mobile, automated tools barely scratch the surface. In my experience, only about 20-30% of accessibility checks can be done with tools. You need manual testing for the rest.

Even manual testing by someone who does not use assistive technologies can miss critical issues. Screen reader behavior changes with each iOS or Android update. Testers who do not use these tools daily may not notice when something stops working. This is why involving testers with disabilities is essential. They understand the technology firsthand and can tell when an issue is a bug rather than an intended feature.

Additionally, iOS and Android handle accessibility differently. iOS provides a consistent VoiceOver experience, while Android’s TalkBack behavior can vary across devices. Platform differences can impact usability, making real-user testing on both iOS and Android essential for WCAG compliance.

Beyond Checklists: Complex Interactions

Even when apps pass automated and manual checks, accessibility challenges often appear in more complex interactions. Real learning experiences rely on features that go beyond basic compliance, and these are the moments where barriers really show up:

• Drag-and-drop activities should announce when an item is picked up, guide focus to valid drop zones, and confirm when the item has been dropped.
• Interactive diagrams should always include alt text or a text-based version so that screen reader users can understand the content.
• Offline content, such as downloaded books, must still allow proper navigation using headings, footnotes, and page turns.

Without these, learners hit walls where others glide through. Even when complex interactions are handled correctly, teams often assume compliance is proven once an Accessibility Conformance Report (ACR) is in place. In reality, the report can hide as much as it reveals.

Accessibility Conformance Reports: Reading Between the Lines

Many teams point to their Accessibility Conformance Reports (ACRs) or Voluntary Product Accessibility Templates (VPATs) as proof of compliance. But a glossy report doesn’t mean the app is usable. A strong ACR should detail not just WCAG compliance, but also which versions and screen readers were tested. For example, iOS VoiceOver or Android TalkBack/Samsung’s screen reader. Without that specificity, the report is just a checkbox exercise.

Quick Fixes with High Impact

If you’re a product or engineering leader under pressure to meet RFP requirements fast, here are three things to prioritize:

1. Separate Focus

Each element should be reachable with a single swipe.

2. Double-Tap Activation

Every button or link must respond to the standard screen reader action.

3. A Reliable Back Button

Never trap a user on a screen.

These alone can turn an inaccessible app into something at least functional while you work toward deeper fixes.

Raising the Bar for Development Teams

Accessibility is about ensuring real learners can actually use your app. That means following the simple checklist:

• Testing with real assistive technology users, not just tools.
• Document clearly in your ACRs which guidelines, versions, and screen readers were tested.
• Designing with updates in mind, since OS-level changes can alter how screen readers behave.

Accessibility Is More than Compliance: Build Equity and Trust

If given a choice between a website and an app, most users with disabilities, including myself, will choose the app. Research indicates that learners with disabilities prefer
mobile-first experiences because these experiences are simpler and more accessible. However, this preference only matters if the app is fully compatible with screen readers and other assistive technologies.

For edtech companies, the stakes could not be higher. Learners with disabilities are already choosing
mobile-first solutions. If an app is not accessible, learners will walk away, and districts evaluating the product against an RFP will take note.

Accessibility is about usability, equity, and building trust. The only way to achieve this is by testing with the people who rely on these technologies the most.