Designing for Accessibility in Mobile Apps

An accessible mobile app is one that people can use regardless of disability, whether they are blind and navigating with a screen reader, have low vision and use large text, have limited dexterity, are hard of hearing, or find complex interfaces difficult to process. In practice, designing for accessibility means a handful of concrete things: enough colour contrast, text that scales without breaking the layout, touch targets large enough to hit reliably, every control properly labelled for screen readers, alternatives to complex gestures, captions for audio, clear language and forms that explain errors helpfully.

None of this is exotic. Apple and Google build extensive accessibility features into iOS and Android, and their design guidelines explain how to support them. The Web Content Accessibility Guidelines (WCAG), the most widely used accessibility standard, can be applied to apps as well as websites. What usually goes wrong is not a lack of tools but a lack of attention: accessibility is left until the end, treated as a compliance checkbox or tested only with automated scanners.

This guide explains why accessibility matters for apps, which standards and laws apply, and the practical design decisions that make the biggest difference, covering visual design, touch and motion, screen readers, forms, content and cognitive accessibility. It also covers how to build accessibility into your design and development process, how to test it properly and the mistakes teams most often make.

Why accessibility matters for mobile apps

More people than most teams assume

The World Health Organization estimates that around 1.3 billion people, about one in six of the world's population, experience significant disability. It also estimates that at least 2.2 billion people have some form of near or distance vision impairment. Red-green colour vision deficiency alone is commonly estimated to affect around one in twelve men and one in two hundred women of Northern European descent. And as populations age, more people develop changes in vision, hearing, dexterity and memory that affect how they use technology.

Mobile devices are often central to independent living for disabled people. Screen readers, magnification, voice control and switch access are built into modern smartphones, which means an accessible app can give someone the same access to banking, shopping, healthcare or work tools as anyone else. An inaccessible one locks them out.

Permanent, temporary and situational limitations

Microsoft's inclusive design guidance popularised a useful way of thinking about this. Disabilities can be permanent, such as having one arm; temporary, such as a broken wrist; or situational, such as holding a baby in one arm while trying to use a phone with the other. The same design decision, making an app usable with one hand, helps all three.

Mobile use is full of situational limitations: bright sunlight that washes out low-contrast text, a noisy train where audio cannot be heard, a bumpy bus that makes small targets hard to hit, or a moment of distraction that makes a complex flow hard to follow. Accessible design makes apps better for everyone in these conditions.

Business and legal reasons

Accessibility also makes commercial sense. People who cannot use your app will use a competitor's. A UK survey known as the Click-Away Pound report found in 2019 that a majority of disabled internet users had left websites they found difficult to use, and the same frustration applies to apps. Accessible apps also tend to have clearer structure and better usability, which benefits all users and can reduce support costs.

The legal case is growing too, as the next section explains. Accessibility requirements now apply to many apps in Europe, the United States and elsewhere, and legal claims relating to inaccessible digital services have become more common.

The standards and laws that apply

WCAG: the common reference point

The Web Content Accessibility Guidelines, published by the World Wide Web Consortium (W3C), are the most widely referenced accessibility standard. Despite the name, they are routinely applied to mobile apps, and the W3C publishes guidance, known as WCAG2ICT, on applying them to non-web software. WCAG is organised around four principles: content must be perceivable, operable, understandable and robust. Each principle contains testable success criteria at three levels, A, AA and AAA. Most laws and policies require Level AA.

The current version is WCAG 2.2, published in October 2023. It added several criteria particularly relevant to mobile, including a minimum target size for interactive elements, alternatives to dragging movements and rules to make authentication less dependent on memory or puzzles. Many legal requirements still reference WCAG 2.1, so check which version applies to you, but designing to 2.2 AA covers both.

Platform guidelines

Apple's Human Interface Guidelines and Google's Material Design and Android accessibility documentation explain how to support each platform's assistive technologies, including VoiceOver and TalkBack screen readers, Dynamic Type and font scaling, Switch Control and Switch Access, and voice control. Following them is the most practical way to meet WCAG on mobile, because they describe how users with disabilities actually experience each platform.

Legal requirements

The legal landscape varies by country and sector, so treat the following as an overview rather than legal advice.

