En progressive web app er ved kørsel tre ting oven på et normalt website: et Web App Manifest, en service worker og en installeret tilstand, der erstatter browser-rammen med operativsystemets eget opgaveskifterindslag. Hvert af de tre lag introducerer sine egne tilgængelighedsforpligtelser — og hvert lag svigter sine brugere af hjælpeteknologi på en anderledes, separat fejlsøgbar måde.

I 2020 kollapsede hele samtalen til »WCAG gælder for PWA’er«, hvilket var teknisk korrekt og operationelt ubrugeligt. I 2026 er samtalen opdelt i de fire overflader, der faktisk betyder noget: install-prompt-UX, de manifest-egenskaber der driver affordances på OS-niveau, overdragelsen mellem browserens tilgængelighedstræ og operativsystemets tilgængelighedstræ når PWA’en startes i standalone-tilstand, og hjælpeteknologiadfærden for service-workerens offline-fallback. WCAG 2.2 styrer dokumentet; platform-integrationslaget er styret af en langt mere plettet blanding af W3C-udkast, leverandørspecifik adfærd og ARIA-konventioner arvet fra webbet.

Install-prompten er den mest brugervendte PWA-overflade og er i 2026 stadig den dårligst udviklede. På Chromium er prompten begrænset af beforeinstallprompt, som kun aktiveres efter en heuristisk engagementstærskel, og som websteder typisk kobler til en brugerdefineret »Installer app«-knap. Den brugerdefinerede knap er, hvor tilgængelighed går galt: omtrent én ud af tre Lighthouse-scorende PWA’er gengiver installationsaffordancen som et <div> eller et stiliseret <span> uden rolle, uden tilgængeligt navn og uden tastaturbehandler — usynlig for en skærmlæser, utilgængelig med Tab og uadskillelig fra dekorativt chrome.

Løsningen er unglamourøs og obligatorisk: gengiv installationsaffordancen som en rigtig <button>, angiv et tilgængeligt navn der inkluderer verbet (»Installer Disability World på denne enhed«), eksponer den samme knap for alle inputmodaliteter, og annoncér succes eller fejl via en live-region efter brugeren har afvist bekræftelsesarket på OS-niveau. Det samme gælder tilstandene relateret-applikationer og afvist beforeinstallprompt — begge skal producere en hjælpeteknologi-opfattelig statusændring.

Web App Manifest voksede stille og roligt mellem 2022 og 2026, og mange af dets nyere egenskaber har direkte tilgængelighedskonsekvenser. Matrixen nedenfor kortlægger de elleve manifest-egenskaber der interagerer med hjælpeteknologi til, hvad hver browser faktisk gør med dem i dag — på tværs af Chrome på Android, Safari på iOS, Edge på Windows og Firefox på desktop. Egenskaber som file_handlers, share_target og window_controls_overlay eksisterede ikke i nogen meningsfuld form i 2021; i 2026 afgør de om PWA’en vises i OS-delingspanelet, åbner filer fra systemets filhåndtering og gengiver sin egen titellinje — alt sammen noget skærmlæserbrugeren skal kunne opfatte og betjene.

Det eneste sværeste fejlsøgningsproblem i PWA-tilgængelighed i 2026 er det, der sker når brugeren krydser sømmen mellem standalone-tilstand PWA-chrome og selve operativsystemet. På Android læser TalkBack manifest-name når brugeren fokuserer hjemmeskærmsikonet og overgår derefter til at læse appens interne tilgængelighedstræ når PWA’en starter; på iOS 16.4+ gør VoiceOver det samme for en installeret PWA, men med én vigtig detalje — det første fokuserbare element efter start annonceres uden det app-niveau-kontekst, som en native iOS-app ville levere via sin UIWindow-titel.

PWA-forfatteren har ét redskab til at bygge bro over denne kløft: ved koldstart fokuseres en overskrift eller et main-region-landmark der inkluderer appnavnet i sit tilgængelige label, og dokumentets <title> sættes til en streng som OS-opgaveskifteren vil læse, når brugeren skifter mellem apps. Uden dette mister skærmlæserbrugeren det kontekstuelle signal om at de har skiftet applikation — en »hvor er jeg«-fejl der ikke eksisterer for native apps.

Når service workeren serverer en offline-fallbackside, opstår to hjælpeteknologispecifikke fejltilstande: det fokus der var inde på den nu aflæssede side tabes stille og roligt på dokumentets body, og offline-siden selv bruger sjældent en live-region til at fortælle skærmlæserbrugeren hvad der netop skete. Resultatet er en bruger der hører én annoncering af offline-sidens titel (hvis de er heldige) og ellers oplever et totalt tab af kontekst.

Løsningen er at behandle offline-overgangen som en tilstandsændring, annoncere den via en høflig aria-live-region, gendanne fokus til et kendt landmark på offline-siden og levere en »Prøv igen«-kontrol som en rigtig knap frem for det »Genindlæs«-link de fleste service-worker-boilerplates leverer. Det samme gælder foreground-sync-gendannelsesstien: når forbindelsen genoptages og service workeren tømmer køen, er det også en tilstandsændring som hjælpeteknologibrugeren skal adviseres om.

Spørgsmålet »skal vi levere en PWA eller en native app?« har nu en tilgængelighedsdimension såvel som en funktionskomplethedsaspekt. Nedenfor sammenligner vi den samme hypotetiske nyhedslæser-app leveret på fire måder — som en PWA på Android, som en PWA på iOS 16.4+, som en native iOS-app og som en native Android-app — på tværs af de fem overflader en skærmlæserbruger rammer først.

Lever installationsaffordancen som en rigtig <button> med et tilgængeligt navn. Kobl en høflig live-region til userChoice-resultatet. Udfyld name, short_name, description, lang og dir i manifestet, og lever maskbare ikoner til Android. Hvis du vælger window_controls_overlay, skal du gengive og labelle din egen titellinje; vælger du file_handlers eller share_target, skal du behandle den resulterende start som en tilstandsændring og annoncere den ved indgang.

Gendan fokus til et labellet landmark hver gang skærmlæserbrugeren krydser sømmen — første start, opgaveskifter-retur, offline-overgang, share-target-start, genopkobling. Behandl hver krydsning som en separat hændelse der skylder brugeren en opfattelig annoncering og et kendt fokusanker. Intet af dette er svært; næsten intet af det leveres konsekvent.

En PWA i 2026 kan være nærmest uadskillelig fra en native app for en hjælpeteknologibruger — på Android. På iOS er den tættere end den var og har stadig en reel kløft. Kløften lukker sig med omtrent én manifest-egenskab om året. For udbudsteams der vælger mellem en PWA og en native app er tilgængelighedsspørgsmålet ikke længere »kan en PWA være tilgængelig?« — det kan den. Spørgsmålet er, om det team der bygger den, har læst de elleve manifest-rækker ovenfor og accepteret, at hver enkelt er en del af det, de skal levere.