Mobile App Accessibility: Make Apps User-Friendly

W3C has never published a separate set of mobile guidelines, so WCAG applies to native iOS and Android apps by interpretation. Each criterion gets read against screens instead of web pages, and that reading is where audits start to disagree.

Regulators haven’t settled on one WCAG version either. The US Department of Justice requires WCAG 2.1 Level AA for state and local government apps, with compliance due 26 April 2027 for entities of 50,000 or more residents (DOJ, 2026). EN 301 549 V4.1.1, published on 2 September 2026 to support the European Accessibility Act, moves to WCAG 2.2 Level AA (ETSI, CEN and CENELEC).

What is mobile app accessibility?

Getting an iOS or Android app, native or hybrid, to work with screen readers, switch devices, voice control and larger text is what mobile app accessibility means. It spans design and engineering, and teams measure it against WCAG and the platform guidelines.

Low vision and blindness mean screen readers, magnification, contrast and text scaling. On the hearing side you need captions, transcripts, and haptic alternatives to audio cues. Motor impairments call for switch input and voice control, large targets, and a non-gesture route to every action. Cognitive needs are mostly about simple flows. No forced timeouts, and reduced motion where it helps.

For scale, the World Health Organization puts the number of people with a significant disability at 1.3 billion, or 16% of the global population (2023).

Methods from web accessibility carry over only partly. A native app has no DOM, so each control has to pass its name, role and state to the operating system through platform accessibility properties.

The failures cluster in the basics. A University of Washington analysis of nearly 10,000 free Android apps found that 23% of the 8,901 apps with image-based elements left more than 90% of those elements without a content description (Ross, Zhang, Fogarty and Wobbrock, 2020).

The US Department of Justice cited that research in its 2024 Title II rule.

It also isn’t only about permanent disability. Apple’s Human Interface Guidelines note that lighting conditions and screen brightness can affect how anyone interacts with an interface, which is why inclusive design treats accessibility as a baseline, not an add-on.

Which assistive technologies does a mobile app need to support?

Start with the screen reader, which means VoiceOver on iOS and TalkBack on Android. After that comes alternative input (Switch Control and Voice Control on iOS, Switch Access and Voice Access on Android), and then the system’s own text and display settings.

Screen readers

WebAIM’s Screen Reader User Survey #10 (December 2023 to January 2024) found that 91.3% of respondents use a screen reader on a mobile device. VoiceOver leads at 70.6%, ahead of TalkBack at 34.7%.

The survey is self-selected, so read those shares as direction, not market share. Test on both platforms either way.

Both screen readers announce only what the app exposes through the platform’s accessibility API, meaning the name, role, state and value of each control. A control that exposes no name gives the user nothing to act on.

Switch and voice input

These tools drop the assumption that a user can touch the screen.

On iOS, Switch Control moves through the interface using external switches, game controllers or sounds such as a click or a pop. Voice Control lets people tap, swipe and type by speaking, and it depends on labeled interface elements.

Android has Switch Access, which controls the device with one or more switches or a keyboard instead of the touchscreen. Voice Access does the same job with spoken commands, on Android 5.0 (API level 21) and higher.

Swipe-only actions are the usual miss. Apple’s guidelines say to pair a swipe-to-dismiss with a button, so people with limited dexterity or an assistive device can do the same thing.

Display and text settings

Both platforms ship a system font size setting, and apps are expected to follow it.

On iOS that setting is Dynamic Type. Apple’s guidelines ask apps to let people enlarge text by at least 200 percent (140 percent on watchOS), through Dynamic Type or custom UI.

Increase Contrast and Reduce Motion also need a response from the app, and Dark Mode gets checked for contrast in both appearances.

How does WCAG 2.2 apply to native mobile apps?

Only by interpretation. W3C publishes no separate mobile guidelines, so its Mobile Accessibility Task Force maintains a draft note, Guidance on Applying WCAG 2.2 to Mobile Applications, that maps the Level A and AA criteria to native, hybrid and mobile web apps.

The note is informative, not a standard, and W3C still labels it an in-progress draft as of October 2026. Cite the WCAG criteria in audit reports, and use the note to settle how a criterion reads on a phone.

W3C published WCAG 2.2 as a Recommendation on 5 October 2023. It adds 9 success criteria to 2.1 and removes 4.1.1 Parsing as obsolete.

The mobile-relevant criteria began with WCAG 2.1 (2018). 1.3.4 Orientation and 2.5.1 Pointer Gestures arrived then, along with 2.5.4 Motion Actuation and a target size rule at Level AAA (2.5.5). A locked orientation fails anyone whose device sits on a fixed mount.