In the European Union, the European Accessibility Act has applied since 28 June 2025. It covers a range of consumer products and services, including e-commerce, banking services, e-books, certain transport services and electronic communications, and those requirements extend to the mobile apps that deliver them. The harmonised European standard EN 301 549, which incorporates WCAG, is the usual benchmark for compliance.

In the United Kingdom, the Public Sector Bodies Accessibility Regulations 2018 require public sector websites and mobile apps to meet accessibility standards and publish accessibility statements. For private businesses, the Equality Act 2010 requires service providers to make reasonable adjustments so that disabled people are not placed at a substantial disadvantage, which can include digital services.

In the United States, the Department of Justice adopted a rule in 2024 under Title II of the Americans with Disabilities Act requiring state and local government web content and mobile apps to meet WCAG 2.1 Level AA, with compliance deadlines phased according to the size of the entity; check the current dates. For private businesses, courts have increasingly applied Title III of the ADA to digital services. In the well-known Robles v. Domino's Pizza case, a federal appeals court held in 2019 that the ADA applied to Domino's website and app, and the Supreme Court declined to review that decision.

Other countries, including Canada, Australia and Israel, have their own accessibility laws. If your app serves users across several markets, designing to WCAG 2.2 AA and the platform guidelines is the most practical way to meet most requirements at once.

Visual design: contrast, text size and colour

Colour contrast

Low-contrast text is one of the most common accessibility problems, and on mobile it is made worse by small screens, glare and dimmed displays. WCAG Level AA requires a contrast ratio of at least 4.5 to 1 between normal text and its background, and 3 to 1 for large text. It also requires a ratio of at least 3 to 1 for meaningful graphics and for the visual boundaries of interface components such as input fields, buttons and focus indicators.

Light grey placeholder text, thin pale fonts and text placed over photographs are frequent offenders. Check contrast with a tool during design, not after development, and check both light and dark modes, because a palette that works in one can fail in the other.

Text that scales

Many people increase the system text size on their phones, and some use very large settings. iOS supports this through Dynamic Type, and Android through font size and display size settings, which recent versions extend to very large sizes. Your app should respect these settings rather than locking text at a fixed size.

Supporting larger text is not only a development task. It is a design decision. Layouts need to adapt when text grows: labels may wrap to several lines, horizontal rows may need to stack vertically and fixed-height containers may need to expand. WCAG requires that text can be resized up to 200 percent without loss of content or functionality. Design key screens at the largest common text sizes to make sure nothing is cut off, overlaps or becomes unreachable.

Do not rely on colour alone

Information conveyed only through colour, such as a red outline for an error, green for success or coloured lines on a chart, is invisible to many people with colour vision deficiency and to screen reader users. Always pair colour with another cue: an icon, a text label, a pattern or a change in shape. An error field should say what is wrong, not just turn red.

Support system preferences

Beyond text size, iOS and Android let users request bold text, increased contrast, reduced transparency, dark mode and reduced motion. Respecting these settings, which both platforms expose to developers, lets people configure the experience they need without your app overriding their choices.

Touch, gestures and motion

Make touch targets big enough

Small buttons and links are hard to tap accurately for people with tremors, limited dexterity or large fingers, and for anyone using a phone on the move. Apple recommends a minimum touch target of 44 by 44 points, and Google recommends at least 48 by 48 density-independent pixels for Android. WCAG 2.2 sets a lower minimum at Level AA, 24 by 24 CSS pixels with some exceptions, and recommends 44 by 44 at the stricter AAA level. In practice, following the platform guidelines is the safer target.

The visible icon can be smaller than the touch area, as long as the tappable region around it meets the minimum. Leave enough space between targets so that people do not activate the wrong one, and be particularly careful with destructive actions such as delete, which should not sit right next to frequently used buttons.

Provide alternatives to complex gestures

Swipes, long presses, pinches and multi-finger gestures can be difficult or impossible for people with motor impairments and for screen reader users, whose gestures are partly taken over by the screen reader itself. WCAG requires that functions using multi-point or path-based gestures can also be operated with a single pointer action, such as a tap, and WCAG 2.2 adds a similar requirement for dragging movements. In practice, every swipe-to-delete should have a visible delete option, every drag-to-reorder should have an alternative such as move up and move down buttons, and any action hidden behind a long press should also be available elsewhere.

