Progressiivinen verkkosovellus on ajon aikana kolme tavallisen verkkosivuston päälle kerrostettua asiaa: Web App Manifest, service worker ja asennettu tila, jossa selainkehys korvataan käyttöjärjestelmän omalla tehtävänvaihtajamerkinnällä. Jokainen kolmesta kerroksesta tuo mukanaan omat saavutettavuusvelvollisuutensa — ja jokainen epäonnistuu avustavan teknologian käyttäjiensä kanssa eri, erikseen debugattavalla tavalla.

Vuonna 2020 koko keskustelu tiivistyi muotoon “WCAG koskee PWA:ita”, mikä oli teknisesti oikein ja operatiivisesti hyödytöntä. Vuonna 2026 keskustelu jakaantuu neljään pintaan, joilla on todella merkitystä: asennuskehotteen käyttöliittymä, käyttöjärjestelmätason toimintoja ohjaavat manifest-ominaisuudet, siirtymä selaimen saavutettavuuspuun ja käyttöjärjestelmän saavutettavuuspuun välillä kun PWA käynnistyy standalone-tilassa, sekä service workerin offline-fallbackin toiminta avustavalla teknologialla. WCAG 2.2 koskee dokumenttia; alustaintegraatiokerros kuuluu paljon pirstaleisempaan yhdistelmään W3C:n luonnoksia, toimittajakohtaista käyttäytymistä ja verkosta periytyneitä ARIA-käytäntöjä.

Asennuskehotteen käyttöliittymä on PWA:n käyttäjälle näkyvin pintakerros ja vuonna 2026 edelleen huonoimmin suunniteltu. Chromiumissa kehotteen porttivartijana toimii beforeinstallprompt, joka laukeaa vasta heuristisen sitoutumiskynnyksen ylityttyä ja joka useimmiten kytketään mukautettuun “Asenna sovellus” -painikkeeseen. Juuri tämä painike on paikka, jossa saavutettavuus menee pieleen: noin joka kolmas Lighthouse-pisteytetty PWA renderöi asennustoiminnon <div>- tai tyyliteltynä <span>-elementtinä, jolla ei ole roolia, saavutettavaa nimeä eikä näppäimistökäsittelijää — näkymätön ruudunlukuohjelmalle, Tabilla tavoittamaton ja erottamaton koristekromista.

Korjaus on epäloistava mutta pakollinen: renderöi asennustoiminto oikeana <button>-elementtinä, aseta saavutettava nimi johon sisältyy verbi (“Asenna Disability World tähän laitteeseen”), näytä sama painike kaikissa syötemuodoissa ja ilmoita onnistumisesta tai epäonnistumisesta live-alueella sen jälkeen kun käyttäjä hylkää käyttöjärjestelmätason vahvistusikkunan. Sama koskee related-applications- ja beforeinstallprompt-hylätty-tiloja — molempien on tuotettava avustavalle teknologialle havaittava tilamuutos.

Web App Manifest kasvoi hiljaisesti vuosien 2022 ja 2026 välillä, ja monilla sen uudemmista ominaisuuksista on suoria saavutettavuusvaikutuksia. Alla oleva matriisi kuvaa yksitoista manifest-ominaisuutta, jotka ovat vuorovaikutuksessa avustavan teknologian kanssa, ja sen, mitä kukin selain nykyään niillä tekee — Chrome Androidilla, Safari iOS:ssä, Edge Windowsilla ja Firefox desktopilla. Ominaisuudet kuten file_handlers, share_target ja window_controls_overlay eivät olleet olemassa missään merkityksellisessä muodossa vuonna 2021; vuonna 2026 ne määräävät, näkyykö PWA käyttöjärjestelmän jakopaneelissa, avaako se tiedostoja järjestelmän tiedostohallinnasta ja renderöikö se oman otsikkopalkin — ja kaikkia näitä ruudunlukuohjelman käyttäjän on pystyttävä havaitsemaan ja käyttämään.

Vaikein yksittäinen debugausongelma PWA-saavutettavuudessa vuonna 2026 on se, mitä tapahtuu kun käyttäjä ylittää saumalinjan standalone-tilan PWA-kromin ja käyttöjärjestelmän välillä. Androidilla TalkBack lukee manifest-tiedoston name-arvon kun käyttäjä kohdistaa kotinäytön kuvakkeen, ja siirtyy sitten lukemaan sovelluksen sisäistä saavutettavuuspuuta PWA:n käynnistyessä; iOS 16.4+:ssa VoiceOver toimii samoin asennetulle PWA:lle, mutta yhdellä tärkeällä poikkeuksella — ensimmäinen kohdistettava elementti käynnistyksen jälkeen ilmoitetaan ilman sovellustasoista kontekstia, jonka natiivi iOS-sovellus toimittaisi UIWindow-otsikkonsa kautta.