Four of the new Level AA criteria in 2.2 reach mobile directly.

• 2.4.11 Focus Not Obscured (Minimum) says a sticky header or footer cannot entirely hide the focused control.
• 2.5.7 Dragging Movements requires a single-pointer alternative for every drag.
• Under 2.5.8 Target Size (Minimum), targets measure at least 24 by 24 CSS pixels, or sit far enough apart.
• 3.3.8 Accessible Authentication (Minimum) means sign-in can’t rely on memorizing or retyping credentials, so support password managers such as iOS Keychain.

WCAG is written in CSS pixels, and a native app has none. Deque’s guidance substitutes 24 pt on iOS and 24 dp on Android for 24 CSS pixels, and reads “web page” as “screen”.

That interpretation step is where audits diverge. Allyant (2025) notes that applying web-based criteria to native apps has produced inconsistent results, which is the gap the W3C note targets.

Legal requirements for mobile app accessibility in the EU and US

Most apps fall under the European Accessibility Act or the ADA, depending on where the users are. The US now has a technical rule for state and local government apps. Private ones still don’t have one.

Directive (EU) 2019/882, the EAA, has applied since 28 June 2025 (National Disability Authority, Ireland, 2026). Microenterprises that provide services are exempt if they have fewer than 10 staff and turnover or a balance sheet of EUR 2 million or less (Directive (EU) 2019/882). EN 301 549 V4.1.1, published 2 September 2026, moves the reference from WCAG 2.1 to WCAG 2.2 Level A and AA (ETSI, CEN and CENELEC, as reported by Davis Wright Tremaine).

On the US side, the ADA Title II standard is WCAG 2.1 Level AA for web content and mobile apps (US Department of Justice, 2024). Deadlines fall on 26 April 2027 for entities with 50,000 or more residents and 26 April 2028 for smaller entities and special districts (DOJ interim final rule, 20 April 2026).

European Accessibility Act and EN 301 549

The EAA covers consumer-facing services such as e-commerce, consumer banking, electronic communications, e-books and passenger transport booking. Mobile apps that deliver those services fall inside it, and non-EU companies selling to EU consumers must comply.

The directive states functional requirements. EN 301 549 supplies the technical test, and it goes beyond WCAG for native software, so WCAG conformance alone does not equal EN 301 549 conformance (Deque, 2026).

Version V3.2.1 (2021) references WCAG 2.1 Level A and AA, and most EAA guidance still points to it. V4.1.1 arrived on 2 September 2026 and references WCAG 2.2 Level A and AA, but it confers presumption of conformity only after the European Commission cites it in the Official Journal of the EU, which Deque puts at around 30 November 2026.

Sources split on what applies in the meantime. BrowserStack says V3.2.1 stays the recognized baseline until that citation happens. Ecorpit’s July 2026 analysis says the Commission harmonised V3.2.1 only under the Web Accessibility Directive, not the EAA.

ADA, DOJ Title II and Section 508

The DOJ’s April 2024 final rule named WCAG 2.1 Level AA as the technical standard for the web content and mobile apps of state and local governments.

On 20 April 2026 an interim final rule pushed both compliance dates back by one year. The DOJ cited staffing, budget and technical expertise gaps, plus dependence on third-party vendors.

Only the timing changed. The standard and the scope of covered apps stay as they were, and Title II’s nondiscrimination and effective-communication duties apply in the meantime.

Section 508 covers information and communication technology that US federal agencies develop, buy or use, mobile apps included.

Private-sector apps have no federal technical rule yet. The Title II framework is the likely blueprint if the DOJ writes one for Title III (Consumer Financial Services Law Monitor, 2026).

Accessibility statements and VPATs

In the EU, EAA service providers have to publish an accessibility statement, a public document saying how the app meets the requirements. EAA guidance suggests linking it from the store listing or the in-app menu.

US vendors tend to fill in a VPAT instead. The Voluntary Product Accessibility Template reports, criterion by criterion, how a product conforms to WCAG, Section 508 and EN 301 549.

Apple adds a store-facing option. The Human Interface Guidelines (updated June 2025) point to Accessibility Nutrition Labels, which show on the App Store which accessibility features an app supports.

Exemptions and gaps

Some apps stay outside the rules. Microenterprises providing services (fewer than 10 staff, EUR 2 million or less in turnover or balance sheet) fall outside the EAA. A provider can also claim disproportionate burden or fundamental alteration, though that takes a formal assessment. Archived content, meaning anything not updated or edited after 28 June 2025, is excluded from the EAA, and the ADA Title II rule keeps limited exceptions of its own, archived web content among them.

