Partiellement, et la réponse honnête tient en trois temps. Elle n'est PAS certifiée RGAA ou WCAG et n'a pas été auditée par un tiers : aucune page de ce site ne vous dira le contraire. En revanche plusieurs acquis sont là par construction, parce que l'interface est écrite par un programme déterministe et non redessinée à chaque fois — focus clavier visible, mouvement réduit si votre système le demande, formulaires réels, aucune boîte de dialogue native. À chaque génération, l'arbre d'accessibilité de chaque écran est relevé et publié dans un rapport. Ce qui manque est nommé plus bas plutôt que tu. Et comme le code vous appartient, une correction d'accessibilité est un travail ordinaire, pas une demande déposée chez un éditeur.
Ce qui est acquis par construction, parce qu'un programme écrit l'interface
La différence tient à qui tient le stylo. L'interface n'est pas dessinée par un modèle à chaque génération : un constructeur déterministe l'émet à partir d'une bibliothèque de composants commune. Une garantie posée une fois vaut donc pour tous les écrans de toutes les applications, au lieu de dépendre de l'inspiration du jour. C'est la propriété la plus utile de cette architecture en matière d'accessibilité, et elle n'a rien d'un slogan : elle se vérifie écran par écran.
Concrètement : tout élément interactif prend le focus au clavier et affiche un anneau visible tiré de la charte de l'application — pas l'anneau par défaut du navigateur, qui disparaît sur un fond coloré — et ce même anneau ne s'affiche pas sur un clic de souris, là où il n'apprend rien. Un utilisateur dont le système demande de réduire les animations voit les transitions ramenées à une durée négligeable. Les boîtes de saisie sont de vrais formulaires : la touche Entrée valide, le premier champ prend le focus à l'ouverture, et le bouton principal est un bouton de soumission.
Aucune boîte de dialogue native, et pourquoi c'est une bonne nouvelle
Une application produite ici n'emploie jamais la fenêtre de confirmation native du navigateur. Supprimer une ligne se fait en deux temps, dans la page : un premier clic arme l'action, un second la confirme, et on peut renoncer entre les deux. Le même principe vaut pour désactiver un compte.
Cette décision n'a pas été prise pour l'accessibilité — elle vient d'un problème d'automatisation et d'une question de langage visuel — mais sa conséquence est réelle et vaut d'être dite. Une fenêtre native sort du document, interrompt le fil de lecture et n'est pas annoncée de la même manière selon le navigateur et l'outil d'assistance. Une confirmation posée dans la page reste dans l'ordre de tabulation, se lit comme le reste de l'écran, et laisse la possibilité de revenir en arrière sans avoir à répondre à une question modale.
Ce qui est MESURÉ à chaque génération — et ce que la mesure ne promet pas
Avant d'être livrée, chaque application est ouverte dans un vrai navigateur et parcourue écran par écran. À cette occasion, ce n'est pas l'image qui est examinée mais l'arbre d'accessibilité : la structure que traverse un lecteur d'écran. On y relève les boutons, liens et champs sans nom accessible, les niveaux de titre sautés, les images sans description, et les libellés identiques répétés hors d'une liste. Un « × » de fermeture y est compté comme non nommé, parce qu'un lecteur d'écran le prononce « signe de multiplication ».
Le point d'honnêteté est ici, et il est décisif : c'est un RAPPORT, pas une porte. Il n'y a ni seuil, ni verdict, ni blocage — un écran comportant des contrôles sans nom n'est pas retenu à la livraison. La mesure dit donc ce qu'on sait de l'application ; elle ne promet aucun niveau de conformité. Un chiffre de couverture qui prétendrait le contraire serait exactement le genre de promesse que cette page refuse de faire.
Ce qui n'est PAS fait, et ce que vous pouvez en faire
Trois manques, nommés. Les boîtes de saisie ne piègent pas le focus : la tabulation peut sortir d'un dialogue ouvert, alors que la règle veut qu'elle y tourne. Aucune région vocale n'est posée : un enregistrement réussi, une erreur, une liste rafraîchie se voient à l'écran mais ne sont annoncés à personne. Et il n'existe ni certification RGAA ou WCAG, ni audit indépendant — donc si vous êtes soumis à une obligation légale, cette application ne vous en dispense pas et ne prétend pas le faire.
Ce que vous pouvez en faire est précisément ce qui distingue cette situation d'un logiciel fermé. Le code vous appartient, il est récupérable en archive ou sur un dépôt, et c'est un projet Next.js ordinaire : piéger le focus d'un dialogue ou ajouter une région vocale sont des travaux de développement front-end balisés, chiffrables, que n'importe quel prestataire sait mener. Chez un éditeur classique, le même défaut est un ticket dont vous ne maîtrisez ni la priorité ni la date. Si vous relevez du RGAA, prévoyez votre audit : il est de toute façon obligatoire, et ici ses conclusions sont actionnables.