Do not depend on device motion

If your app uses shaking, tilting or other device movements to trigger actions, offer another way to do the same thing and allow users to turn motion triggers off. People who mount their phone on a wheelchair, or who have tremors, may not be able to use motion reliably, and accidental activation can be a problem.

Handle animation and timing with care

Large animations, parallax effects and automatic transitions can cause discomfort or nausea for people with vestibular disorders. Respect the system's reduce motion setting by replacing large movements with simpler fades or no animation. Avoid content that flashes more than three times per second, which can trigger seizures.

Time limits can also exclude people who need longer to read, decide or type. Where a time limit is necessary, such as a session timeout, warn users before it expires and let them extend it. Avoid carousels that move automatically without a way to pause them.

Support orientation and input methods

Do not lock the app to portrait or landscape unless the function genuinely requires it. Some users have their device mounted in a fixed orientation. Support external keyboards, switch devices and voice control by making sure all functionality can be reached and operated without touch alone.

Designing for screen readers and assistive technology

Screen readers convert what is on the screen into speech or braille. On iOS, the built-in screen reader is VoiceOver; on Android, it is TalkBack. Users move through an app by swiping between elements or exploring the screen by touch, and the screen reader announces each element's label, its role, such as button or heading, and its state, such as selected or expanded. For this to work, the app must describe itself accurately.

Label every control meaningfully

Icon-only buttons are the most common screen reader failure. A magnifying glass, a heart or a three-dot menu means nothing to a screen reader unless it has an accessible label. Labels should describe the purpose, not the appearance: "Search", "Add to favourites" and "More options", not "Magnifying glass icon". Avoid repeating the element type, because the screen reader already announces it. "Submit" is better than "Submit button".

Images need the same thought. Informative images need a short description of what they convey. Decorative images should be hidden from assistive technology so users do not have to listen to them.

Use native components and correct semantics

Standard platform controls, such as native buttons, switches, lists and text fields, come with accessibility support built in. Custom components often do not, unless developers add the right roles, states and actions. Use native components wherever possible, and when custom ones are necessary, make sure they expose the same information. Mark section headings as headings so screen reader users can jump between them, which is often how they skim a screen.

Cross-platform frameworks such as Flutter and React Native provide their own accessibility properties that map to VoiceOver and TalkBack. They work well, but only if developers use them deliberately.

Make reading and focus order logical

Screen readers move through elements in an order that should match the visual and logical order of the screen: top to bottom, left to right in most languages, with related items grouped. Complex layouts sometimes produce a confusing order, such as a price read before the product name it belongs to. Group related elements, such as a product card's image, title and price, so they are read together.

When something changes on screen, such as a dialog opening, an error appearing or new content loading, move focus or announce the change so that screen reader users know it has happened. When a dialog closes, return focus to a sensible place rather than to the top of the screen.

Communicate state and feedback

Toggles should announce whether they are on or off, tabs whether they are selected, and expandable sections whether they are open. Success messages, errors and loading states should be announced, not just shown visually.

Test with real assistive technology

The only reliable way to know whether an app works with a screen reader is to use it with one. Designers and developers should learn the basic VoiceOver and TalkBack gestures and regularly navigate their own app with the screen turned off or the screen curtain enabled.

Forms, content, media and cognitive accessibility

Forms that help rather than hinder

Forms are where many users give up, and they are especially difficult for people using screen readers, voice input or switch devices. Every field needs a visible label that stays on screen while the user types; placeholder text that disappears is not a label. Use the correct input types so the right keyboard appears, such as a numeric keypad for phone numbers and an email keyboard for email addresses, and support autofill and password managers.

When something goes wrong, explain the error in plain words next to the field, say how to fix it and announce it to assistive technology. "Enter a date in the format DD/MM/YYYY" is far more useful than "Invalid input". Do not clear what the user has already entered when showing an error.

WCAG 2.2 also addresses authentication. Logins should not depend on remembering or transcribing information, or solving puzzles, without an accessible alternative. Supporting password managers, passkeys, biometric login and copy and paste for one-time codes all help.

Clear, predictable content

