Diagnostic Flash accessibilité : les 15 points officiels expliqués

Comment estimer l'accessibilité d'un site quand on n'est ni auditeur ni développeur ? DesignGouv, l'équipe design et accessibilité de la DINUM, a une réponse concrète : le Diagnostic Flash, une série de 15 vérifications réalisables par n'importe qui, avec un navigateur et deux extensions gratuites. En une heure ou deux, vous obtenez une première photographie honnête de votre site. Pas un verdict de conformité : une photographie.

Ce guide reprend les 15 points officiels un par un, les relie aux critères RGAA qu'ils recouvrent, et précise à chaque fois ce qu'un scanner automatique détecte déjà et ce qui reste entre vos mains. Parce qu'il faut le dire d'emblée : une partie de ces vérifications s'automatise très bien, une autre pas du tout.

---

Le Diagnostic Flash, qu'est-ce que c'est ?

Le Diagnostic Flash est une méthode d'évaluation rapide et partielle de l'accessibilité d'un site web, publiée par DesignGouv (DINUM). Elle regroupe 15 vérifications sans prérequis technique, organisées en trois familles : navigation et utilisation, langage et interface, structuration de l'information.

Sa promesse tient en une phrase : donner à des non-experts un moyen fiable de repérer les problèmes d'accessibilité les plus courants avant d'engager un audit. DesignGouv le recommande d'ailleurs comme premier réflexe, y compris pour vérifier le travail d'un prestataire qui affirme livrer un site accessible.

Deux extensions de navigateur suffisent pour l'ensemble de la méthode : HeadingsMap (hiérarchie des titres) et Contrast Checker (ratios de contraste), toutes deux disponibles sur Chrome, Firefox et Edge.

---

Navigation et utilisation : 4 vérifications

Cette première famille contrôle qu'on peut se déplacer et agir sur le site, quel que soit l'équipement ou la méthode de navigation.

• Le site est optimisé pour toutes les tailles d'écran. Testez sur smartphone ou en réduisant la fenêtre du navigateur : rien ne doit disparaître ni se chevaucher (critère 13.9). Côté scan : la présence d'un viewport responsive et les largeurs fixes problématiques se détectent automatiquement, mais le rendu réel en portrait et paysage se juge à l'œil.
• La navigation et l'utilisation peuvent s'effectuer entièrement au clavier. Tabulez dans la page : le focus doit rester visible en permanence, des liens d'accès rapide doivent mener au contenu principal, et aucun composant ne doit piéger le curseur (critère 10.7, critère 12.9). Côté scan : les liens d'évitement et la suppression du focus en CSS se repèrent automatiquement ; l'ordre de tabulation et les pièges clavier exigent un test humain. Notre testeur de focus vous accompagne dans cet exercice.
• Deux moyens de navigation sont présents. Menu principal, plan du site, moteur de recherche : il en faut au moins deux (critère 12.1). Côté scan : la présence de ces éléments se détecte ; leur pertinence (un plan du site à jour, un moteur qui trouve vraiment) se vérifie à la main.
• Les fichiers bureautiques téléchargeables sont en format ouvert et accessibles. PDF pour les documents à consulter, ODT, ODP et ODS pour les documents modifiables (critère 13.3). Côté scan : les documents en téléchargement sont repérés et signalés, mais leur accessibilité interne (balisage, ordre de lecture) demande une analyse dédiée, par exemple avec notre vérificateur de documents accessibles.

Un détail qui surprend souvent : la navigation au clavier ne concerne pas que les personnes aveugles. Elle sert aussi les personnes avec un handicap moteur, les utilisateurs de commandes vocales, et tous ceux dont la souris vient de rendre l'âme un vendredi soir.

---

Langage et interface : 7 vérifications

La deuxième famille est la plus fournie. Elle contrôle que les contenus se perçoivent et se comprennent.

• Les contrastes sont suffisants. Le texte doit atteindre un ratio de 4,5:1 avec son arrière-plan, les composants d'interface (boutons, champs, icônes porteuses d'information) un ratio de 3:1 (critère 3.2, critère 3.3). Le seuil descend à 3:1 pour les textes agrandis, à partir de 24 px, ou 18,5 px en gras. Côté scan : les ratios calculables se mesurent automatiquement ; les textes posés sur des images ou des dégradés restent à vérifier avec un calculateur de contraste.
• Aucune information n'est véhiculée uniquement par la couleur. Un formulaire qui signale ses erreurs seulement en rouge exclut les personnes daltoniennes, soit 8 % des hommes selon DesignGouv (critère 3.1). Les liens dans le texte doivent être soulignés, pas seulement colorés. Côté scan : certains indices se détectent (liens non soulignés, états portés par la seule couleur), le verdict final reste humain.
• Les images, vidéos et fichiers audio ont une alternative textuelle. Chaque image porteuse d'information a un attribut alt pertinent, chaque image décorative un alt="" vide, chaque vidéo des sous-titres et une transcription (critère 1.1). Côté scan : les alt manquants ou suspects se détectent très bien, et une analyse par IA peut proposer un premier avis sur la pertinence. La décision finale (cette alternative transmet-elle la bonne information ?) appartient à un humain.
• La langue principale du site est bien définie. Un clic droit, « Inspecter », et vous devez trouver lang="fr" sur la balise <html> (critère 8.3). Sans cet attribut, les synthèses vocales lisent le français avec les règles de prononciation d'une autre langue. Côté scan : vérification entièrement automatique, présence et pertinence du code de langue comprises.
• Les liens sont explicites. « En savoir plus », « Cliquez ici » : ces libellés ne disent rien à une personne qui navigue de lien en lien avec un lecteur d'écran (critère 6.1). Côté scan : les libellés génériques se repèrent automatiquement ; juger si « Découvrir l'offre » suffit dans son contexte demande un regard humain.
• Le contenu reste lisible à 200 % de la taille de caractères. Six fois Ctrl et + dans votre navigateur : rien ne doit se superposer ni disparaître (critère 10.4). Côté scan : les unités de taille figées et les débordements à 320 px de large se détectent en partie ; le test de zoom complet se fait à la main.
• Les animations, clignotements et sons sont contrôlables. Un mouvement de plus de 5 secondes doit pouvoir être arrêté, un son de plus de 3 secondes coupé indépendamment du volume système (critère 13.8). Côté scan : les lectures automatiques et animations infinies laissent des traces détectables dans le code ; la contrôlabilité réelle se teste en conditions réelles.