The baselines don’t line up. The DOJ rule still says WCAG 2.1 AA, EN 301 549 is moving from 2.1 AA to 2.2 AA, and WCAG 2.2 is already W3C’s current Recommendation.

WCAG 2.2 keeps every 2.1 criterion except 4.1.1 Parsing (W3C), so one WCAG 2.2 Level AA target covers the WCAG portion of all of them. EN 301 549’s extra software requirements still need their own check.

What touch target size should a mobile app use?

Design every tap target to 48 by 48 on both platforms. WCAG 2.2 Level AA sets a lower floor, and the platform guidelines set the practical standard.

Apple’s own table lists 44 by 44 pt as the default control size and 28 by 28 pt as the minimum. Many guides call 44 the minimum, so the number most teams quote is stricter than what Apple’s guidelines state (Apple Human Interface Guidelines, as of October 2026).

WCAG 2.5.8 has two escape hatches. A target under 24 by 24 passes if a 24-pixel circle centered on it overlaps no other target or other undersized target’s circle, or if it sits inline in a sentence (W3C).

The visible icon doesn’t have to hit the number. Google’s guidance says an icon that looks 24 by 24 dp can sit inside a 48 by 48 dp target once padding counts, and Material components in Jetpack Compose add that padding automatically.

A 48 dp target measures about 9 mm on any screen, inside the 7 to 10 mm range Google cites for touchscreen objects.

Dense toolbars are where this falls apart. Icon buttons packed edge to edge look fine but miss the 8 dp spacing Google recommends.

Gesture-only actions fail the same users. WCAG 2.5.1 asks for a single-pointer alternative to path-based gestures such as swipes, and 2.5.7 asks for one for dragging.

My rule is to use 48 by 48 as the design token on both platforms. Drop to Apple’s 44 only where a layout can’t hold 48, and treat 28 pt (Apple’s minimum) and 24 (WCAG) as documented floors, not targets.

Color contrast, text scaling and motion settings

Text needs 4.5:1 contrast against its background, large text and UI components need 3:1, and every screen has to hold up at the largest system text size with Reduce Motion on.

Contrast

WCAG, Apple and Google all publish thresholds, and they differ at the edges.

Under WCAG 1.4.3 and 1.4.11 (AA), text needs 4.5:1, large text (18 pt, or 14 pt bold) needs 3:1, and so do the parts of a UI component needed to identify it and its states (WebAIM). Apple’s Accessibility Inspector uses 4.5:1 up to 17 pt, 3:1 at 18 pt, and 3:1 for bold text at any size.

Android wants 4.5:1 below 18 sp or for bold text below 14 sp, and 3:1 for everything else (Android Developers, updated September 2026).

The bold rule is where they split. Apple’s table gives all bold text 3:1, while WCAG and Android reserve 3:1 for bold at 14 or larger, so a 12 pt bold label can pass the Inspector and still fail WCAG.

Measure color contrast on every state, because 1.4.11 covers states as well as the default look.

Apple adds a settings rule. If an app misses the minimum by default, it should at least switch to a higher-contrast scheme when Increase Contrast is on, and contrast gets checked in both light and dark appearances.

Text scaling

Scaling text rarely breaks the text. It breaks the layout around it.

Apple’s guidelines recommend a 17 pt default and an 11 pt minimum for custom type styles on iOS. Thin weights call for larger sizes, which is the core of accessible typography on a phone.

Android measures text in sp, and its font scaling is non-linear, so doubling the scale factor does not double the rendered size. It also separates font scale, which resizes text only, from density scaling, which resizes text, controls, images and spacing together (Android Developers).

Apple’s checklist asks that layouts reflow, avoid truncation and avoid overlapping elements at the largest accessibility sizes. Accessibility Inspector’s Dynamic Type and clipped-text audits flag the common breaks.

Motion

When Reduce Motion is on, Apple’s guidelines ask apps to cut automatic and repetitive animation, including zooming, scaling and peripheral motion.

The same guidelines suggest tightening animation springs to reduce bounce, tracking animations directly to gestures and skipping depth changes on the z-axis. Replace x, y and z transitions with fades, and avoid animating into and out of blurs.

Dim Flashing Lights is a separate setting. Video playback has to respond to it by reducing flicker (Apple testing guidance).

How to expose names, roles and focus order in code

Every control needs a name and a role, plus a state where it has one, exposed through the framework’s accessibility properties. Then check that focus order follows the reading order. The property names change between frameworks, but the model stays the same: label, role, state, value, order.

