Mobile App Accessibility: What Every Business Owner Needs to Know

If your business has a mobile app, accessibility is no longer optional. With the European Accessibility Act (EAA) now in force and ADA lawsuits increasingly targeting mobile experiences, app accessibility has moved from a nice-to-have to a legal and business imperative. Yet most business owners have no idea where to start.

This guide explains mobile app accessibility in plain language. You do not need to be a developer to understand what makes an app accessible, why it matters, and what to ask your development team to fix.

Why Mobile App Accessibility Matters Now

More than 60 percent of all web traffic comes from mobile devices, and for many users, a mobile app is their primary — or only — way to interact with your business. People with disabilities use smartphones at roughly the same rate as the general population, but they rely on built-in accessibility features like screen readers (VoiceOver on iPhone, TalkBack on Android), voice control, switch access, and display adjustments to navigate apps.

When your app is not built with these features in mind, it becomes unusable for a significant portion of your audience. The World Health Organization estimates 1.3 billion people live with a significant disability globally. In the United States alone, over 42 million adults have a disability that affects how they use technology.

Beyond the moral case, the business case is clear. Inaccessible apps lose customers, generate negative reviews, and increasingly attract legal action.

Americans with Disabilities Act (ADA)

The ADA does not mention mobile apps specifically — it was written in 1990 — but U.S. courts have consistently ruled that mobile apps offered by businesses open to the public fall under Title III’s “places of public accommodation.” Domino’s Pizza lost a landmark case in 2019 when the Supreme Court declined to hear their appeal of an accessibility lawsuit over their ordering app. Since then, mobile app accessibility lawsuits have increased every year.

In 2025, over 1,200 ADA lawsuits specifically cited mobile app accessibility failures. Common targets include restaurant ordering apps, banking apps, retail apps, and healthcare portals.

European Accessibility Act (EAA)

The EAA, effective since June 2025, explicitly covers mobile applications used for e-commerce, banking, transport, and other consumer services. If your app serves customers in any EU country, it must meet the accessibility requirements outlined in EN 301 549, which references WCAG 2.1 AA and adds mobile-specific requirements.

Penalties vary by country, but they can include fines, mandatory corrective action, and even removal of your app from the market in that country. Our guide on EAA fines by country covers the specifics.

Other Regulations

Canada’s Accessible Canada Act, the UK’s Equality Act, Australia’s Disability Discrimination Act, and Japan’s revised accessibility laws all apply to mobile apps in their respective jurisdictions. If your app has an international user base, accessibility is a global compliance issue.

The Most Common Mobile App Accessibility Problems

You do not need to run a technical audit to understand what typically goes wrong. Here are the issues that affect mobile app users with disabilities most frequently.

1. Touch Targets That Are Too Small

This is the single most common mobile accessibility failure. Buttons, links, and interactive elements that are too small or too close together make it difficult or impossible for people with motor disabilities to tap accurately. WCAG 2.2 introduced Success Criterion 2.5.8, which requires touch targets to be at least 24 by 24 CSS pixels with adequate spacing.

Many apps have tiny close buttons on modals, small icons without sufficient padding, and navigation elements crammed together. This affects not only people with motor disabilities but also older adults and anyone using their phone one-handed.

What to ask your team: “Do all interactive elements meet the 24 by 24 pixel minimum target size? Are there any elements closer than 24 pixels apart?“

2. Missing Labels on Buttons and Icons

When a screen reader user taps a button that only contains an icon — a hamburger menu, a heart for favorites, a cart icon — the screen reader has nothing to announce. The user hears “button” with no description of what the button does. This happens constantly in mobile apps because designers favor icon-only interfaces for visual cleanliness.

Every interactive element needs an accessible name. On iOS, this is the accessibilityLabel. On Android, it is contentDescription. Without these labels, screen reader users are navigating blind.

What to ask your team: “Does every button and icon have an accessibility label that describes its purpose?“

3. Gestures Without Alternatives

Swipe to delete, pinch to zoom, drag to reorder — these gestures feel natural to most users, but they are impossible for people who use switch access, voice control, or certain types of assistive technology. WCAG 2.1 Success Criterion 2.5.1 requires that any functionality triggered by multipoint or path-based gestures can also be performed with a single pointer action.

In practice, this means every swipe action needs a button alternative. Every drag-and-drop needs a different way to accomplish the same result. Every pinch-to-zoom should work with on-screen controls as well.

What to ask your team: “For every gesture-based interaction, is there a button or menu alternative that achieves the same result?“

4. Poor Color Contrast

