Прогресивното уеб приложение по време на изпълнение е три неща, наслоени върху нормален уебсайт: уеб манифест на приложението (Web App Manifest), service worker и интерфейс в инсталиран режим, който заменя рамката на браузъра със собствения елемент за превключване на задачи на операционната система. Всеки от трите слоя въвежда свои собствени задължения за достъпност — и всеки се проваля пред потребителите си на помощни технологии по различен, отделно отстраним начин.

През 2020 г. целият разговор се сви до „WCAG се прилага за PWA“, което беше технически вярно и оперативно безполезно. През 2026 г. разговорът е разделен на четирите повърхности, които наистина имат значение: UX на подканата за инсталиране, свойствата на манифеста, които управляват средствата на ниво операционна система, предаването между дървото за достъпност на браузъра и дървото за достъпност на операционната система, след като PWA се стартира в самостоятелен режим (standalone), и поведението на помощните технологии при офлайн резервната страница на service worker. WCAG 2.2 управлява документа; слоят за интеграция с платформата се управлява от много по-разпокъсана смес от чернови на W3C, специфично за доставчика поведение и ARIA конвенции, наследени от уеб.

Подканата за инсталиране е най-обърнатата към потребителя повърхност на PWA и през 2026 г. все още е най-зле проектираната. В Chromium подканата е заключена зад beforeinstallprompt, който се задейства само след евристичен праг на ангажираност и който сайтовете обикновено свързват с персонализиран бутон „Инсталиране на приложението“. Този персонализиран бутон е там, където достъпността се обърква: приблизително едно от три PWA с Lighthouse оценка изобразява средството за инсталиране като <div> или стилизиран <span> без роля, без достъпно име и без обработчик на клавиатура — невидим за екранен четец, недостижим с Tab и неразличим от декоративния интерфейс.

Поправката е непривлекателна и задължителна: изобразете средството за инсталиране като реален <button>, задайте достъпно име, което включва глагола („Инсталиране на Disability World на това устройство“), изложете същия бутон на всички модалности на въвеждане и обявявайте успех или неуспех чрез жива област (live region), след като потребителят отхвърли потвърждаващия лист на ниво операционна система. Същото важи за състоянията на свързаните приложения (related-applications) и за отхвърления beforeinstallprompt — и двете трябва да предизвикат промяна на статуса, доловима от помощната технология.

Уеб манифестът на приложението нарасна тихо между 2022 и 2026 г. и много от по-новите му свойства носят преки последици за достъпността. Матрицата по-долу съпоставя единадесетте свойства на манифеста, които взаимодействат с помощната технология, с това какво всеки браузър реално прави с тях днес — в Chrome на Android, Safari на iOS, Edge на Windows и Firefox на десктоп. Свойства като file_handlers, share_target и window_controls_overlay не съществуваха в каквато и да е значима форма през 2021 г.; през 2026 г. те определят дали PWA се появява в листа за споделяне на операционната система, отваря файлове от системния файлов мениджър и изобразява собствена заглавна лента — всичко това, което потребителят на екранен четец трябва да може да долови и да управлява.

Единственият най-труден проблем за отстраняване на грешки в достъпността на PWA през 2026 г. е какво се случва, когато потребителят пресече шева между интерфейса на PWA в самостоятелен режим и самата операционна система. На Android TalkBack чете name от манифеста, когато потребителят фокусира иконата на началния екран, след което преминава към четене на дървото за достъпност в приложението, щом PWA се стартира; на iOS 16.4+ VoiceOver прави същото за инсталирано PWA, но с една важна особеност — първият фокусируем елемент след стартиране се обявява без контекста на ниво приложение, който нативно iOS приложение би предоставило чрез заглавието на своя UIWindow.

Авторът на PWA има един инструмент, за да преодолее тази пролука: при студено стартиране фокусирайте заглавие или ориентир на главната област (main region), което включва името на приложението в достъпния си етикет, и задайте <title> на документа на низ, който елементът за превключване на задачи на ОС ще прочете, когато потребителят прелиства между приложенията. Без това потребителят на екранен четец губи контекстуалния сигнал, че е сменил приложението — провал от типа „къде се намирам“, който не съществува за нативни приложения.

Когато service worker сервира офлайн резервна страница, се появяват два специфични за помощните технологии режима на отказ: фокусът, който беше вътре в сега заредената наново страница, мълчаливо пада върху тялото на документа, а самата офлайн страница рядко използва жива област, за да каже на потребителя на екранен четец какво току-що се случи. Резултатът е потребител, който чува едно обявяване на заглавието на офлайн страницата (ако има късмет) и иначе изпитва пълна загуба на контекст.

Поправката е офлайн преходът да се третира като промяна на състоянието, да се обяви чрез учтива aria-live област, фокусът да се възстанови до познат ориентир на офлайн страницата и контрол „Опитайте отново“ да се изведе като реален бутон, а не като връзката „Презареждане“, която повечето шаблони за service worker предлагат. Същото важи за пътя за възстановяване чрез синхронизация на преден план: когато свързаността се възстанови и service worker изпразни опашката, това също е промяна на състоянието, за която потребителят на помощна технология трябва да бъде уведомен.

Въпросът „да внедрим ли PWA или нативно приложение“ сега има измерение на достъпността, освен измерение на пълнотата на функционалностите. По-долу сравняваме едно и също хипотетично приложение за четене на новини, доставено по четири начина — като PWA на Android, като PWA на iOS 16.4+, като нативно iOS приложение и като нативно Android приложение — през петте повърхности, които потребителят на екранен четец докосва пръв.

Внедрете средството за инсталиране като реален <button> с достъпно име. Свържете учтива жива област с изхода на userChoice. Попълнете name, short_name, description, lang и dir в манифеста и внедрете маскируеми икони за Android. Ако включите window_controls_overlay, изобразете и етикетирайте своя собствена заглавна лента; ако включите file_handlers или share_target, третирайте полученото стартиране като промяна на състоянието и го обявявайте при влизане.

Възстановявайте фокуса до етикетиран ориентир всеки път, когато потребителят на екранен четец пресече шева — първо стартиране, връщане от превключвателя на приложения, офлайн преход, стартиране от споделяне (share-target), повторно свързване. Третирайте всяко пресичане като отделно събитие, което дължи на потребителя доловимо обявяване и позната котва на фокуса. Нищо от това не е трудно; почти нищо от него не се внедрява последователно.

PWA през 2026 г. може да бъде почти неразличимо от нативно приложение за потребител на помощна технология — на Android. На iOS то е по-близо, отколкото беше, и все още има реална пролука. Пролуката се затваря с приблизително едно свойство на манифеста на година. За екипите по обществени поръчки, които избират между PWA и нативно приложение, въпросът за достъпността вече не е „може ли PWA да бъде достъпно?“ — може. Въпросът е дали екипът, който го изгражда, е прочел единадесетте реда на манифеста по-горе и е приел, че всеки от тях е част от тяхната доставка.