---

Structuration de l'information : 4 vérifications

La troisième famille contrôle l'architecture invisible de la page, celle sur laquelle s'appuient les technologies d'assistance.

• L'intitulé de l'onglet est unique et pertinent. La balise <title> doit annoncer le contenu de la page, suivi du nom du site (critère 8.5). C'est ce que lisent les lecteurs d'écran à l'arrivée sur la page, et ce qui s'affiche dans les favoris comme dans les résultats de recherche. Côté scan : présence détectée automatiquement, pertinence affichée pour validation.
• La hiérarchie des titres est complète et cohérente. Au moins un titre de niveau 1, pas de saut de niveau, un arbre logique (critère 9.1). Lancez HeadingsMap et regardez l'arbre : s'il ne ressemble pas à un sommaire, il y a un problème. Côté scan : vérification entièrement automatique. Notre validateur de titres fait le même exercice en collant simplement votre HTML.
• Chaque champ de formulaire est associé à son intitulé, champs et formats obligatoires indiqués. Cliquez sur l'intitulé d'un champ : le curseur doit se positionner dans le champ. Les mentions obligatoires et les formats attendus doivent être annoncés, et chaque message d'erreur doit identifier le champ concerné (critère 11.1, critère 11.10). Côté scan : les étiquettes manquantes ou mal associées se détectent automatiquement, c'est même l'une des anomalies les plus fréquentes du web. La pertinence des intitulés et la qualité des messages d'erreur se jugent à la lecture.
• Les informations des fichiers en téléchargement sont indiquées. Format, poids, langue si elle diffère de la page : l'utilisateur doit savoir avant de cliquer si le téléchargement lui sera utile (critère 6.2). Côté scan : les liens de téléchargement sans mention de format ou de poids se repèrent en partie automatiquement.

---

Que peut-on vraiment automatiser dans le Diagnostic Flash ?

Posons la question franchement, parce qu'elle conditionne l'usage que vous ferez de votre temps. DesignGouv l'écrit noir sur blanc dans sa foire aux questions : environ 25 % des 250 tests du RGAA peuvent être évalués automatiquement, sans jamais couvrir un seul critère dans son intégralité.

Le Diagnostic Flash n'échappe pas à cette règle. Trois de ses points s'automatisent presque complètement (langue, hiérarchie des titres, titre d'onglet). La majorité s'automatise partiellement : la machine détecte les anomalies mécaniques, l'humain tranche la pertinence. Et quelques-uns résistent entièrement à l'automatisation, comme le test de zoom à 200 % ou l'accessibilité interne des documents bureautiques.

C'est exactement la philosophie de notre scanner : traiter en quelques secondes tout ce qui relève de la détection mécanique sur les 106 critères, signaler « à vérifier » ce qui demande un jugement, et ne jamais présenter une anomalie comme une non-conformité établie. Le scan défriche, l'audit humain tranche.

Si vous voulez comparer les approches outillées, nous avons passé en revue les outils d'évaluation de l'accessibilité et leurs périmètres respectifs.

---

Et après le Diagnostic Flash ?

Le Diagnostic Flash est un point de départ, pas une destination. DesignGouv propose une progression graduée : corriger ce que le diagnostic a révélé, former les équipes, puis passer à un audit rapide sur 25 critères de niveau A, un audit complémentaire, et enfin l'audit complet des 106 critères qui permet de publier une déclaration d'accessibilité.

Deux lectures pour préparer la suite : notre sélection d'outils d'audit RGAA détaille la marche vers l'audit complet, et notre checklist accessibilité prolonge les 15 points du Diagnostic Flash avec les vérifications techniques que DesignGouv réserve aux développeurs.

Un dernier conseil issu de la même équipe : ne commandez pas d'audit de conformité tant que les problèmes évidents ne sont pas corrigés. Comme le dit DesignGouv, aucun site n'a jamais été accessible par accident. L'audit constatera ce que vous savez déjà si le Diagnostic Flash est resté sans suite.

---

Conclusion

Les 15 points du Diagnostic Flash forment le socle minimal de l'accessibilité : perceptible, utilisable, compréhensible, et cela sans exiger la moindre expertise. Réalisez-le sur votre site cette semaine, notez ce qui bloque, corrigez dans l'ordre : clavier, contrastes, alternatives, formulaires.

Pour la partie mécanique, gagnez du temps : lancez un scan gratuit et obtenez en quelques secondes les détections automatiques sur les 106 critères du RGAA, avec pour chaque anomalie le critère concerné et la piste de correction.