Vérification manuelle avec une technologie d'assistance

Il s'agit ici de procédures de vérification manuelle ciblées, pour des résultats et des corrections précis - un moyen, pour l'équipe qualité d'une agence partenaire et non pour un spécialiste de l'accessibilité à temps plein, de confirmer à la main qu'une correction donnée fonctionne réellement avec un lecteur d'écran ou au clavier. Elles ne remplacent pas un audit d'accessibilité manuel professionnel.

À qui cela s'adresse

  • À l'équipe qualité d'une agence, pour confirmer la correction d'une personne développeuse avant que le client ne la voie.
  • Aux équipes conformité d'un fournisseur, pour valider une auto-évaluation au format VPAT là où l'automatisation ne suffit pas.
  • Aux acheteurs, pour contrôler par sondage un site dont ils envisagent d'acquérir le logiciel.

Avant de commencer

Chaque correction propre à une règle comporte une section Vérifier maintenant with … sur la fiche du problème : c'est la recette de référence. Ce document donne le cadre plus général : comment installer les outils, et comment interpréter ce que l'on entend lorsque l'analyseur indique une réussite.

Installation, une fois pour toutes

Windows et NVDA (point de départ recommandé)

  1. Téléchargez NVDA depuis le site de NV Access. NVDA est gratuit ; AllyProof ne le fournit pas.
  2. Installez-le à l'emplacement par défaut. Au premier lancement, NVDA lit la fenêtre à voix haute : montez le volume et vérifiez que vous l'entendez.
  3. Configurez Firefox ou Chrome comme navigateur de test. NVDA fonctionne avec les deux ; Firefox présente un comportement légèrement meilleur pour l'arbre d'accessibilité.
  4. Apprenez les cinq raccourcis qui couvriront 90 % de vos besoins : Tab, H (titre suivant), D (repère suivant), F (champ de formulaire suivant), NVDA+Espace (basculer entre mode navigation et mode formulaire).

macOS et VoiceOver

  1. Activez-le dans Réglages Système → Accessibilité → VoiceOver. La fonction est intégrée : aucune installation.
  2. Apprenez la touche VO : Contrôle + Option. Presque tous les raccourcis de VoiceOver en sont préfixés.
  3. Safari est le partenaire natif de VoiceOver. Chrome fonctionne, mais présente des particularités avec les contenus dynamiques.

Vérification au clavier seul (sur les deux plateformes)

La moitié de ce qu'on appelle « tester avec une technologie d'assistance » consiste simplement à débrancher la souris. Tab, Maj+Tab, Entrée, Espace et les touches fléchées : si vous ne pouvez pas atteindre chaque élément interactif et l'activer, le site échoue, quoi qu'en dise un lecteur d'écran.

Comment vérifier un problème précis

  1. Sur la fiche du problème dans AllyProof, lisez le panneau Vérifier maintenant with … : il nomme l'outil et les étapes exactes.
  2. Ouvrez la page concernée dans le navigateur indiqué, avec la technologie d'assistance mentionnée en fonctionnement.
  3. Suivez les étapes numérotées. Dans le cadre de la vérification de ce défaut connu, chaque étape correspond à un seul résultat observable : l'annonce ou le comportement correspond à l'attendu, ou non, sans appréciation à porter à chaque étape. C'est cette propriété qui rend ces recettes exécutables par des personnes non spécialistes ; c'est aussi pourquoi elles ne confirment que le comportement attendu précis, et rien au-delà.
  4. Si la vérification réussit, laissez un commentaire de test manuel sur le problème - le formulaire de commentaire propose un type Manual verification - en indiquant le nom de l'outil, le système d'exploitation et la date. C'est ce que votre client verra dans la traçabilité.
  5. Si la vérification échoue, rouvrez le problème et notez précisément l'étape qui a échoué. Une capture d'écran ou une transcription de la synthèse vocale est idéale.

Ce que ces recettes ne sont pas

Ces recettes vérifient des comportements attendus précis. Un audit d'accessibilité manuel complet exige en outre une appréciation contextuelle, le test de processus entiers, un échantillonnage représentatif et des tests exploratoires avec des technologies d'assistance. Réussir toutes les recettes de cette page confirme que chaque correction fonctionne - cela n'établit pas la conformité du site aux WCAG.

Pièges courants

  • Tester en mode formulaire alors qu'il faudrait être en mode navigation. Le mode navigation de NVDA simule la lecture de la page ; le mode formulaire sert à remplir un formulaire. Si les touches fléchées ne parcourent pas le contenu, appuyez sur NVDA+Espace.
  • Exécuter la technologie d'assistance dans le mauvais navigateur. Une page correctement restituée sous Safari et VoiceOver peut se comporter autrement sous Chrome et VoiceOver, en raison de différences subtiles dans l'arbre d'accessibilité. Utilisez le navigateur indiqué sur la fiche du problème.
  • Considérer que « l'analyseur réussit » signifie « c'est terminé ». L'automatisation détecte la syntaxe ; elle ne peut pas dire si le nom d'un bouton a du sens en contexte. Exécutez toujours la vérification manuelle indiquée après le passage au vert de l'analyse.
  • Se limiter au lecteur d'écran en sautant le test au clavier seul. Les personnes utilisant un lecteur d'écran naviguent en général au clavier : s'il existe des pièges au clavier, l'expérience au lecteur d'écran est elle aussi défaillante. Commencez par le passage au clavier.

Ce qui constitue un élément de preuve suffisant

Pour une auto-évaluation au format VPAT ou une déclaration d'accessibilité publique :

  • nommez l'outil (par exemple NVDA 2024.4), le navigateur (par exemple Firefox 128 ESR) et le système d'exploitation (par exemple Windows 11) utilisés pour la vérification ;
  • consignez la date de la vérification : les personnes qui relisent attendront qu'elle remonte au trimestre en cours ;
  • pour les constats contestés, conservez une courte transcription - copie de la sortie de la visionneuse vocale de NVDA, ou enregistrement de VoiceOver.

Quand faire appel à un spécialiste de l'accessibilité

Une équipe qualité partenaire peut vérifier en confiance la trentaine de règles du catalogue d'AllyProof. Faites appel à une personne spécialisée dans les tests d'accessibilité dès que l'une de ces conditions est réunie :

  • Le problème concerne des régions live ARIA, des composants sur mesure (listes combinées, arborescences, grilles) ou le comportement de contenus dynamiques : la vérification n'y est pas mécanique, étape par étape.
  • Le site relève du secteur public, de la santé ou de la finance, où une appréciation erronée a des conséquences juridiques.
  • La personne qui relit le VPAT demande expressément une attestation d'expert tiers : dans ce cas, la couverture automatisée et la vérification par l'équipe qualité partenaire constituent le socle, non le plafond.