Progresywna aplikacja internetowa to, w czasie działania, trzy rzeczy nałożone na normalną stronę internetową: Web App Manifest, service worker i chrome trybu zainstalowanego, który zastępuje ramkę przeglądarki własnym wpisem przełącznika zadań systemu operacyjnego. Każda z tych trzech warstw wprowadza własne obowiązki dostępności — i każda zawodzi użytkowników technologii wspomagających w inny, osobno debugowalny sposób.

W 2020 roku całą rozmowę sprowadzano do stwierdzenia „WCAG obowiązuje w PWA“, co było technicznie poprawne i operacyjnie bezużyteczne. W 2026 roku rozmowa jest podzielona na cztery powierzchnie, które naprawdę mają znaczenie: UX monitu instalacji, właściwości manifestu sterujące funkcjami na poziomie systemu operacyjnego, przekazanie między drzewem dostępności przeglądarki a drzewem dostępności systemu operacyjnego po uruchomieniu PWA w trybie samodzielnym oraz zachowanie technologii wspomagającej podczas offline’owego fallbacku service workera. WCAG 2.2 reguluje dokument; warstwa integracji z platformą jest regulowana przez znacznie bardziej nierówną mieszaninę szkiców W3C, zachowań specyficznych dla dostawców i konwencji ARIA odziedziczonych z sieci.

Monit instalacji to najbardziej widoczna dla użytkownika powierzchnia PWA i, w 2026 roku, nadal najgorzej zaprojektowana. W Chromium monit jest sterowany przez beforeinstallprompt, który uruchamia się dopiero po heurystycznym progu zaangażowania i który serwisy zazwyczaj podłączają do niestandardowego przycisku „Zainstaluj aplikację“. To właśnie ten niestandardowy przycisk jest miejscem, gdzie dostępność zawodzi: mniej więcej jeden na trzy PWA oceniane przez Lighthouse renderuje funkcję instalacji jako <div> lub stylowany <span> bez roli, bez dostępnej nazwy i bez obsługi klawiatury — niewidoczny dla czytnika ekranu, nieosiągalny za pomocą Tab i nieodróżnialny od dekoracyjnego chrome’u.

Naprawa jest niepozorna i obowiązkowa: renderuj funkcję instalacji jako prawdziwy <button>, ustaw dostępną nazwę zawierającą czasownik („Zainstaluj Disability World na tym urządzeniu“), udostępnij ten sam przycisk wszystkim modalności wejściowym i ogłaszaj sukces lub niepowodzenie za pomocą regionu live po tym, jak użytkownik odrzuci systemowy arkusz potwierdzenia. To samo dotyczy stanów związanych z aplikacjami i odrzuconym beforeinstallprompt — oba muszą powodować zmianę stanu percepcji przez technologię wspomagającą.

Web App Manifest rozrastał się dyskretnie między 2022 a 2026 rokiem, a wiele jego nowszych właściwości ma bezpośrednie konsekwencje dla dostępności. Poniższa macierz mapuje jedenaście właściwości manifestu wchodzących w interakcję z technologią wspomagającą na to, co każda przeglądarka rzeczywiście z nimi robi dzisiaj — w Chrome na Androidzie, Safari na iOS, Edge na Windows i Firefox na komputerze stacjonarnym. Właściwości takie jak file_handlers, share_target i window_controls_overlay nie istniały w żadnej znaczącej formie w 2021 roku; w 2026 roku decydują o tym, czy PWA pojawia się w arkuszu udostępniania systemu operacyjnego, otwiera pliki z menedżera plików systemowych i renderuje własny pasek tytułu — a wszystko to użytkownik czytnika ekranu musi być w stanie postrzegać i obsługiwać.

Najtrudniejszym problemem debugowania w dostępności PWA w 2026 roku jest to, co dzieje się, gdy użytkownik przekracza granicę między chrome PWA w trybie samodzielnym a samym systemem operacyjnym. Na Androidzie TalkBack odczytuje name z manifestu, gdy użytkownik skupia ikonę na ekranie głównym, a następnie przechodzi do odczytu drzewa dostępności wewnątrz aplikacji po uruchomieniu PWA; na iOS 16.4+ VoiceOver robi to samo dla zainstalowanej PWA, ale z jedną istotną osobliwością — pierwszy fokusowalny element po uruchomieniu jest ogłaszany bez kontekstu na poziomie aplikacji, który natywna aplikacja iOS dostarczyłaby poprzez tytuł UIWindow.

