Une application web progressive est, à l’exécution, trois éléments superposés sur un site web normal : un Web App Manifest, un service worker, et un chrome en mode installé qui remplace le cadre du navigateur par l’entrée propre au gestionnaire de tâches du système d’exploitation. Chacune de ces trois couches introduit ses propres obligations en matière d’accessibilité — et chacune échoue ses utilisateurs de technologies d’assistance d’une manière différente et séparément déboguable.

En 2020, toute la conversation se résumait à « WCAG s’applique aux PWA », ce qui était techniquement correct et opérationnellement inutile. En 2026, la conversation est divisée en quatre surfaces qui comptent réellement : l’UX de la demande d’installation, les propriétés du manifeste qui pilotent les affordances au niveau du système d’exploitation, le transfert entre l’arbre d’accessibilité du navigateur et l’arbre d’accessibilité du système d’exploitation une fois la PWA lancée en mode autonome, et le comportement des technologies d’assistance lors du basculement hors ligne du service worker. WCAG 2.2 régit le document ; la couche d’intégration à la plateforme est régie par un mélange bien plus hétérogène de brouillons W3C, de comportements spécifiques aux fournisseurs et de conventions ARIA héritées du web.

La demande d’installation est la surface PWA la plus visible par les utilisateurs et, en 2026, encore la plus mal conçue. Sur Chromium, la demande est conditionnée par beforeinstallprompt, qui ne se déclenche qu’après un seuil d’engagement heuristique et que les sites câblent généralement sur un bouton personnalisé « Installer l’appli ». C’est ce bouton personnalisé qui pose problème en matière d’accessibilité : environ un tiers des PWA scorées par Lighthouse affiche l’affordance d’installation sous forme de <div> ou de <span> stylisé sans rôle, sans nom accessible et sans gestionnaire clavier — invisible pour un lecteur d’écran, inatteignable par Tab, et indiscernable du chrome décoratif.

La correction est ingrate et obligatoire : afficher l’affordance d’installation sous forme de vrai <button>, définir un nom accessible incluant le verbe (« Installer Disability World sur cet appareil »), exposer le même bouton à toutes les modalités d’entrée, et annoncer le succès ou l’échec via une région live après que l’utilisateur a rejeté la feuille de confirmation au niveau du système d’exploitation. La même règle s’applique aux états related-applications et beforeinstallprompt ignoré — les deux doivent produire un changement d’état perceptible par les technologies d’assistance.

Le Web App Manifest a évolué discrètement entre 2022 et 2026, et bon nombre de ses nouvelles propriétés ont des conséquences directes en matière d’accessibilité. La matrice ci-dessous met en correspondance les onze propriétés du manifeste qui interagissent avec les technologies d’assistance et ce que chaque navigateur en fait réellement aujourd’hui — sur Chrome sur Android, Safari sur iOS, Edge sur Windows et Firefox sur bureau. Des propriétés comme file_handlers, share_target et window_controls_overlay n’existaient sous aucune forme significative en 2021 ; en 2026, elles déterminent si la PWA apparaît dans la feuille de partage du système d’exploitation, ouvre des fichiers depuis le gestionnaire de fichiers système et affiche sa propre barre de titre — autant d’éléments que l’utilisateur de lecteur d’écran doit pouvoir percevoir et activer.

Le problème de débogage le plus difficile en matière d’accessibilité PWA, en 2026, est ce qui se passe quand l’utilisateur franchit la couture entre le chrome de la PWA en mode autonome et le système d’exploitation lui-même. Sur Android, TalkBack lit le name du manifeste quand l’utilisateur fait la mise au point sur l’icône d’écran d’accueil, puis bascule vers la lecture de l’arbre d’accessibilité interne à l’appli une fois la PWA lancée ; sur iOS 16.4+, VoiceOver fait de même pour une PWA installée, mais avec une particularité importante — le premier élément focusable après le lancement est annoncé sans le contexte au niveau de l’appli qu’une application iOS native fournirait via le titre de son UIWindow.

L’auteur de PWA dispose d’un seul outil pour combler cet écart : au lancement à froid, faire la mise au point sur un titre ou un repère de région principale incluant le nom de l’appli dans son étiquette accessible, et définir le <title> du document comme une chaîne que le sélecteur de tâches du système d’exploitation lira quand l’utilisateur fait défiler les applis. Sans cela, l’utilisateur de lecteur d’écran perd le repère contextuel indiquant qu’il a changé d’application — un échec de type « où suis-je » qui n’existe pas pour les applis natives.

Lorsque le service worker sert une page de secours hors ligne, deux modes d’échec spécifiques aux technologies d’assistance apparaissent : le focus qui se trouvait dans la page désormais déchargée est silencieusement déplacé vers le corps du document, et la page hors ligne elle-même utilise rarement une région live pour informer l’utilisateur de lecteur d’écran de ce qui vient de se passer. Le résultat est un utilisateur qui entend une annonce du titre de la page hors ligne (s’il a de la chance) et subit autrement une perte totale de contexte.

La correction consiste à traiter la transition hors ligne comme un changement d’état, à l’annoncer via une région aria-live polie, à restaurer le focus sur un repère connu de la page hors ligne, et à présenter un contrôle « Réessayer » sous forme de vrai bouton plutôt que le lien « Recharger » que la plupart des modèles de service worker livrent. La même règle s’applique au chemin de récupération par synchronisation au premier plan : quand la connectivité revient et que le service worker vide la file d’attente, c’est aussi un changement d’état dont l’utilisateur de technologies d’assistance doit être informé.

La question « faut-il livrer une PWA ou une appli native » comporte désormais une dimension accessibilité en plus de la complétude des fonctionnalités. Ci-dessous, nous comparons la même hypothétique application de lecture de news livrée de quatre façons — en tant que PWA sur Android, en tant que PWA sur iOS 16.4+, en tant qu’appli iOS native, et en tant qu’appli Android native — sur les cinq surfaces qu’un utilisateur de lecteur d’écran touche en premier.

Livrez l’affordance d’installation sous forme de vrai <button> avec un nom accessible. Câblez une région live polie sur le résultat de userChoice. Renseignez name, short_name, description, lang et dir dans le manifeste, et livrez des icônes maskable pour Android. Si vous optez pour window_controls_overlay, affichez et étiquetez votre propre barre de titre ; si vous optez pour file_handlers ou share_target, traitez le lancement résultant comme un changement d’état et annoncez-le à l’entrée.

Restaurez le focus sur un repère étiqueté chaque fois que l’utilisateur de lecteur d’écran franchit la couture — premier lancement, retour depuis le sélecteur d’applis, transition hors ligne, lancement via share-target, reconnexion. Traitez chaque franchissement comme un événement discret qui doit à l’utilisateur une annonce perceptible et un ancre de focus connue. Rien de cela n’est difficile ; presque rien de cela n’est livré de manière cohérente.

Une PWA en 2026 peut être presque indiscernable d’une appli native pour un utilisateur de technologies d’assistance — sur Android. Sur iOS, elle est plus proche qu’avant, et présente encore un écart réel. L’écart se comble à raison d’environ une propriété de manifeste par an. Pour les équipes d’achats qui choisissent entre une PWA et une appli native, la question d’accessibilité n’est plus « une PWA peut-elle être accessible ? » — elle peut. La question est de savoir si l’équipe qui la construit a lu les onze lignes de manifeste ci-dessus et accepté que chacune fasse partie de ses livrables.