Tester l'accessibilité de votre site : la méthode

Les scanners automatiques ne suffisent pas : avec ce plan de test en 7 étapes, vous vérifiez votre site de manière systématique – du clavier au lecteur d'écran.

Pourquoi un plan de test vaut mieux qu'un outil isolé

Beaucoup d'exploitants de sites lancent un scan automatique, voient quelques messages d'erreur et considèrent le sujet comme réglé. C'est trop court : l'accessibilité ne se vérifie que partiellement de façon automatisée. Savoir si une page est réellement utilisable au clavier, si un lecteur d'écran restitue les contenus de manière cohérente ou si les messages d'erreur des formulaires sont compréhensibles – cela, vous devez l'essayer vous-même.

Le plan de test qui suit combine donc outils automatiques et vérifications manuelles. Vous n'avez besoin d'aucun équipement spécialisé : un navigateur à jour, un clavier et le lecteur d'écran déjà installé sur votre système d'exploitation suffisent pour commencer. La référence est la norme WCAG 2.2, le standard international pour des contenus web accessibles.

Étape 1 : les scanners automatiques comme point de départ

Les outils automatiques détectent rapidement et de manière fiable les erreurs techniques typiques : attributs alt manquants, contrastes insuffisants, étiquettes de formulaire absentes, attributs ARIA erronés. Trois outils gratuits et éprouvés :

• Lighthouse : intégré à Chrome et Edge. Ouvrez les outils de développement (F12), onglet « Lighthouse », sélectionnez la catégorie « Accessibility » et lancez le rapport.
• axe DevTools : extension de navigateur de Deque. Après l'installation, vous trouverez dans les outils de développement un onglet dédié qui marque les problèmes directement dans le code.
• WAVE : un outil de vérification de l'organisation américaine WebAIM (sans lien avec Wave Tools – la ressemblance des noms est fortuite). Il superpose des symboles directement sur votre page et rend ainsi les problèmes très parlants.

Ne testez pas seulement la page d'accueil, mais chaque type de page : accueil, page de contenu, page de formulaire, page produit ou article, résultats de recherche.

Étape 2 : le test au clavier

Mettez la souris de côté et utilisez votre site uniquement au clavier. Avec la touche Tab, vous avancez d'un élément interactif à l'autre, avec Maj+Tab vous reculez, avec Entrée ou la barre d'espace vous les déclenchez. Soyez attentif à trois choses :

1. L'ordre : le focus doit se déplacer dans un ordre logique – en général de haut en bas et de gauche à droite, en suivant la structure visible. S'il saute dans tous les sens, quelque chose ne va pas dans la structure du document.
2. La visibilité : vous devez pouvoir reconnaître à tout moment quel élément a le focus. Si le contour de focus manque (souvent supprimé en CSS avec outline), les utilisateurs au clavier sont perdus.
3. Pas de pièges : vous devez pouvoir quitter chaque élément. Les pièges classiques sont les widgets embarqués, les bandeaux de cookies et les fenêtres modales qui ne se ferment pas avec Échap.

Testez aussi les menus, accordéons, carrousels et sélecteurs de date – c'est précisément là que beaucoup de sites échouent.

Étape 3 : test de base au lecteur d'écran

Un lecteur d'écran lit la page telle que les personnes aveugles ou fortement malvoyantes la perçoivent. Pour un test de base, vous n'avez rien à acheter :

• Windows : NVDA est gratuit et très répandu. Après le démarrage, il lit automatiquement ; avec la touche H, vous sautez de titre en titre, avec Tab vous parcourez les éléments interactifs.
• macOS et iOS : VoiceOver est intégré. Sur Mac, vous le lancez avec Cmd+F5, sur iPhone via les réglages, dans Accessibilité.

Posez-vous trois questions en écoutant : la page a-t-elle du sens même sans écran ? Les images sont-elles annoncées avec des textes alternatifs pertinents ou seulement avec des noms de fichiers ? Pour les boutons et les liens, apprenez-vous ce qui se passe si vous les activez – ou n'entendez-vous que « lien » et « cliquez ici » ? Dix minutes avec un lecteur d'écran vous en apprennent déjà plus sur votre site que n'importe quel rapport.

Étape 4 : zoom à 200 % et reflow