PWA:n kehittäjällä on yksi keino kuroa tämä aukko: kylmäkäynnistyksen yhteydessä siirretään kohdistus otsikolle tai main-alueen maamerkille, jonka saavutettavassa nimessä on sovelluksen nimi, ja asetetaan dokumentin <title> merkkijonoksi, jonka käyttöjärjestelmän tehtävänvaihtaja lukee käyttäjän vaihtaessa sovellusten välillä. Ilman tätä ruudunlukuohjelman käyttäjä menettää kontekstuaalisen vihjeen siitä, että hän on vaihtanut sovellusta — “missä olen” -ongelma, jota natiivissa sovelluksissa ei ole.

Kun service worker tarjoaa offline-fallback-sivun, ilmenee kaksi avustavalle teknologialle ominaista virhettä: kohdistus, joka oli nyt purkautuneen sivun sisällä, pudotetaan äänettömästi dokumentin runkoon, eikä offline-sivu itsessään juuri koskaan käytä live-aluetta kertoakseen ruudunlukuohjelman käyttäjälle mitä juuri tapahtui. Tuloksena on käyttäjä, joka kuulee parhaimmillaan yhden ilmoituksen offline-sivun otsikosta ja kokee muuten täydellisen kontekstin menetyksen.

Korjaus on kohdella offline-siirtymää tilamuutoksena, ilmoittaa siitä kohteliaan aria-live-alueen kautta, palauttaa kohdistus tunnetulle maamerkille offline-sivulla ja tarjota “Yritä uudelleen” -hallinta oikeana painikkeena eikä useimpien service-worker-mallipohjien toimittamana “Lataa uudelleen” -linkkinä. Sama koskee foreground-sync-palautuspolkua: kun yhteys palautuu ja service worker tyhjentää jonon, sekin on tilamuutos, josta avustavan teknologian käyttäjälle on kerrottava.

Kysymyksellä “toimitetaanko PWA vai natiivisovellus” on nyt myös saavutettavuusnäkökulma ominaisuuksien täydellisyyden lisäksi. Alla vertaillaan samaa hypoteettista uutistenlukulaitetta neljällä tavalla — PWA:na Androidilla, PWA:na iOS 16.4+:ssa, natiivina iOS-sovelluksena ja natiivina Android-sovelluksena — viidessä pintakerroksessa, joihin ruudunlukuohjelman käyttäjä törmää ensin.

Toimita asennustoiminto oikeana <button>-elementtinä saavutettavalla nimellä. Kytke kohteliaan live-alueen userChoice-tulokseen. Täytä manifestissa name, short_name, description, lang ja dir, ja toimita maskattavia kuvakkeita Androidille. Jos otat käyttöön window_controls_overlay, renderöi ja nimeä oma otsikkopalkkisi; jos otat käyttöön file_handlers tai share_target, kohtele tuloksena syntyvää käynnistystä tilamuutoksena ja ilmoita siitä sovellukseen saavuttaessa.

Palauta kohdistus nimetylle maamerkille joka kerta kun ruudunlukuohjelman käyttäjä ylittää saumalinjan — kylmäkäynnistyksessä, tehtävänvaihtajasta palatessa, offline-siirtymässä, share-target-käynnistyksessä ja yhteyden palautuessa. Kohtele jokainen ylitys erillisenä tapahtumana, joka on velkaa käyttäjälle havaittavan ilmoituksen ja tunnetun kohdistusankkurin. Mikään tässä ei ole vaikeaa; lähes mitään ei toimiteta johdonmukaisesti.

PWA voi vuonna 2026 olla avustavan teknologian käyttäjälle hyvin lähellä natiivia sovellusta — Androidilla. iOS:llä se on lähempänä kuin ennen, mutta todellinen aukko on edelleen olemassa. Aukko sulkeutuu suunnilleen yksi manifest-ominaisuus vuodessa. Hankintatiimeille, jotka valitsevat PWA:n ja natiivisovelluksen välillä, saavutettavuuskysymys ei ole enää “voiko PWA olla saavutettava?” — se voi. Kysymys on, onko tiimi lukenut yllä olevat yksitoista manifest-riviä ja hyväksynyt, että jokainen niistä on osa toimitettavaa kokonaisuutta.