Accessibility Testing for Native Mobile Apps vs Progressive Web Apps

Why Native and PWA Accessibility Testing Aren't the Same

A native app and a PWA can share the same backend, the same design system, and even the same product team, and still fail accessibility testing in completely different places. The reason is the accessibility tree each one builds.

A native Android or iOS app talks to the operating system through Android's AccessibilityService API or Apple's UIAccessibility protocol, which expose native widgets, buttons, switches, lists, directly to TalkBack or VoiceOver. A PWA, even one installed to a home screen and running full screen, still executes inside the device's browser engine, so it exposes HTML and ARIA to the browser's own accessibility tree instead.

• Different accessibility trees mean different automation. A scanner built on web ARIA rules cannot inspect a native Android view hierarchy or an iOS UIKit tree.
• Different failure modes surface. Native apps commonly fail on custom controls missing content descriptions; PWAs commonly fail on div-based buttons with no keyboard support.
• The W3C's mobile accessibility guidance confirms WCAG 2 applies to native apps directly, so "we tested the web version" does not cover the native binary.

Globally, the World Health Organization estimates 1.3 billion people, 16 percent of the world's population, live with significant disability. Every one of those users interacts with either a native accessibility API or a browser's accessibility tree, never both at once, which is exactly why testing has to happen on both surfaces independently.

How Native Mobile Accessibility Testing Works

Native accessibility testing validates whether an app's UI elements are correctly exposed to the platform's assistive technology layer, not whether the code looks correct.

• Automated checks run through Appium with an accessibility scanning hook, evaluating rules like missing content descriptions, unlabeled buttons, and undersized touch targets against the platform's own accessibility node tree.
• TestMu AI covers this with 18 automated Android rules and 15 automated iOS rules, triggered via the AccessibilityService-based lambda-accessibility-scan hook inside an existing Appium suite.
• Manual testing means installing the app on a real device, not an emulator, and navigating with TalkBack or VoiceOver switched on, since emulators can behave differently from the sensors and rendering paths on physical hardware.
• Google's own Accessibility Scanner and Apple's Xcode Accessibility Inspector give a free first pass, but neither runs in CI/CD or scales past a handful of manual checks per release.

For teams building or automating native mobile checks, our guide on automating accessibility for Android and iOS apps covers the Appium setup in more depth.

How PWA Accessibility Testing Works

A PWA is a web app first, so its accessibility testing looks like web testing with one added step: verifying it still behaves correctly once installed and running full-screen outside a browser chrome.

• Automated scanning uses axe-core against the rendered DOM, checking the same 39 WCAG-aligned rule set used for any web page: alt text, contrast, form labels, heading structure, and ARIA correctness.
• Because a PWA is a single-page app in most implementations, a one-time page scan misses modal dialogs, route changes, and dynamically loaded content. A Workflow Scan that steps through the actual user journey catches what a static scan cannot.
• Installed-mode testing matters specifically for PWAs: install the app to a real device's home screen and confirm keyboard traps, focus order, and screen reader behavior hold up without the browser's address bar and navigation chrome present.
• Service worker-driven offline states and cached views need their own accessibility pass, since content served from cache can render before ARIA live regions or focus management scripts finish initializing.

For general PWA testing beyond accessibility, see our tips for testing a PWA.

Native vs PWA: Key Accessibility Testing Differences

Side by side, the two testing approaches share a goal, WCAG conformance, but almost nothing about how they get there.

Screen Reader and Assistive Technology Differences

Screen reader usage is now overwhelmingly a mobile behavior, which is exactly why testing on real devices, not just desktop browsers, decides whether a compliance claim is credible.

WebAIM's 10th Screen Reader User Survey found that 91.3 percent of respondents use a screen reader on a mobile device, with VoiceOver used by 70.6 percent and TalkBack by 34.7 percent of mobile screen reader users. Both readers behave differently depending on whether they are driving a native app or a browser tab.

• In native mode, VoiceOver and TalkBack read the accessible name, role, and value the platform API reports for each widget directly, so a mislabeled native button is silent or reads a raw resource ID.
• In browser mode, the same screen readers read the accessible name computed from HTML semantics and ARIA attributes, so the same mislabeling bug looks completely different: an unlabeled link might read the full destination URL instead of nothing.
• Swipe gestures for navigating by heading, link, or landmark work in both modes, but landmark and heading structure only exists in a PWA if the HTML defines it; native apps rely on the platform's own grouping and traversal order instead.
• Testing "the same interaction" on both surfaces with the same screen reader is the only way to confirm parity, since a pass on one tells you nothing about the other.

A Step-by-Step Native App Accessibility Testing Workflow