Native iOS: UIKit and SwiftUI

An iOS control exposes a label, traits and, for adjustable elements, a value. Accessibility Inspector’s audit checks each element’s label (its “element description” test) and verifies that an element implements what its traits require.

SwiftUI’s isHeader trait marks an element as a header that divides content into sections, like a navigation bar title (Apple Developer Documentation). The accessibilityElement(children: .combine) modifier groups related views so a card reads as one item.

Hints are the optional layer. VoiceOver reads a hint after the label only if the user has hints enabled, so the label has to carry the meaning on its own.

Native Android: Views and Jetpack Compose

contentDescription should state the purpose of the interaction, not the visual, so “Submit” beats “Submit button”. Each item in a LazyColumn gets its own description.

Decorative elements get null or hideFromAccessibility so accessibility services skip them. Headings go through Modifier.semantics { heading() }, which lets users move between sections.

For live updates, LiveRegionMode.Polite suits most alerts and Assertive is for time-sensitive content. Neither belongs on fast counters such as countdown timers.

Custom components are the usual gap. A custom low-level composable gives accessibility services nothing until semantics are added by hand, and in Google’s calendar example TalkBack announces only the calendar’s name, not the day the user picked (Android Developers).

Reading order has a default, left to right and then top to bottom. Google’s example shows TalkBack reading two columns of text in the wrong sequence until isTraversalGroup is set on each column.

Form errors need exposing too. Compose’s error semantics make TalkBack read the visible message first and a longer explanation after it, which is how accessible forms get the reason for a failure to the user and not only a red outline.

Cross-platform: React Native and Flutter

React Native maps its props onto native properties. The accessible prop becomes focusable on Android and isAccessibilityElement on iOS (React Native documentation, version 0.87). It also accepts web-style ARIA props such as aria-label and aria-live, and role takes precedence over accessibilityRole.

• Touchable elements are accessible by default, and the label defaults to the concatenated text children.
• accessibilityLiveRegion works on Android only, with none, polite and assertive values.
• Hints cannot be switched off on Android, while iOS reads them only if the user enabled them.
• The docs flag experimental_accessibilityOrder as experimental, and it drops every element it does not list.

Flutter’s standard widgets build the accessibility tree automatically, and the Semantics widget overrides it where an app needs something different. ExcludeSemantics drops decorative subtrees, MergeSemantics folds a subtree into one node, and the Accessibility Guideline API in Flutter’s test library can check contrast and touch target size.

Tools for testing mobile app accessibility and what each one catches

Start with the platform’s own audit tools, because they are free and map to platform rules. That means Accessibility Inspector and XCUITest audits on iOS, and Accessibility Scanner and Espresso checks on Android. Add axe DevTools Mobile when one team needs the same WCAG-mapped rules across iOS, Android and React Native.

Google adds two Android extras. The Google Play pre-launch report runs the same Accessibility Test Framework on uploaded builds and sorts findings into touch target size, low contrast, content labeling and implementation, while Android Studio’s Compose UI Check mode flags low color contrast and text stretched on large screens (Android Developers).

The real choice is where the check runs. Inspector and Scanner find problems while you design. XCUITest audits, Espresso checks and axe DevTools Mobile can fail a build, which is where regressions get caught.

How to run a mobile app accessibility test

Test the main tasks on a physical device with one assistive technology on at a time: screen reader first, then switch and voice input, then the visual settings. Log each failure against its WCAG criterion.

1. Start by listing the main tasks on each screen, such as signing in, creating an item and changing a setting. Apple’s guidance uses a to-do app as the example.
2. Build a matrix of devices, accessibility settings and assistive technologies, and cover every device type the app supports.
3. Turn on VoiceOver or TalkBack on a physical device and complete every task using only the screen reader. VoiceOver is not available in Simulator, and Apple suggests the screen curtain, which blanks the display while the screen stays active.
4. While you do that, listen for spoken feedback that conveys each control’s purpose, short announcements, every element reachable by swiping, and temporary messages read aloud (Google’s TalkBack checklist).
5. Switch Control or Switch Access is next. Every touch gesture needs a selectable control or custom action, each item should highlight once, and only actionable items should highlight.
6. Voice Control or Voice Access comes after that. On iOS, the “Show names” and “Show numbers” commands reveal what the system can address by voice.
7. Switch on the visual settings one at a time and re-run the tasks. On iOS that means Larger Accessibility Sizes, Bold Text, Increase Contrast, Differentiate Without Color and Reduce Motion. On Android, test layouts under both in-app scaling and system font or display settings.
8. Run the automated audit on every screen with Accessibility Inspector or Accessibility Scanner, then fix the findings.
9. Finish with users who have disabilities. Google suggests local disability organizations, colleges or universities, or a user testing service.

