Le pré-audit en trois repères
Périmètre ciblé
Jusqu’à 8 pages choisies ou découvertes sur le même domaine, analysées en desktop 1366×900 et en mobile 390×844.
Détection automatisée
axe-core dans Chromium, complété par un contrôle de visibilité du focus et un contrôle des cibles tactiles de 24×24 pixels.
Validation humaine
Une grille RGAA optionnelle et une checklist guident les vérifications que l’automatisation ne peut pas trancher.
01 — PÉRIMÈTRE
Comment les pages sont analysées
Le résultat décrit un instant précis, sur les pages et les états effectivement chargés pendant le scan.
- En mode ciblé, seules les URL fournies sont analysées. En mode découverte, Odeet utilise le sitemap et les liens internes de la page d’accueil, dans la limite de 8 pages du même domaine.
- Chaque URL est ouverte dans Chromium en deux contextes : desktop et mobile. Les redirections et le contenu rendu au moment du scan sont pris en compte.
- axe-core relève les violations détectables dans le DOM. Odeet ajoute les sélecteurs concernés, des extraits HTML, les messages d’échec et des recommandations de correction.
- Deux contrôles complémentaires alimentent le même rapport : visibilité détectable du focus au clavier sur desktop et taille minimale des cibles tactiles sur mobile.
- Une erreur HTTP, réseau ou de navigation reste attachée au contexte concerné afin de rendre visible un périmètre incomplet.
02 — SCORE TECHNIQUE
Une note de 0 à 100, où 100 est le meilleur signal
Le score sert à prioriser et à suivre une évolution sur un périmètre comparable. Il est calculé à partir des impacts fournis par axe-core et des contrôles complémentaires d’Odeet.
Pénalité par règle et par contexte
Critique
+4 par occurrence
Sérieux
+2 par occurrence
Modéré
+1 par occurrence
Mineur
+1 par occurrence
La première occurrence applique le poids principal. Jusqu’à 8 occurrences supplémentaires par règle et par contexte sont comptabilisées afin qu’un défaut répété pèse davantage sans écraser tout le score.
Niveaux de lecture
Calcul final
- 1Une pénalité est calculée séparément pour chaque couple page × viewport chargé avec succès.
- 2La pénalité globale est la moyenne de ces contextes réussis, arrondie et plafonnée à 100.
- 3Score = 100 − pénalité moyenne. Les pages supplémentaires ne font donc pas mécaniquement baisser la note si leur niveau de qualité est comparable.
Traitement des erreurs de scan
Lorsqu’au moins un contexte a réussi, les contextes en erreur sont signalés mais exclus de la moyenne : le score ne doit jamais être lu sans vérifier le nombre d’échecs. Si aucun contexte ne peut être analysé, le score est 0.
03 — RÉFÉRENTIELS
La détection automatique ne conclut jamais seule à la conformité
Odeet rapproche certains constats de références WCAG et d’une grille RGAA afin de préparer le travail d’un auditeur. Ce rapprochement est une aide à l’analyse, pas une certification.
- Lorsqu’une règle associée à un critère échoue, le critère peut être prérempli « non conforme » avec une source automatique.
- L’absence de violation ne produit jamais automatiquement un statut « conforme » : le critère reste à vérifier humainement.
- L’absence totale de cadres, médias, tableaux ou formulaires peut proposer les thématiques correspondantes en « non applicable ». Cette proposition doit être confirmée selon le périmètre réel.
- Une décision manuelle de l’auditeur prime toujours sur le préremplissage automatique.
- Le taux RGAA, lorsqu’il est utilisé, suit la formule critères conformes ÷ (conformes + non conformes). Il reste provisoire tant que des critères applicables ne sont pas testés.
La grille embarquée reprend les 106 critères du RGAA 4.1.2, version officielle actuellement en vigueur. Les errata 4.1.2 n’invalident pas les audits déjà réalisés.
04 — LIMITES
Ce qui exige encore une évaluation humaine
Une page peut obtenir un bon score tout en restant difficile ou impossible à utiliser pour certaines personnes.
- La pertinence d’une alternative textuelle, d’un intitulé, d’un ordre de lecture ou d’un message d’erreur.
- La navigation complète au clavier, les pièges de focus, les composants dynamiques et les parcours métier de bout en bout.
- L’expérience réelle avec les lecteurs d’écran, la commande vocale, le zoom, les préférences utilisateur et différentes technologies d’assistance.
- Les contenus derrière une authentification, un consentement, une interaction ou un état que le scénario automatisé n’a pas ouvert.
- La représentativité de l’échantillon, les dérogations, le champ légal applicable et la rédaction d’une déclaration d’accessibilité.
- La stabilité dans le temps : le rapport est une photographie datée et peut devenir obsolète après une modification du site.
05 — BONNE LECTURE
Comment utiliser le rapport sans surinterpréter le score
- 01
Contrôler le périmètre
Vérifier les URL, les deux viewports et les éventuelles pages en erreur avant toute comparaison.
- 02
Confirmer les constats
Reproduire les problèmes prioritaires et écarter les faux positifs dans le contexte réel du produit.
- 03
Tester les parcours
Compléter par des tests clavier, zoom et technologies d’assistance sur un échantillon représentatif.
- 04
Communiquer avec prudence
Présenter le score comme un indicateur de pré-audit. Réserver toute conclusion de conformité à un audit complet fondé sur le référentiel officiel à jour.
Un bon pré-audit commence par un périmètre clair.
Choisissez les pages utiles, analysez les erreurs du scan, puis transformez les constats confirmés en plan d’action.