Lancez un scanner gratuit — WAVE ou le contrôle d’accessibilité intégré à Lighthouse de Chrome — sur votre page d’accueil, et vous aurez un rapport en moins d’une minute : un score, une liste de règles échouées, peut-être une bannière rouge en haut de l’écran. Ce n’est pas la réponse — c’est la première étape. Un scanner excelle à repérer ce qui vit dans le code : un attribut alt manquant, un contraste insuffisant, un niveau de titre qui saute de H2 à H4. Il ne peut pas vous dire si tout ça a du sens pour la personne qui utilise réellement la page. La Web Accessibility Initiative, la branche du W3C qui rédige la norme sur laquelle ces outils se basent, le dit directement : « Les outils ne peuvent pas vérifier automatiquement tous les aspects de l’accessibilité. Un jugement humain est nécessaire. » Une deuxième phrase de la même organisation est encore plus directe sur ce qu’est réellement un rapport — les outils d’évaluation « ne peuvent pas déterminer l’accessibilité, ils ne peuvent qu’aider à le faire ».
Cette nuance compte le plus juste après avoir lancé un scanner, parce qu’un rapport propre se lit comme un verdict alors que ça n’en est pas un. ce que la conformité ADA demande vraiment à vos pages détaille ce que l’ADA et les WCAG exigent réellement d’un site ; ici, la question est plus précise — quoi vérifier de vos propres mains une fois le passage automatisé terminé, et pourquoi. C’est aussi la question qu’on se pose pour chaque site que nous construisons, avant la mise en ligne de la page plutôt qu’après.
Les défauts qu’un scanner juge sans problème
Une poignée de problèmes reviennent sans cesse sur les sites réels, et aucun d’eux ne déclenche de règle dans un outil automatisé, parce qu’aucun n’est du code manquant — c’est du code techniquement présent et concrètement inutile.
Une image peut avoir un attribut alt et échouer complètement quand même : « image1.jpg » ou « photo » satisfait la règle qui vérifie si l’attribut existe, sans rien dire à un utilisateur de lecteur d’écran sur ce que montre l’image. Une page peut avoir un jeu complet de balises de titre et n’avoir aucune vraie structure, parce que les titres ont été choisis selon la taille du texte à l’écran, pas selon ce qui appartient sous quoi — un scanner voit <h2>, <h3>, <h4> et considère que c’est réglé, il ne sait pas que le H3 aurait dû être un H2.
L’ordre de tabulation se brise à des endroits qu’un scanner ne visite jamais, parce qu’il lit surtout la page telle qu’elle se charge, pas telle qu’on l’utilise. Ouvrez un menu déroulant, et la prochaine pression sur Tab peut vous ramener en haut de la page au lieu d’entrer dans le menu qui vient d’apparaître. Ouvrez une fenêtre modale, et le problème inverse survient : le focus reste coincé à l’intérieur, à tourner entre les deux ou trois mêmes éléments sans moyen de sortir avec Tab — un piège au clavier, une des raisons fréquentes pour lesquelles quelqu’un abandonne une page.
Un formulaire peut signaler une erreur au moment où vous le soumettez et quand même échouer : un contour rouge sans texte à côté dit à un utilisateur de souris voyant que quelque chose cloche, mais ne dit rien du tout à un utilisateur de lecteur d’écran, parce que la couleur seule ne transmet aucune information dès qu’on ne peut pas la voir. Le même formulaire peut aussi se passer complètement d’étiquettes et se fier à un texte d’indication logé à l’intérieur du champ — ça ressemble à une étiquette, ça se lit comme une étiquette, et ça disparaît dès que quelqu’un commence à taper, exactement au moment où un lecteur d’écran en avait besoin.
Au-delà du formulaire : des vidéos sans sous-titres, un compteur de panier ou de résultats de recherche qui se met à jour à l’écran sans que rien n’annonce le changement à voix haute, des PDF qui n’ont jamais été construits avec des balises au départ, et des intégrations tierces — un widget de réservation, une bulle de clavardage, une carte — qui font tourner du code que vous ne pouvez pas corriger directement, seulement demander à qui l’a construit, ou remplacer.
Un scanner comme WAVE ou Lighthouse vaut quand même la peine d’être lancé en premier — les deux sont gratuits, les deux sont honnêtes sur leurs propres limites, et la documentation de Lighthouse contient une section distincte de « vérifications manuelles » pour exactement les parties que son score ne couvre pas. Le lancer n’est pas l’erreur. S’arrêter là, oui.
Comment tester vous-même l’accessibilité de votre site, en vingt minutes
Rien de tout ça ne demande un nouveau logiciel. Ça demande de mettre la souris de côté un moment.
Naviguez à la touche Tab dans la page d’accueil et votre formulaire de demande, sans souris. C’est la même vérification préliminaire que recommande le W3C lui-même : cliquez dans la barre d’adresse, mettez la souris de côté, et appuyez sur Tab pour parcourir la page. Observez si chaque lien, bouton et champ de formulaire est atteint dans un ordre logique, si vous pouvez toujours dire où se trouve le focus, et si quoi que ce soit — un menu, une fenêtre contextuelle, une bannière de cookies — vous piège à l’intérieur sans issue.
Zoomez le navigateur à 200 %. Aucune extension — juste le zoom natif du navigateur. Du texte qui se chevauche, des boutons qui disparaissent hors de l’écran, ou un champ de formulaire coupé en deux sont tous des éléments qu’un scanner, qui tourne à une largeur d’affichage fixe, ne remarque jamais.
Désactivez les images. La plupart des navigateurs cachent cette option dans les paramètres. Ce qui reste sur la page, c’est exactement ce qu’un lecteur d’écran annonce en premier — si la page garde son sens avec seulement du texte et des textes alternatifs, c’est bon signe ; si elle se transforme en cases vides et boutons sans nom, c’est exactement ce à quoi un utilisateur de lecteur d’écran fait face.
Activez le lecteur d’écran déjà intégré à votre appareil — VoiceOver sur Mac, Narrateur sur Windows, TalkBack sur Android — pendant quelques minutes sur la page d’accueil et le formulaire. Pas besoin de le maîtriser pour remarquer l’évident : un bouton annoncé comme « bouton », un titre qui n’est jamais annoncé comme un titre, un champ sans nom du tout.
Un test n’est pas un audit
Vingt minutes sur votre propre page d’accueil et votre propre formulaire vous disent si les problèmes les plus gros et les plus courants sont présents. Ça ne couvre pas chaque gabarit du site, chaque état dans lequel un formulaire peut se retrouver une fois que de vraies erreurs surviennent, ni un PDF que personne n’a ouvert depuis deux ans — c’est la différence entre une auto-vérification et ce que couvre vraiment un audit d’accessibilité. C’est aussi un exercice différent d’un audit SEO technique : celui-là vérifie comment une page est structurée pour la recherche, pas si une personne au clavier peut la parcourir.
Le formulaire qui échoue en silence
Un formulaire inaccessible ne renvoie pas d’erreur. Il ne renvoie pas de 404, il ne plante pas, il n’apparaît dans vos analyses comme rien d’inhabituel — il arrête simplement, en silence, d’accepter les soumissions de quiconque ne peut pas le remplir, et rien sur la page ne vous dit que c’est arrivé. Le chiffre de trafic a l’air identique dans les deux cas. Le nombre de soumissions est la seule chose qui change, et la plupart des sites ne regardent jamais d’assez près pour remarquer qu’il a chuté pour une raison qui n’a rien à voir avec l’intérêt.
C’est aussi pourquoi nous comptons les soumissions nous-mêmes plutôt que de les lire sur un tableau de bord — notre propre extension de suivi des demandes est installée sur les sites que nous construisons et enregistre ce qui est réellement arrivé, pour qu’une chute silencieuse soit au moins visible comme un chiffre plutôt que comme rien du tout. Savoir si une page perd des demandes pour des raisons qui n’ont rien à voir avec l’accessibilité est une question plus large, et ça commence ici. Sur un site que nous construisons, l’accessibilité n’est pas une ligne à part — le contraste, des états de focus visibles, un vrai ordre de titres, des étiquettes plutôt que du texte d’indication, un texte alternatif qui décrit l’image viennent avec le texte et la mise en page. Lancez un scanner. Puis prenez vous-même les vingt minutes avant de décider que l’une ou l’autre réponse donne le portrait complet.
