Una progressive web app è, a runtime, tre elementi sovrapposti a un normale sito web: un Web App Manifest, un service worker e una chrome in modalità installata che sostituisce il frame del browser con la voce del task switcher del sistema operativo. Ciascuno dei tre livelli introduce le proprie obbligazioni in materia di accessibilità — e ciascuno delude i propri utenti di tecnologie assistive in modo diverso, separatamente diagnosticabile.

Nel 2020 l’intera discussione si riduceva a «WCAG si applica alle PWA», il che era tecnicamente corretto e operativamente inutile. Nel 2026 la discussione è suddivisa nelle quattro superfici che contano davvero: l’UX del prompt di installazione, le proprietà del manifest che guidano le affordance a livello di sistema operativo, il trasferimento tra l’albero di accessibilità del browser e l’albero di accessibilità del sistema operativo una volta avviata la PWA in modalità standalone, e il comportamento delle tecnologie assistive nel fallback offline del service worker. WCAG 2.2 disciplina il documento; il livello di integrazione con la piattaforma è disciplinato da un insieme molto più frammentato di bozze W3C, comportamenti specifici per vendor e convenzioni ARIA ereditate dal web.

Il prompt di installazione è la superficie PWA più esposta all’utente e, nel 2026, ancora quella peggio progettata. Su Chromium, il prompt è subordinato a beforeinstallprompt, che si attiva solo dopo una soglia euristica di interazione e che i siti tipicamente collegano a un pulsante personalizzato «Installa app». È quel pulsante personalizzato il punto in cui l’accessibilità va storta: circa uno su tre PWA con punteggio Lighthouse rende l’affordance di installazione come un <div> o uno <span> stilizzato senza role, senza nome accessibile e senza handler da tastiera — invisibile a uno screen reader, irraggiungibile con Tab e indistinguibile dagli elementi decorativi.

La soluzione è poco appariscente e obbligatoria: rendere l’affordance di installazione come un vero <button>, impostare un nome accessibile che includa il verbo («Installa Disability World su questo dispositivo»), esporre lo stesso pulsante a tutte le modalità di input, e annunciare il successo o il fallimento tramite una live region dopo che l’utente ha congedato il foglio di conferma a livello di sistema operativo. Lo stesso vale per gli stati di related-applications e di beforeinstallprompt dismissed — entrambi devono produrre un cambiamento di stato percepibile dalle tecnologie assistive.

Il Web App Manifest è cresciuto silenziosamente tra il 2022 e il 2026, e molte delle sue proprietà più recenti hanno conseguenze dirette sull’accessibilità. La matrice che segue mappa le undici proprietà del manifest che interagiscono con le tecnologie assistive a ciò che ciascun browser fa effettivamente con esse oggi — su Chrome su Android, Safari su iOS, Edge su Windows e Firefox su desktop. Proprietà come file_handlers, share_target e window_controls_overlay non esistevano in forma significativa nel 2021; nel 2026 determinano se la PWA compare nel foglio di condivisione del sistema operativo, apre file dal file manager di sistema e rende la propria barra del titolo — tutte funzionalità che l’utente di screen reader deve essere in grado di percepire e operare.

Il singolo problema di debug più difficile nell’accessibilità PWA, nel 2026, è ciò che accade quando l’utente attraversa il confine tra la chrome PWA in modalità standalone e il sistema operativo stesso. Su Android, TalkBack legge il name del manifest quando l’utente mette a fuoco l’icona della schermata iniziale, poi passa a leggere l’albero di accessibilità in-app una volta avviata la PWA; su iOS 16.4+, VoiceOver fa lo stesso per una PWA installata ma con un’importante particolarità — il primo elemento focalizzabile dopo il lancio viene annunciato senza il contesto a livello di app che un’app iOS nativa fornirebbe attraverso il titolo UIWindow.

L’autore della PWA ha uno strumento per colmare questa lacuna: al lancio a freddo, mettere a fuoco un’intestazione o un landmark della regione principale che includa il nome dell’app nella propria etichetta accessibile, e impostare il <title> del documento su una stringa che il task switcher del SO leggerà quando l’utente scorre tra le app. Senza questo, l’utente di screen reader perde il segnale contestuale di aver cambiato applicazione — un fallimento del tipo «dove mi trovo» che non esiste per le app native.

Quando il service worker serve una pagina di fallback offline, compaiono due modalità di fallimento specifiche per le tecnologie assistive: il focus che si trovava all’interno della pagina ora scaricata viene silenziosamente spostato sul body del documento, e la pagina offline raramente usa una live region per comunicare all’utente di screen reader cosa è appena successo. Il risultato è un utente che sente un solo annuncio del titolo della pagina offline (se è fortunato) e che altrimenti sperimenta una perdita totale di contesto.

La soluzione è trattare la transizione offline come un cambio di stato, annunciarla attraverso una regione aria-live polite, ripristinare il focus su un landmark noto nella pagina offline, e presentare un controllo «Riprova» come un vero <button> anziché il link «Ricarica» che la maggior parte dei boilerplate per service worker spedisce. Lo stesso vale per il percorso di ripristino del foreground-sync: quando la connettività viene ripristinata e il service worker svuota la coda, anche questo è un cambio di stato di cui l’utente delle tecnologie assistive deve essere informato.

La questione «conviene distribuire una PWA o un’app nativa» ha ora una dimensione di accessibilità oltre che una di completezza funzionale. Di seguito, viene confrontata la stessa ipotetica app di lettura notizie distribuita in quattro modi — come PWA su Android, come PWA su iOS 16.4+, come app iOS nativa e come app Android nativa — sulle cinque superfici che un utente di screen reader tocca per prime.

Distribuire l’affordance di installazione come un vero <button> con un nome accessibile. Collegare una live region polite all’esito di userChoice. Compilare name, short_name, description, lang e dir nel manifest, e distribuire icone maskable per Android. Se si adotta window_controls_overlay, rendere e etichettare la propria barra del titolo; se si adotta file_handlers o share_target, trattare il lancio risultante come un cambio di stato e annunciarlo all’ingresso.

Ripristinare il focus su un landmark etichettato ogni volta che l’utente di screen reader attraversa il confine — primo lancio, ritorno dal task switcher, transizione offline, lancio da share target, riconnessione. Trattare ogni attraversamento come un evento discreto che deve all’utente un annuncio percepibile e un ancoraggio di focus noto. Niente di tutto ciò è difficile; quasi nulla viene distribuito in modo coerente.

Una PWA nel 2026 può essere quasi indistinguibile da un’app nativa per un utente di tecnologie assistive — su Android. Su iOS è più vicina di quanto fosse, ma presenta ancora un gap reale. Il gap si chiude approssimativamente a una proprietà del manifest per anno. Per i team di appalti che scelgono tra una PWA e un’app nativa, la questione dell’accessibilità non è più «una PWA può essere accessibile?» — può esserlo. La domanda è se il team che la costruisce abbia letto le undici righe del manifest sopra riportate e accettato che ciascuna fa parte del loro deliverable.