A progressive web app is, at runtime, three things layered on top of a normal website: a Web App Manifest, a service worker, and an installed-mode chrome that replaces the browser frame with the operating system’s own task-switcher entry. Each of the three layers introduces its own accessibility obligations — and each fails its assistive-tech users in a different, separately-debuggable way.

In 2020 the entire conversation collapsed into “WCAG applies to PWAs,” which was technically correct and operationally useless. In 2026 the conversation is split into the four surfaces that actually matter: the install-prompt UX, the manifest properties that drive OS-level affordances, the handoff between the browser’s accessibility tree and the operating system’s accessibility tree once the PWA is launched in standalone mode, and the assistive-tech behavior of the service-worker offline fallback. WCAG 2.2 governs the document; the platform-integration layer is governed by a much patchier mix of W3C drafts, vendor-specific behavior, and ARIA conventions inherited from the web.

The install prompt is the most user-facing PWA surface and, in 2026, still the worst-engineered one. On Chromium, the prompt is gated by beforeinstallprompt, which fires only after a heuristic engagement threshold and which sites typically wire into a custom “Install app” button. That custom button is where accessibility goes wrong: roughly one in three Lighthouse-scoring PWAs renders the install affordance as a <div> or a styled <span> with no role, no accessible name, and no keyboard handler — invisible to a screen reader, unreachable by Tab, and indistinguishable from decorative chrome.

The fix is unglamorous and mandatory: render the install affordance as a real <button>, set an accessible name that includes the verb (“Install Disability World on this device”), expose the same button to all input modalities, and announce success or failure via a live region after the user dismisses the OS-level confirmation sheet. The same applies to the related-applications and beforeinstallprompt dismissed states — both must produce an AT-perceivable status change.

The Web App Manifest grew quietly between 2022 and 2026, and many of its newer properties carry direct accessibility consequences. The matrix below maps the eleven manifest properties that interact with assistive technology to what each browser actually does with them today — across Chrome on Android, Safari on iOS, Edge on Windows, and Firefox on desktop. Properties such as file_handlers, share_target, and window_controls_overlay did not exist in any meaningful form in 2021; in 2026 they shape whether the PWA appears in the OS share sheet, opens files from the system file manager, and renders its own titlebar — all of which the screen reader user must be able to perceive and operate.

The single hardest debugging problem in PWA accessibility, in 2026, is what happens when the user crosses the seam between standalone-mode PWA chrome and the operating system itself. On Android, TalkBack reads the manifest name when the user focuses the home-screen icon, then transitions to reading the in-app accessibility tree once the PWA launches; on iOS 16.4+, VoiceOver does the same for an installed PWA but with one important quirk — the first focusable element after launch is announced without the app-level context that a native iOS app would supply through its UIWindow title.

The PWA author has one tool to bridge this gap: on cold launch, focus a heading or main-region landmark that includes the app name in its accessible label, and set the document <title> to a string that the OS task switcher will read when the user swipes between apps. Without this, the screen-reader user loses the contextual cue that they have switched applications — a “where am I” failure that doesn’t exist for native apps.

When the service worker serves an offline fallback page, two AT-specific failure modes appear: the focus that was inside the now-unloaded page is silently dropped onto the document body, and the offline page itself rarely uses a live region to tell the screen-reader user what just happened. The result is a user who hears one announcement of the offline-page title (if they’re lucky) and otherwise experiences a total loss of context.

The fix is to treat the offline transition as a state change, announce it through a polite aria-live region, restore focus to a known landmark on the offline page, and surface a “Retry” control as a real button rather than the “Reload” link most service-worker boilerplates ship. The same applies to the foreground-sync recovery path: when connectivity returns and the service worker drains the queue, that too is a state change the AT user must be told about.

The “should we ship a PWA or a native app” question now has an accessibility dimension as well as a feature-completeness one. Below, we compare the same hypothetical news-reader app delivered four ways — as a PWA on Android, as a PWA on iOS 16.4+, as a native iOS app, and as a native Android app — across the five surfaces a screen-reader user touches first.

Ship the install affordance as a real <button> with an accessible name. Wire a polite live region to the userChoice outcome. Fill out name, short_name, description, lang, and dir in the manifest, and ship maskable icons for Android. If you opt into window_controls_overlay, render and label your own titlebar; if you opt into file_handlers or share_target, treat the resulting launch as a state change and announce it on entry.

Restore focus to a labeled landmark every time the screen-reader user crosses the seam — first launch, app-switcher return, offline transition, share-target launch, reconnection. Treat each crossing as a discrete event that owes the user a perceivable announcement and a known focus anchor. None of this is hard; almost none of it is shipped consistently.

A PWA in 2026 can be very nearly indistinguishable from a native app for an assistive-tech user — on Android. On iOS it is closer than it was, and still has a real gap. The gap is closing roughly one manifest property per year. For procurement teams choosing between a PWA and a native app, the accessibility question is no longer “can a PWA be accessible?” — it can. The question is whether the team building it has read the eleven manifest rows above and accepted that each one is part of their deliverable.