Ce qu’un scanner voit (et ce qu’il ne verra jamais)
Un scanner d’accessibilité repère très vite les erreurs manifestes et oriente le travail : image sans alt, langue non déclarée, titres mal structurés, contraste calculable.
Chapitres
- 0:00Situations du quotidien (nouvelle fenêtre, YouTube)
- 0:22L’outil avec l’humain, pas contre lui (nouvelle fenêtre, YouTube)
- 0:45Ce qu’un test automatique fait très bien (nouvelle fenêtre, YouTube)
- 1:09Présent ne veut pas dire pertinent (nouvelle fenêtre, YouTube)
- 1:39Tout vert ne veut pas dire utilisable (nouvelle fenêtre, YouTube)
- 2:14Propre pour l’outil, perdu au clavier (nouvelle fenêtre, YouTube)
- 2:47Une piste à confirmer, pas un verdict (nouvelle fenêtre, YouTube)
- 3:18Checklist (nouvelle fenêtre, YouTube)
- 3:48CTA (nouvelle fenêtre, YouTube)
Transcription
Texte intégral de la narration de l’épisode.
Situations du quotidien
Tu lances un scanner d’accessibilité sur ta page, le rapport ressort sans erreur, et tu te dis : c’est bon, mon site est accessible. C’est là que tout se joue. Un outil automatique voit certaines choses très bien, et il en rate d’autres par nature. Pas parce qu’il est mauvais, mais parce que certaines vérifications demandent un jugement humain. Voyons précisément ce qu’un scanner voit, et ce qu’il ne verra jamais tout seul.
L’outil avec l’humain, pas contre lui
Le bon modèle, ce n’est pas l’outil contre l’humain, c’est l’outil avec l’humain. Un scanner passe la page au crible en quelques secondes, repère les erreurs manifestes et t’oriente vers les zones à risque. Ensuite, un auditeur reprend la main pour juger ce qui ne se mesure pas automatiquement. Retiens un principe : certains tests d’un critère peuvent être automatisés, mais jamais un critère entier.
Ce qu’un test automatique fait très bien
Commençons par ce qu’un test automatique fait très bien. Il repère en un instant une image qui n’a aucun attribut alt. Il vérifie que la langue de la page est déclarée. Il liste la structure des titres et signale un niveau sauté. Il calcule le contraste entre une couleur de texte et un fond bien définis. Tout ça, c’est précieux : ça dégrossit le travail et ça pointe les endroits à regarder. Mais chacune de ces vérifications reste partielle.
Présent ne veut pas dire pertinent
Prenons l’exemple des images. Un scanner sait dire si l’attribut alt est présent ou absent. À gauche, l’image n’a pas d’alternative : l’outil le détecte tout de suite. À droite, l’attribut est là, donc pour l’outil, c’est bon. Mais est-ce que ce texte décrit vraiment l’image ? Un alt qui dit simplement « image », « photo » ou « logo » est bien présent, et pourtant il n’apporte aucune information utile. Juger si une alternative est pertinente, ça, c’est un travail humain. La présence se mesure, la pertinence se juge.
Tout vert ne veut pas dire utilisable
Maintenant, imagine un rapport automatique complet sur une page. Résultat : tout est vert. Les alternatives sont présentes, la langue est déclarée, les titres sont structurés, les contrastes calculés passent. Sur le papier, aucune erreur. Puis un auditeur reprend la même page à la main. Et là, la liste s’allonge : un alt bien présent mais qui ne veut rien dire, un ordre de tabulation qui part dans tous les sens, une fenêtre modale qui emprisonne le clavier, des sous-titres qui ne correspondent pas à l’audio. Le vert automatique n’était pas un feu vert, c’était juste un point de départ.
Propre pour l’outil, perdu au clavier
Autre exemple, encore plus parlant. Une page peut être parfaitement propre pour un outil et devenir un piège dès qu’on lâche la souris. Regarde : au clavier, on appuie sur Tab pour se déplacer d’un élément à l’autre. À gauche, rien ne change à l’écran, impossible de savoir où on se trouve. À droite, un contour net suit chaque élément actif. Un outil ne sait pas juger de façon fiable si ce focus reste visible. Un humain, lui, le voit en trois secondes de navigation clavier. C’est tout le sens du critère 10.7 sur la visibilité de la prise de focus.
Une piste à confirmer, pas un verdict
Alors comment s’en servir sans se tromper. L’erreur, c’est de prendre un rapport automatique sans erreur et de le coller comme preuve de conformité. Le bon réflexe, c’est de traiter chaque signal comme une piste à confirmer, pas comme un verdict. Une anomalie détectée par un outil, ce n’est pas une non-conformité établie : c’est un endroit à aller vérifier. Automatique pour dégrossir et gagner du temps, humain pour statuer. La conformité d’un critère, au bout du compte, se tranche à la main.
Checklist
Récapitulons ce qu’un scanner ne verra jamais tout seul. Premièrement, la pertinence d’une alternative : un alt peut être présent et complètement faux. Deuxièmement, la logique de navigation et l’ordre de tabulation. Troisièmement, les comportements dynamiques, comme une modale ou un menu déroulant. Quatrièmement, la qualité réelle des sous-titres et de l’audio-description. Et pour finir, le contraste d’un texte incrusté dans une image. Sur tous ces points, l’outil oriente, mais c’est l’humain qui juge.
CTA
Un scanner, c’est un excellent copilote : il balaie la page, repère les erreurs manifestes et te dit où creuser. Le reste, la pertinence, les parcours, le clavier, le multimédia, c’est ton regard qui le tranche. Pour lancer cette première passe, repérer les signaux à vérifier et orienter ton audit, va sur rgaa-checker.com. L’outil t’oriente et te fait gagner du temps ; il ne délivre pas un taux de conformité officiel à ta place.
Approfondir dans le guide
Cet épisode aborde ces critères du RGAA 4.1.2. Ouvre leur fiche pour la méthode de test détaillée, les cas particuliers et les exemples.
Vidéos liées
D’autres épisodes qui abordent des critères proches, dans d’autres séries.
- Images et alternatives textuelles
Épisode 5Bases RGAA3 minEn ligne
- Navigation au clavier
Épisode 3Bases RGAA4 minEn ligne
Passer à l’action
La vidéo pose le cadre. Pour repérer des pistes d’amélioration sur un site réel, lance une analyse ou explore le guide des 106 critères.