Cognitive accessibility covers people with learning disabilities, dyslexia, attention difficulties, memory impairments and those affected by stress, fatigue or unfamiliar languages. Good practice includes using plain language and short sentences, explaining or avoiding jargon, keeping navigation and layouts consistent across screens, breaking long processes into clear steps with progress indicators, using familiar icons with text labels, and asking for confirmation before irreversible actions. These choices help everyone, especially people using an app quickly on the move.

Audio and video

Video content needs captions for people who are deaf or hard of hearing and for anyone watching without sound, which on mobile is very common. Important visual information in videos may also need audio description or a text alternative. Do not autoplay audio, and give users clear controls to pause, stop and adjust volume.

Notifications and haptics

Alerts that rely only on sound or vibration exclude some users. Pair them with visible messages, and make sure important notifications are readable by screen readers. Haptic feedback can be a helpful extra cue but should not be the only one.

Building accessibility into your process and testing it

Accessibility is far cheaper to build in than to fix later. Retrofitting an app after launch often means redesigning screens, rewriting custom components and retesting everything. Making it part of each stage of development avoids most of that cost.

In planning and requirements

Set a clear target, usually WCAG 2.2 Level AA plus the relevant platform guidelines, and include accessibility in acceptance criteria for every feature. A user story is not done until it works with a screen reader, supports large text and meets contrast and target size requirements.

In design

Build accessibility into your design system. Define colour palettes that meet contrast requirements, typography that scales, components with adequate touch targets and focus states, and patterns for errors and empty states. Annotate designs with accessibility information for developers, such as labels for icon buttons, heading levels, reading order and what should happen to focus when a screen changes. Check designs at large text sizes and in dark mode before development begins.

In development

Prefer native components, set accessibility properties deliberately, respect system settings for text size, motion and contrast, and include accessibility in code reviews. Automated checks can catch some problems during development: Xcode's Accessibility Inspector and audits on iOS, Google's Accessibility Scanner and Android Studio lint checks on Android, and accessibility checks in automated UI test frameworks such as Espresso. Commercial tools can add further coverage.

In testing

Automated tools find only a portion of accessibility issues. They can detect missing labels or low contrast, but cannot judge whether a label makes sense, whether the reading order is logical or whether a flow is usable. Manual testing should include navigating key journeys with VoiceOver and TalkBack, using the largest text sizes and display zoom, operating the app with an external keyboard or switch control, testing with reduce motion and increased contrast enabled, and checking colour use in greyscale.

The most valuable testing involves disabled people themselves. Usability sessions with screen reader users, people with low vision, motor impairments or cognitive disabilities reveal problems that internal teams consistently miss. Specialist accessibility testing organisations can recruit participants and provide expert audits.

After launch

Publish an accessibility statement explaining your app's level of accessibility, known issues and how users can report problems. Provide an easy way for users to give feedback, act on it, and include accessibility checks in every release so that new features do not introduce regressions.

Common accessibility mistakes in mobile apps

Leaving accessibility until the end. Treating accessibility as a final audit almost always leads to expensive rework and compromises. Build it into design and development from the start.

Relying only on automated tools. Automated scanners are useful but catch only part of the problem. An app can pass every automated check and still be very difficult to use with a screen reader.

Unlabelled icon buttons. This is one of the most frequent and most damaging issues for screen reader users, and one of the easiest to fix.

Fixed text sizes and rigid layouts. Ignoring system text settings, or allowing large text to overflow and overlap, makes apps unusable for many people with low vision.

Custom components without accessibility support. Custom sliders, pickers, tabs and menus often look polished but are invisible or confusing to assistive technology unless built carefully.

Gesture-only interactions. Hiding important actions behind swipes or long presses, with no visible alternative, excludes many users.

Using placeholder text as labels. Labels that disappear when typing begins make forms harder for everyone and especially for people with memory or attention difficulties.

Accessibility overlays and quick fixes. Third-party tools that promise to make products accessible automatically do not fix underlying problems in an app's code and design, and they are no substitute for building accessibility properly.

Not involving disabled users. Designing for people without involving them leads to assumptions that do not hold. Even a few sessions with users of assistive technology can transform an app's usability.

If you are planning a new app or reviewing an existing one, an accessibility audit is a practical starting point. An experienced mobile development partner can assess your app against WCAG and platform guidelines, prioritise fixes by impact and help build accessibility into your design system and release process so it stays accessible as the app grows.