A repeatable native testing pass looks the same whether it runs manually once or automatically on every build:

• Confirm the existing Appium suite is green and locators resolve correctly before adding accessibility checks on top of it.
• Add the accessibility capability to the Appium session and set LT_USERNAME and LT_ACCESS_KEY as environment variables rather than hardcoding them.
• Call the accessibility scan hook, driver.executeScript("lambda-accessibility-scan") in Java, after each stable screen following navigation waits, not mid-transition.
• Run the suite on a real device in the cloud rather than an emulator, since touch target sizing and rendering can differ from physical hardware.
• Review the generated report for the build, prioritizing Critical and Serious severity issues that block screen reader navigation entirely.
• Turn on TalkBack or VoiceOver on the same device and manually walk the three or four most-used flows, since automation only catches 30 to 40 percent of issues.
• File every confirmed issue with its WCAG reference through an integration like JIRA so remediation is tracked against a standard, not a vague description.

A Step-by-Step PWA Accessibility Testing Workflow

A PWA's workflow mirrors standard web accessibility testing, with an added device-install check most teams skip:

• Run a Full Page Scan against the deployed PWA to catch the machine-detectable baseline: alt text, contrast, labels, and heading order.
• Add a Workflow Scan across the core user journey, since a single-page scan will not evaluate modals, in-app navigation, or content injected after route changes.
• Wire the same checks into CI/CD using the Playwright or Cypress integration so a regression in a pull request fails the build instead of reaching production.
• Install the PWA to a real Android and a real iOS device from the browser's install prompt, then repeat the core journey with the app running full-screen.
• Turn on TalkBack and VoiceOver on those same installed instances and confirm focus order and announcements still work without the browser chrome present.
• Test the offline and cached state specifically, since service-worker-served content can render before scripts that manage focus or ARIA live regions finish running.
• Compare results against the native app's report if one exists, since shared design components can still be implemented inconsistently across the two codebases.

Common Accessibility Pitfalls by Platform

Most native and PWA accessibility bugs are platform-specific, which is why a generic checklist misses so many of them.

Native app pitfalls

• Custom-drawn controls, canvas-based charts, custom sliders, that never set a content description, so TalkBack announces nothing or a generic "button."
• Touch targets under the platform minimum, 44x44 points on iOS per Apple's Human Interface Guidelines, that pass a visual review but fail for users with motor impairments.
• Screens that lock orientation without a documented reason, breaking users who rely on a fixed device angle for a mounted or shared device.
• Dynamic Type and system font scaling ignored, truncating text for low-vision users who increase system font size rather than zoom.

PWA pitfalls

• Clickable divs and spans built to look like buttons but missing role, tabindex, and keyboard event handlers, so keyboard and screen reader users cannot activate them.
• Focus getting lost after a route change in a single-page app, dropping the user back at the top of the document with no indication anything happened.
• Install prompts and offline banners injected via JavaScript with no ARIA live region, so screen reader users never hear that the state changed.
• Fragment-identifier hash routing treated as a single page by a scanner that has not enabled Fragment Identifier support, hiding per-route violations entirely.

Choosing and Combining the Right Testing Approach

Most product teams do not choose one platform's testing approach over the other, because most products that ship a PWA also ship a native app for the same market. The decision is how to combine the two without doubling headcount.

• If you only ship a PWA, standard web accessibility tooling covers you, but still add the installed-mode and offline-state checks most web-only teams skip.
• If you only ship native apps, budget separately for Appium-based automation and real-device manual testing since no web scanner can substitute for either.
• If you ship both, standardize on a platform that reports native and web accessibility results in one dashboard, so a compliance officer is not reconciling two separate tools to answer "are we accessible."
• Either way, treat the 30 to 40 percent automated coverage figure as the same ceiling on both platforms. Manual screen reader testing is not optional on the surface you consider "easier."

TestMu AI's app automation platform runs Appium-based accessibility scans for native apps, while the same account's browser automation covers PWA scanning, both reporting into the same Accessibility dashboard. For teams authoring native mobile tests without writing Appium code, KaneAI supports inserting an accessibility scan step directly into a mobile test flow.

Conclusion

Start by confirming which accessibility tree each of your surfaces actually builds, native platform APIs for the app, the browser's ARIA tree for the PWA, then assign automated scanning and real-device screen reader testing to each one separately. Treating "we tested accessibility" as a single checkbox across both platforms is how a compliant PWA ships next to a native app that a screen reader user cannot navigate.

To set up automated WCAG checks across both native apps and PWAs from one platform, see the accessibility automation documentation, and start with our web accessibility guide if the PWA side needs a fundamentals refresher first.