Een progressive web app bestaat tijdens uitvoering uit drie lagen bovenop een gewone website: een Web App Manifest, een service worker en een in geïnstalleerde modus werkende schil die de browser vervangen door de eigen taakwisselaar van het besturingssysteem. Elk van die drie lagen introduceert eigen toegankelijkheidsverplichtingen — en elk mislukt zijn gebruikers van hulptechnologie op een andere, afzonderlijk debuggbare manier.

In 2020 luidde het volledige debat: “WCAG is van toepassing op PWA’s” — technisch correct, operationeel nutteloos. In 2026 is het debat opgesplitst in de vier vlakken die er werkelijk toe doen: de install-prompt UX, de manifest-eigenschappen die OS-niveau-functies aansturen, de overdracht tussen de toegankelijkheidsboom van de browser en die van het besturingssysteem zodra de PWA in standalone-modus wordt gestart, en het gedrag van hulptechnologie bij de offline-terugvalmodus van de service worker. WCAG 2.2 regelt het document; de platform-integratielaag wordt bepaald door een veel lappiger geheel van W3C-concepten, leverancierspecifiek gedrag en ARIA-conventies die van het web zijn overgenomen.

De install-prompt is het meest gebruikersgerichte PWA-vlak en in 2026 nog steeds het slechtst gebouwde. Op Chromium wordt de prompt bewaakt door beforeinstallprompt, die pas afvuurt na een heuristische betrokkenheidsdrempel en die sites doorgaans koppelen aan een aangepaste knop “App installeren”. Juist bij die aangepaste knop gaat het mis met toegankelijkheid: bij ruwweg één op drie Lighthouse-scorende PWA’s verschijnt het installatie-element als een <div> of een gestylde <span> zonder role, zonder toegankelijke naam en zonder toetsenbordhandler — onzichtbaar voor een schermlezer, niet bereikbaar via Tab, en niet te onderscheiden van decoratief chrome.

De oplossing is onopvallend en verplicht: render het installatie-element als een echte <button>, stel een toegankelijke naam in die het werkwoord bevat (“Disability World op dit apparaat installeren”), maak dezelfde knop beschikbaar voor alle invoermodaliteiten, en kondig succes of mislukking aan via een live-regio nadat de gebruiker het bevestigingsscherm van het OS heeft gesloten. Hetzelfde geldt voor de staten na het verwerpen van related-applications en beforeinstallprompt — beide moeten een statuswijziging opleveren die door hulptechnologie waarneembaar is.

Het Web App Manifest groeide stilletjes tussen 2022 en 2026, en veel van de nieuwere eigenschappen hebben directe gevolgen voor toegankelijkheid. De matrix hieronder brengt de elf manifest-eigenschappen in kaart die een wisselwerking hebben met hulptechnologie en toont wat elke browser er vandaag daadwerkelijk mee doet — in Chrome op Android, Safari op iOS, Edge op Windows en Firefox op desktop. Eigenschappen als file_handlers, share_target en window_controls_overlay bestonden in 2021 nauwelijks; in 2026 bepalen ze of de PWA verschijnt in het deelmenu van het OS, bestanden opent vanuit de bestandsbeheerder van het systeem en een eigen titelbalk toont — elk vlak dat de schermlezer-gebruiker moet kunnen waarnemen en bedienen.

Het moeilijkst te debuggen probleem bij PWA-toegankelijkheid in 2026 is wat er gebeurt wanneer de gebruiker de naad passeert tussen de chrome van de PWA in standalone-modus en het besturingssysteem zelf. Op Android leest TalkBack de manifest-name wanneer de gebruiker het startscherm-icoon focust, en schakelt daarna over naar de in-app-toegankelijkheidsboom zodra de PWA wordt gestart; op iOS 16.4+ doet VoiceOver hetzelfde voor een geïnstalleerde PWA, maar met één belangrijk voorbehoud — het eerste focusbare element na het starten wordt aangekondigd zonder de appniveaucontext die een native iOS-app via zijn UIWindow-titel zou bieden.

De PWA-auteur heeft één middel om dit gat te overbruggen: focus bij koude start een kop of hoofdlandmark dat de appnaam bevat in zijn toegankelijk label, en stel de <title> van het document in op een tekenreeks die de taakwisselaar van het OS leest wanneer de gebruiker tussen apps schakelt. Zonder dit verliest de schermlezer-gebruiker de contextuele aanwijzing dat er van applicatie is gewisseld — een fout van het type “waar ben ik” die bij native apps niet bestaat.

Wanneer de service worker een offline-terugvalpagina serveert, doen zich twee hulptechnologie-specifieke storingen voor: de focus die binnen de nu verwijderde pagina zat, valt stil weg naar de document-body, en de offline-pagina zelf gebruikt zelden een live-regio om de schermlezer-gebruiker te vertellen wat er zojuist is gebeurd. Het resultaat is een gebruiker die één aankondiging van de titel van de offline-pagina hoort (als hij geluk heeft) en verder een volledig contextverlies ervaart.

De oplossing is de offline-overgang als een statuswijziging te behandelen, deze aan te kondigen via een beleefde aria-live-regio, de focus te herstellen naar een bekend landmark op de offline-pagina, en een “Opnieuw proberen”-bediening als echte knop aan te bieden in plaats van de “Herladen”-link die de meeste service-worker-boilerplates meesturen. Hetzelfde geldt voor het herstelpad na achtergrond-synchronisatie: wanneer de verbinding terugkeert en de service worker de wachtrij leegmaakt, is dat eveneens een statuswijziging waarvan de hulptechnologie-gebruiker op de hoogte moet worden gesteld.

De vraag “moeten we een PWA of een native app uitleveren?” heeft nu naast een functionaliteitsdimensie ook een toegankelijkheidsdimensie. Hieronder vergelijken we dezelfde hypothetische nieuwslezer-app op vier manieren — als PWA op Android, als PWA op iOS 16.4+, als native iOS-app en als native Android-app — op de vijf vlakken die een schermlezer-gebruiker als eerste aanraakt.

Lever het installatie-element als een echte <button> met een toegankelijke naam. Koppel een beleefde live-regio aan de uitkomst van userChoice. Vul name, short_name, description, lang en dir in het manifest in, en lever maskeerbare iconen voor Android. Als gekozen wordt voor window_controls_overlay, render en label dan een eigen titelbalk; als gekozen wordt voor file_handlers of share_target, behandel de daaruit voortvloeiende start als een statuswijziging en kondigt deze aan bij binnenkomst.

Herstel de focus naar een gelabeld landmark elke keer dat de schermlezer-gebruiker de naad passeert — eerste start, terugkeer via de taakwisselaar, offline-overgang, start via share-target, herstel van verbinding. Behandel elke overgang als een afzonderlijk evenement dat de gebruiker een waarneembare aankondiging en een bekend focusanker verschuldigd is. Niets hiervan is ingewikkeld; bijna niets ervan wordt consequent geleverd.

Een PWA in 2026 kan voor een hulptechnologie-gebruiker vrijwel niet te onderscheiden zijn van een native app — op Android. Op iOS is het dichter dan voorheen, maar er bestaat nog een reëel gat. Dat gat sluit zich met ongeveer één manifest-eigenschap per jaar. Voor aanbestedingsteams die kiezen tussen een PWA en een native app is de toegankelijkheidsvraag niet langer “kan een PWA toegankelijk zijn?” — dat kan. De vraag is of het team dat hem bouwt, de elf manifest-rijen hierboven heeft gelezen en heeft geaccepteerd dat elk ervan deel uitmaakt van het te leveren werk.