Just like on websites, insufficient color contrast in mobile apps makes text hard to read for people with low vision or color blindness. The problem is often worse on mobile because screens are smaller, frequently used outdoors in bright light, and color rendering varies significantly across devices.

WCAG 2.1 requires a minimum contrast ratio of 4.5:1 for normal text and 3:1 for large text. Many apps fail this, especially for placeholder text in form fields, disabled button states, and light gray text on white backgrounds.

What to ask your team: “Have we tested our app’s color contrast ratios? Do all text elements and interactive controls meet the 4.5:1 minimum?” Our color contrast guide explains the requirements in detail.

5. Forms That Do Not Work With Screen Readers

Mobile forms are a frequent pain point. Input fields without labels, date pickers that cannot be navigated with a screen reader, dropdown menus that do not announce their options, and error messages that appear visually but are never announced to assistive technology.

If your app includes any kind of form — sign-up, checkout, booking, profile editing — it needs to be tested with VoiceOver and TalkBack. Our accessible forms guide covers the principles that apply to both web and mobile.

What to ask your team: “Can a user complete every form in our app using only a screen reader? Are error messages announced when they appear?“

6. No Support for Dynamic Text Sizes

Both iOS and Android allow users to set a preferred text size in their system settings. Many people with low vision set their text size to 150 or 200 percent of the default. Apps that use fixed font sizes ignore this setting entirely, forcing users with low vision to use magnification gestures that show only a small portion of the screen at a time.

An accessible app respects the user’s system text size preference. This means using relative font sizes and ensuring that layouts adapt when text gets larger without cutting off content or breaking the interface.

What to ask your team: “Does our app respect the system text size setting? What happens to our layout when a user sets their text size to 200 percent?“

7. Videos and Audio Without Captions

If your app includes any video content — product demos, tutorials, promotional videos, user-generated content — it needs captions. This is not just a website issue. The same WCAG requirements (1.2.2 for prerecorded captions, 1.2.4 for live captions) apply to mobile apps. Our video accessibility guide covers this in depth.

What to ask your team: “Do all videos in our app have accurate captions? Is there a process for adding captions to new video content?”

How to Test Your App’s Accessibility

You do not need specialized tools to start testing. Both major mobile platforms have accessibility features built in.

On iPhone (VoiceOver)

  1. Go to Settings, then Accessibility, then VoiceOver, and turn it on
  2. Swipe right to move through elements one by one
  3. Listen for unlabeled buttons (you will hear just “button” with no description)
  4. Try to complete key tasks: sign up, browse products, make a purchase, contact support
  5. Note anywhere you get stuck or hear confusing announcements

On Android (TalkBack)

  1. Go to Settings, then Accessibility, then TalkBack, and turn it on
  2. Swipe right to navigate through elements
  3. Listen for the same issues: unlabeled elements, missing descriptions, confusing navigation
  4. Try the same key user flows

Quick Checks Anyone Can Do

  • Increase text size to the maximum in your phone’s settings and see if the app still works
  • Turn on “Reduce Motion” (iOS) or “Remove Animations” (Android) and check if the app still functions
  • Try using the app in landscape mode — does it work or does it force portrait only?
  • Turn on high contrast or dark mode and check if text remains readable
  • Try to use every feature without any swiping gestures — can you find button alternatives?

What to Do Next

If you have tested your app and found issues, here is a practical path forward.

Prioritize by impact. Fix the issues that block users from completing core tasks first. If users cannot sign up, cannot check out, or cannot access their account, those are your highest priorities.

Add it to your development process. Accessibility should be part of your QA checklist for every release, not a one-time remediation project. Ask your development team to test with VoiceOver or TalkBack before each release.

Set a standard. Tell your team your app must meet WCAG 2.1 AA. This gives them a clear, measurable target. If you are subject to the EAA, this is the minimum legal requirement.

Document your commitment. Publish an accessibility statement in your app or on your website. Our accessibility statement guide walks you through what to include.

Get a professional audit if needed. For complex apps, a professional accessibility audit can identify issues that manual testing misses. Our guide on how to read a WCAG audit report helps you understand what you will receive.

The Bottom Line

Mobile app accessibility is not a separate discipline from web accessibility — it follows the same WCAG principles of perceivable, operable, understandable, and robust. The specifics differ (touch targets instead of click targets, gestures instead of keyboard shortcuts), but the goal is the same: making sure every user can access your product regardless of ability.

The businesses that act now will avoid legal risk, reach more customers, and build better products. The ones that wait will face increasingly expensive remediation and mounting legal exposure.

We’re building a simple accessibility checker for non-developers — no DevTools, no jargon. Join our waitlist to get early access.