Beaucoup de personnes malvoyantes agrandissent les contenus dans le navigateur. Les WCAG exigent que le texte reste utilisable à 200 % de zoom, sans perte de contenu ni de fonctionnalité. Voici comment tester :

1. Agrandissez la page avec Ctrl et + (Mac : Cmd et +) progressivement jusqu'à 200 %.
2. Vérifiez si des textes sont tronqués, se chevauchent, ou si des éléments de commande sortent de la zone visible.
3. Réduisez en plus la fenêtre du navigateur à environ 320 pixels de large ou zoomez à 400 % : le contenu doit maintenant se réorganiser sur une seule colonne (reflow), sans que vous ayez à faire défiler horizontalement.

Si votre site est construit proprement en responsive, il passe généralement ce test sans retouche – sinon, vous voyez immédiatement où ça coince.

Étape 5 : vérifier les contrastes

Les contrastes trop faibles comptent parmi les barrières les plus fréquentes. Les WCAG exigent pour le texte normal un rapport de contraste d'au moins 4,5:1 avec l'arrière-plan, pour le texte de grande taille (à partir d'environ 24 pixels, ou 19 pixels en gras) au moins 3:1. Les éléments de commande et les symboles graphiques ont eux aussi besoin d'au moins 3:1.

Pour mesurer, utilisez le Contrast Checker de WebAIM, la pipette de couleurs des outils de développement du navigateur ou des applications de bureau comme le Colour Contrast Analyser. Vérifiez en priorité les candidats critiques : texte gris clair sur fond blanc, textes indicatifs dans les champs de formulaire, texte sur photos et boutons aux couleurs de la marque. Ne vous fiez pas à votre impression sur votre propre écran bien réglé – mesurez.

Étape 6 : formulaires et messages d'erreur

Les formulaires sont l'endroit où les barrières coûtent le plus cher – c'est là que commandes et demandes sont abandonnées. Remplissez chaque formulaire important une fois entièrement, une fois volontairement de façon erronée et une fois uniquement au clavier. Veillez à ceci :

• Chaque champ possède une étiquette visible et reliée programmatiquement – un texte indicatif dans le champ ne remplace pas une étiquette, car il disparaît dès que l'on tape.
• Les champs obligatoires sont signalés comme tels, pas uniquement par la couleur.
• Les messages d'erreur apparaissent sous forme de texte directement au niveau du champ concerné, expliquent concrètement ce qui est faux et comment corriger – « Saisie invalide » seul n'aide personne.
• Après un envoi comportant des erreurs, ce qui a déjà été saisi est conservé.
• Les limites de temps, par exemple dans les parcours de réservation, peuvent être prolongées ou désactivées.

Étape 7 : vérifier les contenus – textes alternatifs, titres, intitulés de liens

Pour finir, place au niveau éditorial, qu'aucun outil ne peut évaluer :

• Textes alternatifs : le texte alternatif décrit-il ce que montre l'image et quelle est sa fonction ? Les images purement décoratives portent-elles un attribut alt vide ? Notre article Bien rédiger les textes alternatifs montre comment produire de bons textes alternatifs.
• Hiérarchie des titres : exactement un H1 par page, puis une structure sans trou (H2, puis H3 en dessous). Les titres sont de la structure, pas un outil de mise en forme – choisir un H4 parce qu'il a l'air joliment petit sabote la navigation au lecteur d'écran.
• Intitulés de liens : chaque lien doit être compréhensible par lui-même. « En savoir plus » et « ici » ne le sont pas – « Télécharger la liste des prix en PDF », oui.

Prioriser, documenter, persévérer

Après les sept étapes, vous disposez d'une liste de constats. Classez-les par impact : d'abord les bloqueurs qui empêchent complètement l'utilisation (pièges clavier, formulaires sans étiquettes, navigation inutilisable), puis les obstacles majeurs comme les textes alternatifs manquants sur les pages centrales et les contrastes faibles, enfin les finitions.

Documentez chaque constat avec la page, une description, le critère WCAG concerné et la correction prévue. Cette documentation paie doublement : elle sert de base de travail à votre équipe – et elle fournit les faits pour votre déclaration d'accessibilité, dans laquelle vous devez de toute façon mentionner les limitations connues et les mesures prévues.