Una aplicación web progresiva es, en tiempo de ejecución, tres elementos superpuestos sobre un sitio web normal: un Web App Manifest, un service worker y un modo instalado que sustituye el marco del navegador por la propia entrada del gestor de tareas del sistema operativo. Cada una de las tres capas introduce sus propias obligaciones de accesibilidad — y cada una falla a sus usuarios de tecnología de apoyo de una manera diferente y depurable de forma independiente.

En 2020, todo el debate se reducía a «WCAG se aplica a las PWA», lo cual era técnicamente correcto y operativamente inútil. En 2026, el debate se divide en las cuatro superficies que realmente importan: la UX del aviso de instalación, las propiedades del manifiesto que impulsan las funcionalidades a nivel de sistema operativo, la transición entre el árbol de accesibilidad del navegador y el del sistema operativo una vez que la PWA se lanza en modo independiente, y el comportamiento de la tecnología de apoyo en la página de respaldo sin conexión del service worker. WCAG 2.2 rige el documento; la capa de integración con la plataforma está regulada por una combinación mucho más fragmentada de borradores del W3C, comportamiento específico de cada proveedor y convenciones ARIA heredadas de la web.

El aviso de instalación es la superficie de la PWA más visible para el usuario y, en 2026, sigue siendo la peor diseñada. En Chromium, el aviso está condicionado por beforeinstallprompt, que solo se activa tras un umbral heurístico de interacción y que los sitios habitualmente conectan a un botón personalizado de «Instalar aplicación». Ese botón personalizado es donde la accesibilidad falla: aproximadamente uno de cada tres sitios PWA que puntúan en Lighthouse muestra el elemento de instalación como un <div> o un <span> con estilo pero sin role, sin nombre accesible y sin controlador de teclado — invisible para un lector de pantalla, inaccesible mediante Tab e indistinguible del cromo decorativo.

La solución no es glamurosa pero es obligatoria: renderice el elemento de instalación como un <button> real, establezca un nombre accesible que incluya el verbo («Instalar Disability World en este dispositivo»), exponga el mismo botón a todas las modalidades de entrada y anuncie el éxito o el fracaso mediante una región en vivo después de que el usuario descarte la hoja de confirmación del sistema operativo. Lo mismo se aplica a los estados de related-applications y de beforeinstallprompt descartado — ambos deben producir un cambio de estado perceptible por la tecnología de apoyo.

El Web App Manifest creció de forma silenciosa entre 2022 y 2026, y muchas de sus propiedades más recientes tienen consecuencias directas de accesibilidad. La tabla a continuación asocia las once propiedades del manifiesto que interactúan con la tecnología de apoyo con lo que cada navegador hace realmente con ellas hoy — en Chrome para Android, Safari para iOS, Edge para Windows y Firefox para escritorio. Propiedades como file_handlers, share_target y window_controls_overlay no existían de forma significativa en 2021; en 2026 determinan si la PWA aparece en la hoja de compartir del sistema operativo, abre archivos desde el gestor de archivos del sistema y renderiza su propia barra de título — todo lo cual el usuario de lector de pantalla debe poder percibir y operar.

El problema de depuración más difícil en la accesibilidad de las PWA, en 2026, es lo que ocurre cuando el usuario cruza la costura entre el cromo de la PWA en modo independiente y el propio sistema operativo. En Android, TalkBack lee el name del manifiesto cuando el usuario focaliza el icono de la pantalla de inicio, y a continuación pasa a leer el árbol de accesibilidad dentro de la aplicación una vez que se lanza la PWA; en iOS 16.4+, VoiceOver hace lo mismo para una PWA instalada pero con un matiz importante — el primer elemento con foco tras el lanzamiento se anuncia sin el contexto a nivel de aplicación que una aplicación nativa de iOS ofrecería a través del título de su UIWindow.

El autor de la PWA dispone de una herramienta para salvar esta brecha: en el lanzamiento en frío, se debe llevar el foco a un encabezado o landmark de región principal que incluya el nombre de la aplicación en su etiqueta accesible, y establecer el <title> del documento en una cadena que el gestor de tareas del SO leerá cuando el usuario cambie entre aplicaciones. Sin esto, el usuario del lector de pantalla pierde la señal contextual de que ha cambiado de aplicación — un fallo del tipo «dónde estoy» que no existe en las aplicaciones nativas.

Cuando el service worker sirve una página de respaldo sin conexión, aparecen dos modos de fallo específicos de la tecnología de apoyo: el foco que estaba dentro de la página ahora descargada se pierde silenciosamente en el cuerpo del documento, y la propia página sin conexión raramente emplea una región en vivo para informar al usuario del lector de pantalla de lo que acaba de ocurrir. El resultado es un usuario que escucha un único anuncio del título de la página sin conexión (si tiene suerte) y que por lo demás experimenta una pérdida total de contexto.

La solución es tratar la transición sin conexión como un cambio de estado, anunciarlo mediante una región aria-live cortés, restaurar el foco en un landmark conocido de la página sin conexión y ofrecer un control «Reintentar» como un <button> real en lugar del enlace «Recargar» que la mayoría de las plantillas de service worker incluyen. Lo mismo se aplica a la vía de recuperación de sincronización en primer plano: cuando se restablece la conectividad y el service worker vacía la cola, ese también es un cambio de estado del que se debe informar al usuario de tecnología de apoyo.

La pregunta «¿debemos distribuir una PWA o una aplicación nativa?» tiene ahora una dimensión de accesibilidad además de una de completitud de funcionalidades. A continuación comparamos la misma hipotética aplicación de lectura de noticias entregada de cuatro formas — como PWA en Android, como PWA en iOS 16.4+, como aplicación nativa de iOS y como aplicación nativa de Android — en las cinco superficies que un usuario de lector de pantalla toca en primer lugar.

Distribuya el elemento de instalación como un <button> real con un nombre accesible. Conecte una región en vivo cortés al resultado de userChoice. Complete name, short_name, description, lang y dir en el manifiesto, y distribuya iconos con máscara para Android. Si adopta window_controls_overlay, renderice y etiquete su propia barra de título; si adopta file_handlers o share_target, trate el lanzamiento resultante como un cambio de estado y anúncielo al entrar.

Restaure el foco en un landmark etiquetado cada vez que el usuario de lector de pantalla cruce la costura — primer lanzamiento, retorno desde el gestor de aplicaciones, transición sin conexión, lanzamiento por share_target, reconexión. Trate cada cruce como un evento discreto que debe al usuario un anuncio perceptible y un anclaje de foco conocido. Nada de esto es difícil; casi nada de esto se distribuye de forma coherente.

Una PWA en 2026 puede ser casi indistinguible de una aplicación nativa para un usuario de tecnología de apoyo — en Android. En iOS está más cerca que antes, y sigue existiendo una brecha real. La brecha se está cerrando aproximadamente a razón de una propiedad del manifiesto por año. Para los equipos de contratación que eligen entre una PWA y una aplicación nativa, la pregunta de accesibilidad ya no es «¿puede una PWA ser accesible?» — puede serlo. La pregunta es si el equipo que la desarrolla ha leído las once filas del manifiesto anteriores y ha aceptado que cada una forma parte de su entregable.