En progressiv webbapp är vid körtid tre saker lagrade ovanpå en normal webbplats: ett Web App Manifest, en service worker och ett installerat läge som ersätter webbläsarens ram med operativsystemets egna aktivitetsväxlarpost. Vart och ett av de tre lagren inför sina egna tillgänglighetsskyldigheter — och vart och ett misslyckas med sina hjälpmedelsanvändare på ett separat, felsökningsbart sätt.

År 2020 kollapsade hela diskussionen till “WCAG gäller för PWA:er”, vilket var tekniskt korrekt och operativt meningslöst. I 2026 är diskussionen uppdelad i de fyra ytor som faktiskt spelar roll: installationsuppmanans UX, manifestegenskaperna som driver OS-nivåns funktioner, överlämningen mellan webbläsarens tillgänglighetsträd och operativsystemets tillgänglighetsträd när PWA:en startas i fristående läge, och hjälpmedelsteknikens beteende vid service workers offlinefallback. WCAG 2.2 reglerar dokumentet; plattformsintegrationslagret regleras av en mycket mer lapptäckesartad blandning av W3C-utkast, leverantörsspecifikt beteende och ARIA-konventioner ärvda från webben.

Installationsuppmaningen är den mest användarorienterade PWA-ytan och, 2026, fortfarande den sämst ingenjörsmässigt hanterade. I Chromium är uppmaningen gated av beforeinstallprompt, som utlöses först efter ett heuristiskt engagemangströskel och som webbplatser vanligen kopplar till en anpassad “Installera app”-knapp. Det är den anpassade knappen där tillgängligheten brister: ungefär var tredje Lighthouse-rankad PWA renderar installationsalternativet som ett <div> eller ett stilsatt <span> utan roll, utan tillgängligt namn och utan tangentbordshanterare — osynligt för en skärmläsare, onåbart via Tab och omöjligt att skilja från dekorativt chrome.

Lösningen är oansenlig och obligatorisk: rendera installationsalternativet som en riktig <button>, sätt ett tillgängligt namn som inkluderar verbet (“Installera Disability World på den här enheten”), exponera samma knapp för alla inmatningsmodaliteter och meddela framgång eller misslyckande via ett live-område efter att användaren avfärdat OS-nivåns bekräftelsedialog. Detsamma gäller för related-applications och beforeinstallprompt dismissed-tillstånden — båda måste ge en AT-märkbar statusförändring.

Web App Manifest växte tyst mellan 2022 och 2026, och många av dess nyare egenskaper har direkta tillgänglighetskonsekvenser. Matrisen nedan kartlägger de elva manifestegenskaper som interagerar med hjälpmedelsteknik mot vad varje webbläsare faktiskt gör med dem idag — för Chrome på Android, Safari på iOS, Edge på Windows och Firefox på skrivbordet. Egenskaper som file_handlers, share_target och window_controls_overlay existerade inte i någon meningsfull form 2021; i 2026 avgör de om PWA:en visas i OS:ets delningspanel, öppnar filer från systemets filhanterare och renderar sitt eget namnlist — allt som skärmläsaranvändaren måste kunna uppfatta och använda.

Det enskilt svåraste felsökningsproblemet inom PWA-tillgänglighet, i 2026, är vad som händer när användaren korsar sömsnittet mellan fristående lägets PWA-chrome och operativsystemet självt. På Android läser TalkBack manifestets name när användaren fokuserar hemskärmsikonen och övergår sedan till att läsa appens interna tillgänglighetsträd när PWA:en startas; på iOS 16.4+ gör VoiceOver detsamma för en installerad PWA men med en viktig egenhet — det första fokuserbara elementet efter start annonseras utan det appnivåkontext som en native iOS-app skulle leverera via sitt UIWindow-title.

PWA-utvecklaren har ett verktyg för att överbrygga detta gap: vid kallstart, fokusera en rubrik eller ett main-regions-landmärke som inkluderar appnamnet i sin tillgängliga etikett, och sätt dokumentets <title> till en sträng som OS:ets aktivitetsväxlare läser när användaren växlar mellan appar. Utan detta förlorar skärmläsaranvändaren den kontextuella ledtråden om att de har bytt applikation — ett “var befinner jag mig”-misslyckande som inte existerar för native-appar.

När service workern levererar en offlinefallbacksida uppstår två AT-specifika fellägen: fokuset som var inne på den nu inaktiverade sidan tappas tyst bort till dokumentkroppen, och offlineside-sidan själv använder sällan ett live-område för att tala om för skärmläsaranvändaren vad som just hänt. Resultatet är en användare som hör ett meddelande om offlinesidetiteln (om de har tur) och i övrigt upplever ett totalt kontextbortfall.

Lösningen är att behandla offlineövergången som en tillståndsförändring, meddela den via ett artigt aria-live-område, återställa fokus till ett känt landmärke på offlineside-sidan och presentera en “Försök igen”-kontroll som en riktig knapp snarare än “Ladda om”-länken som de flesta service worker-mallar levererar. Detsamma gäller för förgrundssyncåtervinningsvägen: när uppkopplingen återkommer och service workern tömmer kön är det också en tillståndsförändring som AT-användaren måste informeras om.

Frågan “ska vi lansera en PWA eller en native-app” har nu en tillgänglighetsdimension utöver en funktionsfullständighetsdimension. Nedan jämför vi samma hypotetiska nyhetsläsarapp levererad på fyra sätt — som PWA på Android, som PWA på iOS 16.4+, som native iOS-app och som native Android-app — över de fem ytor en skärmläsaranvändare möter först.

Leverera installationsalternativet som en riktig <button> med ett tillgängligt namn. Koppla ett artigt live-område till userChoice-utfallet. Fyll i name, short_name, description, lang och dir i manifestet, och leverera maskabara ikoner för Android. Om du väljer window_controls_overlay, rendera och märk din egen namnlist; om du väljer file_handlers eller share_target, behandla den resulterande starten som en tillståndsförändring och meddela den vid inträde.

Återställ fokus till ett märkt landmärke varje gång skärmläsaranvändaren korsar sömsnittet — kallstart, aktivitetsväxlaråterkomst, offlineövergång, share-target-start, återanslutning. Behandla varje korsning som en diskret händelse som är skyldig användaren ett märkbart meddelande och ett känt fokusankar. Inget av detta är svårt; nästan inget av det levereras konsekvent.

En PWA i 2026 kan vara nästan omöjlig att skilja från en native-app för en hjälpmedelsanvändare — på Android. På iOS är det närmare än det var, och det finns fortfarande ett reellt gap. Gapet krymper med ungefär en manifestegenskap per år. För upphandlingsteam som väljer mellan en PWA och en native-app är tillgänglighetsfrågan inte längre “kan en PWA vara tillgänglig?” — det kan den. Frågan är om teamet som bygger den har läst de elva manifestraderna ovan och accepterat att var och en av dem ingår i deras leverans.