Un scanner peut afficher 100/100 alors qu’un menu reste inutilisable au clavier. Il ne sait pas toujours si un texte alternatif décrit correctement une image, si l’ordre de lecture a du sens ou si le message d’erreur permet de récupérer.
À l’inverse, une seule erreur automatique répétée sur mille pages peut produire un volume impressionnant mais se corriger dans un composant.
L’audit doit donc mesurer deux choses : la conformité de l’échantillon et l’impact réel des barrières. Le premier sert la preuve réglementaire. Le second guide la remédiation.
1. Chiffres clés : les erreurs détectables restent massives en 2026
WebAIM a analysé en février 2026 les pages d’accueil d’un million de sites. 95,9 % présentaient au moins un échec WCAG détectable automatiquement, contre 94,8 % en 2025. L’absence d’erreur détectée ne prouve pas la conformité ; le taux réel de pages pleinement conformes était nécessairement inférieur à 4,1 % selon cette limite.
L’étude a détecté 56 114 377 erreurs, soit 56,1 par page en moyenne et +10,1 % sur un an. Les pages comportaient en moyenne 1 437 éléments, +22,5 % en un an et presque deux fois le niveau de 2019. La complexité augmente la surface de contrôle.
Six types représentaient 96 % des erreurs détectées : contraste insuffisant, alternatives d’images manquantes, labels de champs absents, liens vides, boutons vides et langue de document manquante. Le contraste faible apparaissait sur 83,9 % des pages, les alternatives manquantes sur 53,1 % et les labels absents sur 51 %.
Sur 66,6 millions d’images analysées, 16,2 % manquaient d’alternative, hors alt="". 10,8 % des images avec alternative avaient un texte douteux ou répétitif. Plus d’une image sur quatre présentait ainsi une alternative manquante, douteuse ou répétitive selon l’analyse.
Ces chiffres décrivent des pages d’accueil internationales et un outil donné. Une comparaison directe avec le RGAA de votre site serait invalide. Les résultats prouvent surtout que les contrôles automatisables ne sont pas encore des acquis.
Le contexte juridique s’est renforcé. L’European Accessibility Act est entré en application le 28 juin 2025 dans l’Union européenne pour des produits et services couverts, dont communications électroniques, banque, e-books, certaines fonctions de transport et commerce électronique. AccessibleEU rappelle que l’Union compte environ 100 millions de personnes handicapées parmi plus de 440 millions de citoyens.
2. Le cadre de référence : RGAA, WCAG et obligations
La version 4.1.2 du référentiel met à disposition 106 critères, des tests et une méthodologie. Elle est organisée en treize thématiques : images, cadres, couleurs, multimédia, tableaux, liens, scripts, éléments obligatoires, structuration, présentation, formulaires, navigation et consultation.
Les WCAG du W3C fournissent les principes et critères internationaux : perceptible, utilisable, compréhensible et robuste. Le RGAA opérationnalise la vérification dans le contexte français.
Le périmètre légal dépend de l’organisme, du service, des dates et du texte applicable. Secteur public, entreprises concernées par le droit français et services couverts par l’Accessibility Act peuvent avoir des obligations distinctes. Une analyse juridique confirme le cadre.
L’audit technique ne doit pas inventer l’applicabilité. Il documente le produit, la version du référentiel, le niveau, l’échantillon et les résultats. Les mentions légales, déclaration d’accessibilité, schéma pluriannuel et plan d’action sont examinés lorsqu’ils s’appliquent.
3. Étape 1 — Définir le périmètre
La lettre de mission décrit :
- domaines, applications, langues et versions ;
- interfaces authentifiées et publiques ;
- documents PDF et contenus tiers ;
- technologies et navigateurs ;
- référentiel et niveau ;
- objectif : conformité, pré-audit, suivi ou achat ;
- exclusions justifiées ;
- accès, comptes et données de test ;
- date et environnement.
Les contenus tiers ne disparaissent pas du parcours parce que l’équipe ne les développe pas. Paiement, prise de rendez-vous, carte, vidéo et authentification sont recensés. Le rapport distingue responsabilité et impact.
Une application mobile peut nécessiter des méthodes et tests adaptés. Les gestes, orientation, taille de cible, lecteur d’écran mobile et clavier externe sont inclus selon périmètre.
4. Étape 2 — Explorer le produit
Le W3C WCAG-EM structure l’évaluation en cinq étapes : définir le périmètre, explorer le produit, sélectionner un échantillon représentatif, évaluer et rapporter. Sa mise à jour 2026 souligne l’expertise nécessaire en standards, design/développement, technologies d’assistance et usages des personnes handicapées.
L’exploration inventorie templates, composants, technologies, contenus, processus, rôles et états. Un crawler trouve pages et variantes. Les analytics indiquent les parcours fréquents. Les équipes révèlent les fonctions critiques et cas rares.
On construit une matrice :
| Dimension | Exemples |
|---|---|
| Templates | accueil, liste, fiche, article, formulaire |
| Composants | menu, modale, onglet, carrousel, autocomplete |
| Processus | inscription, achat, paiement, demande, suppression |
| États | erreur, succès, vide, chargement, session expirée |
| Contenus | image, vidéo, audio, tableau, PDF |
| Contextes | mobile, zoom, contraste, clavier, lecteur d’écran |
L’exploration continue pendant l’audit. Une page peut révéler un composant non recensé.
5. Étape 3 — Construire un échantillon représentatif
Lorsque chaque page ne peut être auditée, l’échantillon combine sélection structurée et aléatoire, conformément à l’esprit de WCAG-EM.
La sélection structurée inclut :
- accueil et pages de niveau supérieur ;
- chaque template ;
- chaque technologie essentielle ;
- fonctions critiques ;
- pages à fort trafic ;
- pages sensibles ou réglementaires ;
- documents et médias ;
- états d’erreur ;
- pages signalées par utilisateurs.
Les processus complets sont inclus. Si une page du checkout est choisie, toutes les étapes nécessaires à l’achat sont testées. Une conformité page par page ne suffit pas si le processus casse.
Une sélection aléatoire complète pour éviter que l’équipe ne présente uniquement ses meilleurs écrans. La méthode, le nombre et les URLs sont publiés.
Les composants partagés sont signalés. Un défaut du header affecte tout l’échantillon, mais sa correction peut être centralisée.
6. Étape 4 — Préparer l’environnement de test
L’audit documente systèmes, navigateurs et technologies d’assistance. Par exemple : Windows avec NVDA et Firefox/Chrome, macOS avec VoiceOver et Safari, iOS avec VoiceOver, Android avec TalkBack, selon les usages et le référentiel.
Les versions sont notées. Aucun couple ne représente tous les utilisateurs. L’objectif est une couverture cohérente des technologies supportées.
Les paramètres incluent zoom 200 % et 400 %, taille de texte, contraste forcé, mode sombre, réduction de mouvement, orientation et reflow. Le clavier est testé sans souris.
Les outils automatiques — axe, WAVE, Lighthouse ou autres — accélèrent le dépistage. Aucun ne prononce la conformité. Les résultats sont confirmés manuellement et dédupliqués.
Les données de test évitent d’exposer de vraies personnes. Les actions destructives sont réalisées dans un environnement contrôlé.
7. Étape 5 — Tester les treize thèmes
7.1. Images
Chaque image informative possèd'une alternative pertinente. Une image décorative est ignorée correctement. Une image complexe possèd'une description adaptée. Le test juge le sens dans le contexte, ce qu’un automate ne peut conclure seul.
7.2. Cadres
Les cadres ont un titre permettant d’identifier leur contenu. Les intégrations ne créent pas de piège clavier ni de rupture de contexte.
7.3. Couleurs
L’information ne dépend pas uniquement de la couleur. Les contrastes texte/fond, composants et états sont mesurés. Les variations au survol, focus, erreur et désactivation sont incluses.
7.4. Multimédia
Les vidéos disposent de sous-titres, transcription et audiodescription ou alternative selon le besoin. Le lecteur est contrôlable au clavier, ses boutons nommés et l’autoplay maîtrisé.
7.5. Tableaux
Les tableaux de données ont titres, en-têtes et associations. Ils ne sont pas utilisés pour la mise en page. Les tableaux complexes sont simplifiés ou correctement reliés.
7.6. Liens
L’intitulé et le contexte permettent de comprendre la destination. Les liens images ont un nom. Les nouvelles fenêtres sont signalées lorsque nécessaire.
7.7. Scripts
Les composants interactifs ont rôles, noms, valeurs et états. Les messages dynamiques sont annoncés. Le focus est géré dans les modales, menus, onglets et applications.
7.8. Éléments obligatoires
Titre de page, langue, changement de langue, validité et balises structurantes sont contrôlés. Le titre doit distinguer l’étape ou l’erreur.
7.9. Structuration
Les headings reflètent la hiérarchie. Listes, citations et landmarks utilisent la sémantique. L’ordre DOM correspond à une lecture logique.
7.10. Présentation
Le contenu reste disponible sans CSS lorsque le test l’exige, le focus est visible, le zoom et reflow fonctionnent, les espacements peuvent être modifiés, le mouvement respecté et les contenus cachés correctement.
7.11. Formulaires
Chaque champ a un label, les groupes sont identifiés, les instructions arrivent avant besoin, les erreurs sont décrites et reliées, l’autocomplétion s’applique et la correction est possible. Les champs obligatoires sont signalés autrement que par couleur.
7.12. Navigation
Des moyens permettent d’éviter les blocs, de retrouver les pages et de conserver un ordre cohérent. Le clavier accède à tout sans piège. Le plan et la recherche sont évalués selon le produit.
7.13. Consultation
Les délais sont contrôlables, ouvertures de fenêtre maîtrisées, documents accessibles, contenus clignotants évités et gestes complexes disposent d’alternatives.
8. Étape 6 — Tester les parcours avec des personnes
Le W3C recommande d’impliquer des utilisateurs en situation de handicap pour comprendre l’expérience réelle. Les tests utilisateurs ne remplacent pas l’audit de conformité ; ils révèlent impact, stratégies et priorités.
Le recrutement couvre plusieurs profils selon le produit : aveugle lecteur d’écran, malvoyant zoom, mobilité clavier ou commande vocale, surdité, troubles cognitifs, dyslexie. Une personne ne représente pas tout un handicap.
Les tâches sont réalistes : trouver un service, comparer, créer un compte, corriger une erreur, payer, télécharger un document, contacter l’assistance. L’équipe observe réussite, temps, assistance, erreurs et verbatims.
La participation est rémunérée, les besoins d’aménagement demandés et les données minimisées. L’environnement de test lui-même doit être accessible.
Une non-conformité peut être peu visible dans ce petit panel. Une barrière majeure observée par une personne reste importante même sans fréquence statistique.
9. Calculer la conformité sans masquer les barrières
Le RGAA définit la méthode de calcul applicable. Le rapport publie les critères conformes, non conformes, non applicables et non testés, avec justifications.
Un pourcentage global ne suffit pas. Deux sites à 80 % peuvent différer : l’un a des contrastes répétés, l’autre empêche totalement le paiement au clavier.
Logiks ajoute un score d’impact, séparé de la conformité.
Bloquant. Impossible d’accomplir un processus sans assistance.
Majeur. Forte difficulté, erreur ou perte d’information importante.
Modéré. Contournement possible avec effort significatif.
Mineur. Gêne limitée ou incohérence.
L’impact tient compte du nombre de pages, du parcours, de la fréquence et des profils. Il ne modifie pas le résultat réglementaire.
Chaque constat cite critère, page, composant, étape, technologie, reproduction, capture, code utile et proposition. La preuve permet au développeur de vérifier.
10. Analyser les causes racines
Les défauts sont regroupés par origine.
Design system. Contrastes, focus, composants, états et tokens.
Bibliothèque technique. Modale, select, date picker ou routing.
CMS. Champs d’alternative, headings, tableaux, éditeur.
Contenu. textes, médias, documents et langue.
Processus. validation, délais, support et tiers.
Gouvernance. absence de critères d’acceptation, compétence ou test.
Corriger une occurrence sans le composant crée des rechutes. L’audit estime la portée : nombre de templates, contenus et équipes.
Le backlog distingue correction immédiate, refonte composant, migration de contenu et dette fournisseur.
11. Prioriser la remédiation
L’ordre combine blocage utilisateur, obligation, fréquence, portée, dépendance et effort.
48 heures. Contenus dangereux, paiement ou contact impossible, focus piégé, médias sans information essentielle, déclaration manifestement fausse.
30 jours. Navigation, formulaires critiques, contrastes globaux, noms accessibles, structure et documents prioritaires.
90 jours. Design system, composants complexes, CMS, templates et automatisation de tests.
12 mois. reprise des archives, fournisseurs, formation, gouvernance et amélioration continue.
Chaque ticket possède critère d’acceptation et contre-test. « Ajouter ARIA » n’est pas une solution générique. Le HTML natif est souvent plus robuste.
Les corrections sont testées avec clavier, outil automatique et technologie d’assistance pertinente. Une modification de focus peut résoudre un critère et en casser un autre.
12. Intégrer l’accessibilité au cycle produit
La remédiation ponctuelle ne suffit pas. Le pipeline ajoute :
- critères d’accessibilité dans les user stories ;
- revue design avant développement ;
- composants accessibles documentés ;
- linting et tests automatiques ;
- tests clavier et lecteur d’écran en recette ;
- contrôle des contenus CMS ;
- clause fournisseur ;
- revue manuelle périodique ;
- canal de signalement accessible.
Les tests automatiques bloquent les régressions qu’ils savent détecter : label absent, contraste statique, rôle invalide. Ils ne remplacent pas la navigation complète.
La définition of done inclut zoom, focus, erreur, nom et sémantique. Les équipes reçoivent des exemples liés à leur rôle.
Le responsable accessibilité suit la feuille de route. Il ne devient pas le seul à corriger.
13. Cas pratique : 96/100 automatique, checkout impossible
Un site marchand affiche 96 sur l’audit automatique. Le test clavier montre que le sélecteur de point relais ne peut pas être ouvert. Le lecteur d’écran n’entend pas les erreurs de carte. La session expire sans avertissement.
L’échantillon comprend tout le processus. Trois critères automatiques sont en défaut, mais neuf échecs manuels affectent le checkout. Le taux global reste élevé ; l’impact est bloquant.
La cause principale est une bibliothèque de composants. L’équipe remplace le select par un combobox conforme, relie les erreurs, annonce la mise à jour et ajoute une prolongation de session.
Les tests couvrent NVDA, VoiceOver, clavier et mobile. Deux utilisateurs réalisent ensuite l’achat. Le composant rejoint le design system et un test de régression.
La déclaration est mise à jour après contre-audit, pas avant.
14. Livrables attendus
- périmètre, référentiel et technologies ;
- exploration et échantillon justifié ;
- tableau des 106 critères applicables ;
- constats avec preuves et reproduction ;
- taux de conformité et impact séparé ;
- carte des causes racines et composants ;
- backlog priorisé avec critères d’acceptation ;
- contre-audit des corrections ;
- aide à la déclaration d’accessibilité selon cadre ;
- plan de gouvernance, formation et tests continus.
Le livrable lui-même est accessible : structure, tableaux, contrastes, alternatives et format exploitable.
15. Questions fréquentes
15.1. Un score Lighthouse prouve-t-il la conformité RGAA ?
Non. Il couvre une partie automatisable sur une page. Le RGAA exige des tests manuels, un échantillon, des processus et une méthodologie.
15.2. Combien de pages faut-il auditer ?
Assez pour représenter templates, technologies, contenus, fonctions et parcours complets, plus une part aléatoire. Le nombre dépend du produit. La méthode est plus importante qu’un quota fixe.
15.3. Peut-on déclarer 100 % avec des contenus tiers non conformes ?
La réponse dépend du périmètre et des règles applicables. Les exclusions doivent être justifiées, mais l’impact utilisateur reste à traiter avec fournisseur ou alternative. Un conseil juridique confirme la déclaration.
15.4. Les tests utilisateurs remplacent-ils le RGAA ?
Non. Ils complètent la conformité en montrant l’expérience. Une personne peut réussir malgré un échec, ou rencontrer une barrière non couverte par un outil.
15.5. Quand refaire l’audit ?
Après refonte ou changement majeur, puis selon le cycle légal et le risque. Un contrôle annuel et des tests continus réduisent les régressions.
16. Ce que peut prouver le clavier face aux composants non conformes
La correction s’effectue d’abord au niveau le plus réutilisé. Un champ corrigé dans le design system peut résoudre des dizaines d’occurrences ; une surcharge locale laisse la cause active.
Le ticket indique critère, page, composant, étape de reproduction, impact, code concerné et résultat attendu. Une capture d’écran seule ne documente ni le focus, ni l’annonce du lecteur d’écran.
Après livraison, une personne différente refait le test avec le même environnement, puis sur plusieurs occurrences. Elle vérifie aussi les régressions : ordre, zoom, reflow, nom accessible, messages, contraste et état.
Lorsqu’un composant de sélection est annoncé comme corrigé, la recette doit démontrer que l’on peut l’atteindre, l’ouvrir, parcourir ses options, connaître la sélection, valider, annuler, revenir au déclencheur, comprendre les erreurs et accomplir le parcours avec un lecteur d’écran sur les combinaisons retenues ; cette séquence vaut davantage qu’un attribut ajouté, car elle vérifie l’interaction entière et pas seulement la présence d’un rôle.
Les critères non applicables sont justifiés. Les dérogations éventuelles suivent le cadre juridique et ne deviennent pas une catégorie de confort. Les contenus tiers restent recensés, avec responsabilité et alternative lorsque nécessaire.
Le plan de prévention ajoute tests automatisés, checklist éditoriale, revue de conception et échantillon humain. Les automates bloquent les erreurs connues ; le contrôle manuel conserve le sens.
Au prochain audit, l’équipe compare récidive par composant, ancienneté, sévérité et parcours. Une hausse ponctuelle peut provenir d’un périmètre plus large ; le rapport explique le dénominateur plutôt que de célébrer ou dramatiser un score isolé.
Le dossier de clôture joint pour chaque correction critique la preuve avant, la version, le contre-test, les technologies utilisées et les limites restantes, puis une personne qui n’a pas produit le correctif refait le parcours complet ; cette indépendance légère réduit le risque qu’un développeur confirme son propre changement sur le seul cas qu’il connaît, tandis qu’une autre occurrence, une langue ou un état d’erreur demeure bloquant.
La preuve reste datée et reproductible.
17. Ce que Logiks recommande
Définissez l’échantillon avant de calculer un score, incluez les processus complets et confirmez les outils par des tests manuels. Priorisez selon l’impact, corrigez les composants racines et contre-testez. L’accessibilité ne se prouve pas par l’absence d’alertes : elle se démontre par la capacité de personnes différentes à accomplir les mêmes actions.
18. Sources principales
- DINUM, RGAA 4.1.2, 106 critères et méthode technique : https://accessibilite.numerique.gouv.fr/
- DINUM, PDF du RGAA 4.1.2 : https://accessibilite.numerique.gouv.fr/doc/RGAA-v4.1.2.pdf
- W3C WAI, WCAG-EM Overview, mise à jour février 2026 : https://www.w3.org/WAI/test-evaluate/conformance/wcag-em/
- W3C, WCAG-EM 2.0 : https://www.w3.org/TR/wcag-em-2/
- WebAIM, The WebAIM Million 2026 : https://webaim.org/projects/million/
- Commission européenne, entrée en application de l’European Accessibility Act : https://digital-strategy.ec.europa.eu/en/news/eu-becomes-more-accessible-all
- AccessibleEU, EAA et services couverts : https://accessible-eu-centre.ec.europa.eu/content-corner/news/new-era-inclusion-begins-eaa-enters-force-2025-06-27_en