Un instantané sémantique n'est pas un certificat d'accessibilité.

Une refonte de la caisse semble plus propre. Son en-tête devient un div stylisé et le bouton Continuer perd son nom utile. Une comparaison de capture d'écran peut approuver l'apparence tout en manquant le changement sémantique. Un instantané ARIA peut rendre cette structure visible, mais un instantané vert ne certifie pas que l'ensemble de l'expérience est accessible.

Ce guide utilise la documentation des instantanés ARIA de Playwright pour créer un petit contrat sémantique. L'écran qui l'accompagne est une forme inventée localement. Il illustre une relation entre un titre et un bouton, et non un paiement client testé ou un audit d'accessibilité complet.

Commencez par une région que vous pouvez expliquer

Playwright décrit les instantanés ARIA comme des représentations YAML de la structure accessible. Les rôles, noms et attributs sélectionnés proviennent de la sémantique HTML ou ARIA. Un modèle est une contrainte ; il ne s'agit pas nécessairement d'une sérialisation complète de tout ce qui se trouve dans l'arborescence d'accessibilité.

Pour une région de démonstration contrôlée avec un en-tête et un bouton, le chèque peut être suffisamment petit pour être lu en revue :

await expect(page.getByRole('region', { name: 'Demo checkout' }))
  .toMatchAriaSnapshot(`
- heading "Review order" [level=2]
- button "Continue"
  `);

L'exemple suppose que l'application expose cette région nommée et ces contrôles. Cela ne les crée pas. Gardez la portée étroite et les noms liés à la tâche utilisateur prévue. Un instantané géant d'une page entière peut masquer une différence importante entre les modifications non liées à la navigation et au pied de page.

Lisez ce que le modèle oublie

La documentation explique que les noms sont sensibles à la casse, que les espaces sont normalisés et que l'ordre est important. L'omission d'un nom ou d'un attribut permet une correspondance partielle. Cette flexibilité est utile pour les détails dynamiques non pertinents, mais elle supprime également les contraintes qui peuvent protéger l'expérience.

Un modèle qui indique uniquement le bouton peut toujours être transmis après Continuer, devient une étiquette inutile. Une case à cocher sans contrainte d'état coché peut réussir dans l'un ou l'autre état. Notez pourquoi chaque omission est sûre. Si le nom ou l'état accessible est important pour le voyage, conservez-le dans le contrat ou ajoutez une affirmation ciblée.

Évitez de traduire chaque mot accessoire en une exigence de base. Une interface localisée peut avoir des noms légitimes qui diffèrent selon la langue. Choisissez explicitement les paramètres régionaux de test et examinez le texte attendu. Préservez l'intention de la tâche au lieu d'affaiblir la vérification jusqu'à ce que chaque langue réussisse.

Une différence sémantique mérite une revue de produit

Lorsqu'un instantané échoue après une refonte, inspectez la modification avant de mettre à jour le YAML attendu. Un niveau de titre a-t-il changé intentionnellement ? Une région nommée a-t-elle été supprimée ? Le bouton décrit-il toujours son action ? Une mise à jour de la ligne de base enregistre une nouvelle attente ; cela n'explique pas pourquoi cette attente est correcte.

Conservez la différence avec la conception ou la décision de produit pertinente. Si le changement n'est pas intentionnel, corrigez l'interface. Si cela est prévu, mettez à jour le plus petit modèle concerné et conservez la raison. N'acceptez pas un nouvel instantané global simplement pour rendre CI vert.

Pour la démo locale, le remplacement du bouton Continuer par un contrôle visuel sans nom doit être détecté par le contrat sélectionné. Cette vérification négative permet de montrer ce que l'assertion protège. Cela ne prouve toujours pas que toutes les régressions possibles sont couvertes. La portée correspond à la région et au modèle choisis, et non à l'ensemble du site.

La structure est une couche de preuves d'accessibilité

Un arbre de correspondance n'établit pas de contraste lisible, de mise au point utilisable, de complétion du clavier, d'erreurs sensibles ou d'une bonne expérience de lecteur d'écran. Utilisez des contrôles distincts pour ces risques. Le [guide de test d'accessibilité] de Playwright (https://playwright.dev/docs/accessibility-testing) décrit l'analyse automatisée et ses limites ; les contrôles automatisés doivent être accompagnés d'une évaluation manuelle si nécessaire.

Pour ce petit flux, un test de comportement doit activer Continuer et vérifier l'état suivant prévu. Une vérification du clavier doit établir que les utilisateurs peuvent atteindre et utiliser les commandes sans pointeur. L'examen visuel doit inspecter le texte et la mise en page réels rendus. Ce sont des preuves complémentaires, et non des propriétés automatiquement héritées du YAML.

Nommez les résultats avec précision. La vérification de la démo correspond au modèle sémantique sélectionné est une déclaration défendable. Le paiement est accessible est une affirmation beaucoup plus vaste nécessitant plus de preuves. Cette discipline de dénomination aide une petite équipe QA à protéger des contrats significatifs sans créer de badge de certification trompeur.

AnyTest décrit les agents explorant des applications et rédigeant des tests de bout en bout pour une révision humaine. Un évaluateur peut utiliser ce guide pour demander quelle structure et quel comportement un parcours généré vérifie réellement. Aucun instantané ARIA spécifique ou intégration d'accessibilité dans AnyTest n'est revendiqué ici. L'avantage est une limite sémantique lisible qui survit à une refonte et reste honnête sur ce qui n'a pas été testé.