What automated accessibility tests miss

Automated tests confirm that a label exists, a touch target is big enough and a contrast ratio passes. They can’t judge whether the label makes sense, whether the order fits the task or whether a person can finish the flow.

Apple says it plainly. Clearing every audit issue in Accessibility Inspector does not guarantee a fully accessible app, and testing with VoiceOver still has to follow (Apple Developer Documentation).

Label quality is the first gap. A scanner sees that a description exists, not whether it conveys purpose, and Google’s TalkBack checklist leaves that judgment to a person listening.

Runtime behavior is another. The Accessibility Test Framework inside Android Studio cannot detect issues that appear while the app runs on a device (Android Developers).

Embedded web content is a third. axe DevTools Mobile is built for native content, and Deque says results from WebViews or rendered PDFs can be incomplete, so it recommends axe DevTools for Web or axe Monitor for that content (Deque documentation).

Then there are the known false results. Deque’s mobile known-issues page lists false positives for specific rules, rules that do not run in some cases (Color Contrast, when text and background colors match), and unexpected results in hybrid and cross-platform Android apps when items sit partly off screen (Deque documentation).

Coverage claims conflict. Deque’s 2021 study reports that its automated engine identifies 57 percent of accessibility issues, against the 20 to 30 percent commonly quoted (Deque, 2021).

The study is a vendor measurement of its own tooling, so check whether it was measured on web content or native apps before applying it to either. Treat a clean scan as a regression gate, not as a conformance result.

Mobile App Accessibility FAQ

Do Apple and Google require apps to be accessible?

Apple is moving toward requiring accessibility disclosure, not accessibility itself. App Store Connect Help calls Accessibility Nutrition Labels voluntary to start, with sharing support details required over time for new apps and updates.

Google Play’s accessibility policy covers apps that request the Accessibility Service API, and the pre-launch report adds accessibility suggestions to each upload (Android Developers).

How often should an app be retested for accessibility?

Run automated audits on every build, and repeat the manual screen reader pass whenever a flow or custom control changes.

Apple’s WWDC 2023 session on audits frames XCUITest checks as testing with every build, and Deque’s axe DevTools Mobile can block pull requests in CI.

Can I test with a screen reader on an emulator or simulator?

Not reliably. Apple’s documentation says VoiceOver is not available in Simulator, so test on a physical device.

Android emulators ship without TalkBack, but an image with the Play Store lets you install it (React Native documentation).

How do I switch a screen reader on and off quickly while testing?

Set up a system shortcut before the first pass. On iOS, Apple suggests the Accessibility Shortcut to toggle VoiceOver, which also gives you a way out once testing ends.

On Android, turn on the volume key shortcut in Accessibility settings, then press both volume keys for 3 seconds (React Native documentation).

How can I check how an app looks to someone with color blindness?

Turn on the iOS Color Filters (Red/Green, Green/Red, Blue/Yellow) and Differentiate Without Color in Settings, as Apple’s testing guidance lists.

On Android, Android Studio’s Compose UI Check mode previews the UI for different color vision deficiencies and suggests contrast fixes (Android Developers).

What to Fix First in an Existing App

In an existing app, fix what blocks a task before anything that only slows it, and set up regression checks last. In practice that means unlabeled controls and broken focus order first. Small touch targets, weak contrast and clipped scaled text come next, and an automated audit on every build closes it out.

Screen reader users cannot operate a control without a name, while a small target or low contrast slows a task without stopping it.

The audit gate comes last because enabling it before the backlog is cleared fails every build.

The trade-off is slower merges. A failing audit holds a release until the fix lands, so the first gate should cover only new and changed screens.

Audit rules should move to WCAG 2.2 criteria once the Official Journal cites EN 301 549 V4.1.1.

• Author
• Recent Posts

Bogdan Sandu

Bogdan Sandu specializes in web and graphic design, focusing on creating user-friendly websites, innovative UI kits, and unique fonts.

Many of his resources are available on various design marketplaces. Over the years, he's worked with a range of clients and contributed to design publications like Designmodo, WebDesignerDepot, and Speckyboy, Slider Revolution among others.

Latest posts by Bogdan Sandu (see all)

• What is Backend in Web Development? - September 13, 2026
• What is Frontend Development? - September 11, 2026
• How to Make a Button in Figma: Design Best Practices - September 10, 2026