Comment une boutique est testée, et selon quelles normes

Le W3C publie les Web Content Accessibility Guidelines (WCAG 2.1, WCAG 2.2). L’ETSI publie la norme EN 301 549. Sa clause 9 reprend les critères de succès des WCAG aux niveaux A et AA comme exigences applicables aux contenus web, numérotées par 9 suivi du numéro du critère : le critère 1.1.1 correspond à la clause 9.1.1.1. Un critère ajouté par les WCAG 2.2, comme le critère 2.5.8 Target Size (Minimum), n’a de clause que dans la version V4.1.1, dont les exigences relatives au web sont alignées sur les WCAG 2.2.

Validiscan travaille selon les WCAG 2.2 niveau AA, car c’est la version la plus récente, et celle sur laquelle est alignée la norme EN 301 549 V4.1.1, publiée par l’ETSI en septembre 2026. L’Accessibility Guidelines Working Group du W3C, qui rédige les WCAG, recommande aux sites d’adopter les WCAG 2.2 comme nouvelle cible de conformité, même si les obligations formelles mentionnent des versions antérieures (WCAG 2.2). Les résultats sont aussi présentés selon les WCAG 2.1 niveau AA, car c’est le niveau que reprend la norme EN 301 549 V3.2.1, la version dont la référence est publiée au Journal officiel au titre de la directive sur l’accessibilité des sites web.

Les deux versions se recouvrent presque entièrement. Chaque critère de succès des WCAG 2.1 aux niveaux A et AA figure aussi dans les WCAG 2.2, sauf le critère 4.1.1 Parsing, que les WCAG 2.2 ont supprimé. Les WCAG 2.2 ajoutent six critères à ces niveaux :

• 2.4.11 Focus Not Obscured (Minimum), niveau AA
• 2.5.7 Dragging Movements, niveau AA
• 2.5.8 Target Size (Minimum), niveau AA
• 3.2.6 Consistent Help, niveau A
• 3.3.7 Redundant Entry, niveau A
• 3.3.8 Accessible Authentication (Minimum), niveau AA

Chaque critère est évalué une seule fois. Le Remediation Evidence Package présente ensuite les résultats deux fois, dans un tableau pour les WCAG 2.1 niveau AA et dans un autre pour les WCAG 2.2 niveau AA. Le critère 4.1.1 Parsing ne figure que dans le tableau des WCAG 2.1 : le dossier le consigne comme satisfait, avec pour fondement « Toujours satisfait pour les contenus HTML (errata des WCAG 2.1) ».

Le dossier décrit ce qu’il couvre par cette phrase : « La conformité aux critères de succès des WCAG 2.1 niveau AA et des WCAG 2.2 niveau AA, telle qu’évaluée sur les pages et aux dates indiquées. » Il indique aussi : « Ce dossier constitue la preuve d’une évaluation et de travaux de correction. Il ne s’agit pas d’un certificat, et il ne se prononce pas sur la conformité juridique. »

Le scanner de Validiscan charge chaque page dans un vrai navigateur, Chromium piloté par Playwright, et y exécute deux types de règles : les règles d’axe-core, un moteur open source de test d’accessibilité, et les contrôles propres à Validiscan pour les obstacles typiques des boutiques en ligne. Chaque constat indique sa règle, les éléments et les pages où cette règle échoue, ainsi que les critères WCAG et les clauses de la norme EN 301 549 qui lui sont associés.

Beaucoup de critères de succès des WCAG exigent l’appréciation d’une personne. La liste de vérifications manuelles de Validiscan compte 35 points, chacun portant sur un critère de succès de niveau A ou AA que des contrôles automatisés ne peuvent pas entièrement prouver. Sur les 55 critères de succès des WCAG 2.2 aux niveaux A et AA, 22 ne sont testés par aucune règle exécutée et sont couverts uniquement par cette liste. Les 33 autres sont testés par au moins une règle exécutée. Pour certains d’entre eux, comme l’utilisation au clavier, l’ordre du focus et les sous-titres, la liste comporte aussi un point, parce qu’une règle ne les teste qu’en partie. Pour les autres, elle n’en comporte aucun.

La liste demande, entre autres, ces vérifications :

• le parcours jusqu’au panier au clavier seul : les menus, une fiche produit, le choix d’une variante, l’ajout au panier, puis la modification d’une quantité et la suppression d’un article ;
• chaque fenêtre modale et le bandeau cookies au clavier : le focus y entre, la touche Échap les ferme, le focus revient ;
• la recherche, les variantes de produit, le panier et les champs du tunnel de commande avec un lecteur d’écran ;
• les erreurs de formulaire : annoncées dès qu’elles apparaissent, avec le nom du champ et la façon de corriger l’erreur ;
• la page agrandie à 400 % ;
• les vidéos : sous-titres et audiodescription.

La liste indique les lecteurs d’écran à utiliser pour ces vérifications : NVDA avec Chrome sous Windows, et VoiceOver avec Safari sur un Mac. Pour chaque point, Validiscan enregistre un résultat (réussi, échoué ou non applicable), avec des notes et des preuves. Ce résultat détermine la manière dont le critère est présenté dans le Remediation Evidence Package.

Un scan complet, qui est le scan de référence d’un projet, charge un échantillon de chaque type de page de la boutique, jusqu’à 150 pages échantillonnées par défaut : la page d’accueil, les listes de produits, les fiches produit et les autres types de pages qu’il trouve. S’y ajoutent, lorsque le scan les trouve, le panier, la première étape du tunnel de commande, les résultats de recherche, la page de connexion ou d’inscription, la page de contact et les pages juridiques. Par défaut, chaque page est chargée aux dimensions d’un écran d’ordinateur (1440 × 900 pixels) et d’un téléphone (390 × 844 pixels, avec saisie tactile), et tous les contrôles s’exécutent aux deux tailles.