Autor PWA ma jedno narzędzie do wypełnienia tej luki: przy zimnym uruchomieniu należy skupić nagłówek lub punkt orientacyjny głównego regionu, który zawiera nazwę aplikacji w swojej dostępnej etykiecie, i ustawić <title> dokumentu na ciąg znaków, który przełącznik zadań systemu operacyjnego odczyta, gdy użytkownik przesuwa się między aplikacjami. Bez tego użytkownik czytnika ekranu traci wskazówkę kontekstową, że przełączył aplikacje — błąd „gdzie jestem“, który nie istnieje w aplikacjach natywnych.

Gdy service worker serwuje stronę fallback offline, pojawiają się dwa tryby błędów specyficzne dla technologii wspomagającej: fokus, który był wewnątrz właśnie wyładowanej strony, jest po cichu przenoszony na treść dokumentu, a sama strona offline rzadko używa regionu live, aby powiedzieć użytkownikowi czytnika ekranu, co właśnie się stało. Rezultatem jest użytkownik, który słyszy jedno ogłoszenie tytułu strony offline (jeśli ma szczęście) i w inny sposób doświadcza całkowitej utraty kontekstu.

Naprawa polega na potraktowaniu przejścia offline jako zmiany stanu, ogłoszeniu jej przez grzecznościowy region aria-live, przeniesieniu fokusa do znane go punktu orientacyjnego na stronie offline i udostępnieniu elementu sterującego „Spróbuj ponownie“ jako prawdziwego przycisku, a nie linku „Przeładuj“, który większość standardowych szablonów service workera dostarcza. To samo dotyczy ścieżki odzyskiwania foreground-sync: gdy łączność wraca i service worker opróżnia kolejkę, to też jest zmiana stanu, o której użytkownik technologii wspomagającej musi zostać poinformowany.

Pytanie „czy wdrożyć PWA, czy aplikację natywną“ ma teraz wymiar dostępności oprócz wymiaru kompletności funkcji. Poniżej porównujemy tę samą hipotetyczną aplikację do czytania wiadomości dostarczoną na cztery sposoby — jako PWA na Androidzie, jako PWA na iOS 16.4+, jako natywną aplikację iOS i jako natywną aplikację Android — w pięciu powierzchniach, których użytkownik czytnika ekranu dotyka jako pierwszy.

Dostarczaj funkcję instalacji jako prawdziwy <button> z dostępną nazwą. Podłącz grzecznościowy region live do wyniku userChoice. Wypełnij name, short_name, description, lang i dir w manifeście i dostarcz ikony maskable dla Androida. Jeśli decydujesz się na window_controls_overlay, renderuj i oznakuj własny pasek tytułu; jeśli decydujesz się na file_handlers lub share_target, traktuj wynikowe uruchomienie jako zmianę stanu i ogłaszaj ją przy wejściu.

Przenoś fokus do oznakowanego punktu orientacyjnego za każdym razem, gdy użytkownik czytnika ekranu przekracza granicę — pierwsze uruchomienie, powrót z przełącznika aplikacji, przejście offline, uruchomienie share_target, ponowne połączenie. Traktuj każde przekroczenie jako oddzielne zdarzenie, które jest winne użytkownikowi dostrzegalne ogłoszenie i znane zakotwiczenie fokusa. Nic z tego nie jest trudne; prawie nic z tego nie jest konsekwentnie wdrażane.

PWA w 2026 roku może być prawie nieodróżnialna od natywnej aplikacji dla użytkownika technologii wspomagającej — na Androidzie. Na iOS jest bliżej niż była, a realna luka nadal istnieje. Luka zamyka się w tempie mniej więcej jednej właściwości manifestu rocznie. Dla zespołów przetargowych wybierających między PWA a aplikacją natywną pytanie dotyczące dostępności nie brzmi już „czy PWA może być dostępna?“ — może. Pytanie brzmi, czy zespół ją budujący przeczytał jedenaście wierszy manifestu powyżej i zaakceptował, że każdy z nich stanowi część ich produktu dostarczanego na każdej platformie, na którą wysyłają.