Pour atteindre le panier et le tunnel de commande, le scan ajoute au panier un produit en stock, ouvre le panier et ouvre la première étape du tunnel de commande. Il ne finalise jamais d’achat et ne saisit jamais de données de paiement.

Un bandeau cookies est d’abord testé en tant qu’élément de la page. Par défaut, le scan l’accepte ensuite, afin que le reste de la page puisse être testé. Les services connus d’analyse, de publicité, de chat et d’avis sont bloqués par défaut pendant un scan, afin que les résultats n’en dépendent pas. Les outils de consentement ne sont pas bloqués, car le bandeau cookies fait partie de ce qui est testé.

Validiscan ne scanne une boutique en entier qu’avec l’autorisation de son propriétaire. Un scan complet, un scan de vérification et une exécution de la protection contre les régressions exigent l’autorisation écrite du propriétaire de la boutique, enregistrée dans l’application de Validiscan avec l’heure et le nom de la personne qui l’a enregistrée. Sans cet enregistrement, l’application refuse de mettre le scan en file d’attente, et une exécution planifiée de la protection contre les régressions n’a pas lieu.

Un scan complet suit par défaut le fichier robots.txt de la boutique. Il ne peut être configuré pour ignorer robots.txt que si l’autorisation du propriétaire de la boutique est enregistrée.

La vérification gratuite s’effectue sans cette autorisation, dans des limites fixes. Elle charge au plus 15 pages, n’ajoute jamais rien à un panier et n’ouvre jamais le tunnel de commande. Elle suit le fichier robots.txt de l’hôte de la boutique et laisse au moins 1 s entre les requêtes qu’elle lance elle-même, avec des exceptions connues : sa première requête, pour la page d’accueil, est faite avant la lecture de robots.txt, et lorsque la boutique répond à un chargement de page dans le navigateur par une redirection, le navigateur la suit aussitôt, sans cet intervalle et sans vérifier robots.txt. La page consacrée à la vérification gratuite décrit chaque limite et chaque exception.

Les contrôles automatisés ne trouvent qu’une partie des obstacles à l’accessibilité, et un scan décrit les pages qu’il a chargées aux dates où il s’est exécuté. Le Remediation Evidence Package énonce ses propres limites. La liste ci-dessous nomme aussi des lacunes de son scanner que Validiscan a consignées et pas encore comblées.

• Les contrôles automatisés ne prouvent qu’une partie des WCAG. Une règle ne peut pas juger si une alternative textuelle décrit son image, si un message d’erreur a un sens lorsqu’il est lu à voix haute, ni si des sous-titres sont corrects. La liste de vérifications manuelles couvre ces deux derniers points. La qualité des alternatives textuelles n’a aujourd’hui aucun point dans la liste : un résultat « Satisfait » pour le critère 1.1.1 Non-text Content repose donc sur les seuls contrôles automatisés. Les échecs qu’un scan signale sont un minimum, pas un total.
• Les pages sont échantillonnées. Un scan contrôle un échantillon de chaque type de page. Les autres pages construites à partir des mêmes templates devraient se comporter de la même façon, mais elles ne sont pas contrôlées une par une.
• Un scan est un instantané. Les résultats décrivent la boutique aux dates des scans. Les modifications ultérieures du thème, des applications ou du contenu ne sont pas couvertes avant le scan suivant ; la protection contre les régressions scanne de nouveau la boutique selon un calendrier.
• Le tunnel de commande s’arrête à sa première étape. Aucune commande n’est passée et aucune donnée de paiement n’est saisie ; les étapes suivantes du tunnel de commande ne sont donc pas testées automatiquement.
• Cadres d’une autre origine et shadow DOM fermé. Les contenus situés dans des cadres d’une autre origine (cross-origin) et dans un shadow DOM fermé, comme les champs de paiement et certains outils de consentement et widgets, ne sont pas évalués automatiquement. Le contrôle du bandeau cookies de Validiscan n’évalue pas un bandeau situé dans un shadow DOM ou dans un cadre d’une autre origine.
• Les services bloqués ne sont pas testés. Les services d’analyse, de publicité, de chat et d’avis qu’un scan bloque ne sont pas testés. La correction des intégrations tierces, comme le paiement et le chat, ne fait pas non plus partie d’un projet.
• Les résultats « à examiner » ne sont pas encore signalés. Lorsqu’axe-core ou l’un des contrôles de Validiscan ne peut pas trancher, il marque le résultat comme « à examiner » au lieu de signaler un échec. Le scanner ne conserve pas ces résultats aujourd’hui : ils n’apparaissent donc pas comme des constats. Cela concerne les liens vers des PDF et d’autres documents, que le contrôle des documents de Validiscan se contente de marquer comme « à examiner », ainsi que les résultats sur le bandeau cookies, le focus, le clavier et les formulaires qu’un contrôle n’a pas pu trancher. Quelques règles exécutées ne peuvent donc pas produire de constat aujourd’hui. Tant que le scanner ne conserve pas ces résultats, Validiscan vérifie le bandeau cookies à la main et consigne le résultat dans la liste de vérifications manuelles. Les PDF eux-mêmes ne font pas partie d’un projet.
• Les captures d’écran montrent le premier écran. Le scanner capture chaque page à la taille de l’écran, et non sur toute sa longueur. La capture d’un constat situé plus bas dans une page montre le haut de la page. Tant que le scanner ne capture pas les pages entières ou des éléments isolés, Validiscan vérifie à la main les figures de chaque Remediation Evidence Package avant l’émission du dossier.