L’accessibilité numérique consiste à rendre un site utilisable par toutes les personnes, y compris celles qui naviguent au clavier, avec un lecteur d’écran, une loupe, une commande vocale ou un dispositif de pointage adapté. En France, la méthode officielle pour la vérifier s’appelle le RGAA, le Référentiel général d’amélioration de l’accessibilité, édité par la Direction interministérielle du numérique. Sa version en vigueur est le RGAA 4.1.2.
Cette exigence n’a rien de neuf : l’obligation légale date de l’article 47 de la loi du 11 février 2005. Ce qui a changé, c’est qu’elle est désormais contrôlée et sanctionnée. La DINUM rappelle que 12 à 15 millions de personnes sont en situation de handicap en France, et l’Arcom a publié le 24 juin 2026 sa première mise en demeure visant un service de l’État. Dans le même temps, une nouvelle version du référentiel est annoncée pour fin 2026, ce qui pousse beaucoup d’organisations à se demander s’il faut agir maintenant ou attendre.
Nous abordons ce sujet du point de vue qui est le nôtre, celui de la qualité d’un front-end. L’accessibilité n’est pas une discipline séparée qu’on ajoute en fin de projet : c’est une composante de la qualité web, au même titre que le temps de chargement ou la sécurité, et c’est le cadre dans lequel s’inscrit la certification Opquast qui structure notre méthode de travail. Reste à savoir ce que le RGAA exige exactement, qui doit s’y conformer, et ce qu’une conformité réelle demande au-delà d’un bon score d’outil ?
Qu’est-ce que l’accessibilité numérique ?
L’accessibilité numérique désigne la capacité d’un service en ligne à être perçu, compris et utilisé par tous, quelles que soient les capacités sensorielles, motrices ou cognitives de la personne. Elle concerne les situations de handicap permanentes, mais aussi les situations temporaires ou contextuelles : un bras plâtré, une luminosité écrasante en extérieur, un environnement bruyant qui rend une vidéo inaudible sans sous-titres.
Le périmètre légal est large. L’article 47 de la loi de 2005 vise l’accès à tout type d’information sous forme numérique, quels que soient le moyen d’accès et le mode de consultation : sites internet, intranets, extranets, applications mobiles, progiciels, et jusqu’au mobilier urbain numérique pour sa partie interactive.
Quels sont les 4 principes de l’accessibilité numérique ?
Les quatre principes fondateurs viennent des WCAG du W3C et structurent tout le reste, RGAA compris. Ils se retiennent sous l’acronyme POUR, et chacun répond à une question différente sur ce qu’un contenu doit permettre.
- Perceptible : l’information doit pouvoir être reçue par au moins un sens disponible. Une image porte une alternative textuelle, une vidéo des sous-titres, un texte un contraste suffisant pour être lu ;
- Utilisable : l’interface doit pouvoir être manipulée autrement qu’à la souris. Tout doit être atteignable au clavier, sans piège au focus, avec assez de temps pour agir ;
- Compréhensible : le contenu et le fonctionnement doivent être prévisibles. La langue est déclarée, les erreurs de formulaire sont expliquées, la navigation reste cohérente d’une page à l’autre ;
- Robuste : le code doit être suffisamment valide et sémantique pour que les technologies d’assistance présentes et futures l’interprètent correctement.
Ces quatre principes se déclinent ensuite en critères de succès, puis en critères de contrôle nationaux. C’est cet empilement qu’il faut comprendre pour savoir ce que le RGAA ajoute réellement.
Qu’est-ce que la norme RGAA et que contient-elle ?
Le RGAA est le référentiel technique français qui rend vérifiable l’obligation d’accessibilité. Édité par la DINUM et rendu opposable par l’arrêté du 20 septembre 2019, il comporte 13 thématiques et 106 critères de contrôle, avec une moyenne de 2,5 tests par critère selon la méthode technique publiée sur accessibilite.numerique.gouv.fr.
Les 13 thématiques couvrent les images, les cadres, les couleurs, le multimédia, les tableaux, les liens, les scripts, les éléments obligatoires, la structuration de l’information, la présentation, les formulaires, la navigation et les consultations. Chaque critère est formulé de façon à réduire la marge d’interprétation, et de nombreux tests renvoient à des techniques d’implémentation précises en HTML, CSS ou JavaScript.
Une confusion mérite d’être levée tout de suite, parce qu’elle fausse ensuite tout le raisonnement. Le RGAA n’est pas une liste de bonnes intentions : c’est une procédure de test qui produit un résultat chiffré. On ne se déclare pas conforme au RGAA, on mesure un taux de conformité en passant chaque critère applicable sur un échantillon de pages.
Quelle différence entre le RGAA et les WCAG ?
Les WCAG et le RGAA ne sont pas deux normes concurrentes, mais deux étages du même édifice. Les WCAG 2.1 du W3C définissent ce qu’un contenu accessible doit être, sous forme de critères de succès classés en niveaux A, AA et AAA. Le RGAA définit comment le vérifier en France, critère par critère et test par test.
Entre les deux se glisse une couche européenne. La norme harmonisée EN 301 549 retient 50 critères de succès des niveaux A et AA des WCAG 2.1 pour fixer le niveau d’exigence légale, et c’est à elle que renvoie le décret français. Le RGAA décline ces 50 critères de succès en 106 critères de contrôle opérationnels.
Cette architecture a une conséquence pratique que l’Arcom souligne explicitement : c’est la norme européenne qui s’impose juridiquement, pas le référentiel. Si le RGAA reste silencieux sur un point présent dans l’EN 301 549, comme le principe de non-interférence, l’obligation demeure. Le référentiel est une méthode de contrôle, pas le périmètre de l’exigence.
Qui est concerné par le RGAA ?
Trois catégories d’organismes relèvent de l’article 47 de la loi de 2005, et le périmètre s’est considérablement élargi depuis. L’Arcom les énumère sur sa page dédiée, et le seuil applicable aux entreprises privées mérite d’être lu de près.
- Les personnes morales de droit public : État, collectivités territoriales, établissements publics, fonction publique hospitalière ;
- Les personnes morales de droit privé délégataires d’une mission de service public ;
- Les entreprises dont le chiffre d’affaires dépasse un seuil fixé par décret, actuellement 250 millions d’euros, calculé sur la moyenne des trois derniers exercices clos et sur le seul chiffre d’affaires réalisé en France.
Un détail compte pour les groupes, et il est régulièrement mal interprété. Le chiffre d’affaires de référence n’est pas le consolidé du groupe, mais celui de la société désignée responsable du service dans les mentions légales du site. Une filiale française d’un groupe international s’apprécie donc sur son propre volume d’activité.
Ce que l’European Accessibility Act a changé depuis le 28 juin 2025
La directive (UE) 2019/882, dite European Accessibility Act, a ouvert un second régime d’obligations qui vise cette fois des secteurs d’activité plutôt que des tailles d’organisation. Transposée en droit français par la loi n° 2023-171 du 9 mars 2023, le décret n° 2023-931 et l’arrêté du 9 octobre 2023, elle s’applique aux produits mis sur le marché et aux services fournis depuis le 28 juin 2025.
Le périmètre couvre le commerce électronique, les services bancaires aux consommateurs, les transports de voyageurs, les médias audiovisuels, la téléphonie et le livre numérique, ainsi que le matériel associé. La fiche pratique de la DGCCRF détaille les catégories concernées.
Une exemption limite toutefois la portée du dispositif pour les plus petites structures. Les entreprises de moins de 10 salariés dont le chiffre d’affaires reste sous 2 millions d’euros échappent à l’obligation pour les services, tout comme les cas où la mise en accessibilité modifierait fondamentalement la nature du produit ou représenterait une charge disproportionnée.
Le changement d’échelle est considérable. Un site de commerce en ligne de taille moyenne, qui n’était concerné par aucune obligation avant juin 2025, l’est désormais pleinement, et sous le contrôle d’une autorité qui a déjà commencé ses enquêtes.
Quelles sont les obligations d’accessibilité à publier ?
Au-delà de l’état technique du site, la loi impose quatre livrables distincts, que les organisations confondent régulièrement. Ils ne se remplacent pas et chacun peut être constaté en manquement séparément, indépendamment de la qualité réelle du code.
- La mention de conformité en page d’accueil, clairement visible, indiquant si le service est totalement conforme, partiellement conforme ou non conforme ;
- La déclaration d’accessibilité, au format imposé par le point 1.6.1 du RGAA, adossée à un audit réel et accessible directement depuis le service ;
- Le schéma pluriannuel de mise en accessibilité, dont la durée ne peut excéder trois ans, rendu public ;
- Le plan d’actions de l’année en cours, qui décline ce schéma et doit être actualisé chaque année.
Un cinquième élément s’ajoute sans être un document : le service doit permettre facilement à l’usager de signaler un manquement aux règles d’accessibilité, et la déclaration doit porter un contact à cet effet. C’est par ce canal que remontent la plupart des signalements associatifs qui déclenchent ensuite un contrôle.
Que doit contenir une déclaration d’accessibilité ?
La déclaration n’est pas un texte libre. Le point 1.6.1 du RGAA en fixe le format obligatoire, rubrique par rubrique, et impose que l’état de conformité résulte d’une évaluation effective, c’est-à-dire d’un audit mené selon la méthodologie officielle. Trois mentions seulement sont admises, et leurs seuils ne se choisissent pas.
| Mention à afficher | Condition | Ce qu’elle suppose |
|---|---|---|
| Conformité totale | Tous les critères de contrôle applicables sont respectés | Un audit complet, sans aucune non-conformité résiduelle |
| Conformité partielle | Au moins 50 % des critères sont respectés | Un audit complet et la liste publiée des contenus non accessibles |
| Non-conformité | Moins de 50 % des critères, ou aucun audit en cours de validité | C’est la mention par défaut tant qu’aucun audit n’a été mené |
La troisième ligne est celle que la plupart des organisations devraient afficher, et c’est celle qu’on voit le moins. Une déclaration publiée sans audit sous-jacent ne vaut pas conformité partielle : elle relève de la non-conformité, et annoncer autre chose constitue en soi un manquement.
La déclaration a par ailleurs une durée de vie. Le point 1.6.2 impose sa mise à jour lors d’une refonte ou d’une modification substantielle du site, trois ans après sa publication, ou dix-huit mois après la parution d’une nouvelle version du référentiel pour ceux qui appliquent la méthode technique.
Qui contrôle le RGAA et quelles sanctions sont encourues ?
Le contrôle est réparti entre plusieurs autorités selon la nature du service, et cette répartition explique pourquoi une même entreprise peut relever de deux régimes différents. L’ordonnance n° 2023-859 du 6 septembre 2023 a créé l’article 47-1 de la loi de 2005, qui confie à l’Arcom la surveillance des services numériques publics.
| Autorité | Périmètre de contrôle | Fondement |
|---|---|---|
| Arcom | Services numériques des organismes publics et délégataires, obligations d’affichage pour les grandes entreprises | Article 47-1 de la loi de 2005 |
| DGCCRF | Commerce électronique et produits grand public | Code de la consommation, European Accessibility Act |
| ACPR | Services bancaires aux consommateurs | European Accessibility Act |
| Arcep | Services de communications électroniques | European Accessibility Act |
Les montants encourus au titre de l’article 47-1 sont explicites. L’Arcom peut prononcer une sanction pécuniaire d’un maximum de 50 000 € pour le non-respect des exigences d’accessibilité et de 25 000 € pour les autres obligations, modulables selon la nature, la gravité et la durée du manquement. La procédure passe d’abord par une mise en demeure, qui est rendue publique.
Côté DGCCRF, le régime relève du code de la consommation et la mécanique diffère nettement. Les manquements y sont des contraventions de 5e classe, soit 7 500 € d’amende, cumulables selon le nombre d’infractions, et les agents peuvent enjoindre la mise en conformité sous astreinte, avec publication de la mesure.
L’autorité a par ailleurs ouvert un parcours dédié sur la plateforme SignalConso, permettant aux consommateurs de signaler directement un défaut d’accessibilité. Son enquête porte sur les sites de commerce en ligne et sur la loyauté des prestataires qui réalisent ces audits, ce qui vise implicitement les offres de conformité express.
La nuance qui change tout pour les entreprises privées
Un point juridique distingue un contenu sérieux d’une reprise approximative, et il est rarement énoncé. Pour les entreprises assujetties au seul titre de leur chiffre d’affaires, l’Arcom n’est compétente que sur les obligations d’affichage. Elle le dit noir sur blanc : elle ne peut pas intervenir auprès de cette catégorie d’acteurs sur le fondement d’une non-conformité aux exigences d’accessibilité.
La raison est historique. La directive européenne de 2016 ne visait que le secteur public, et l’assujettissement des grandes entreprises privées est une sur-transposition nationale dont le régime de contrôle n’a pas suivi. Une entreprise privée de plus de 250 millions d’euros de chiffre d’affaires peut donc être sanctionnée pour une déclaration absente ou mensongère, mais pas, par cette voie, pour un site techniquement inaccessible.
Cette asymétrie ne doit pas être lue comme une permission. Elle signifie simplement que le risque réglementaire immédiat, pour beaucoup d’organisations, porte d’abord sur des documents, et que ces documents sont la partie la moins coûteuse à mettre en ordre.
Ce que la première mise en demeure de l’Arcom enseigne
Le 24 juin 2026, l’Arcom a mis en demeure le Ministère de l’Action et des Comptes publics au sujet du site impots.gouv.fr. C’est la première décision publique de ce type visant un service de l’État, et le texte intégral de la décision est bien plus instructif que le communiqué qui l’accompagne. Dix manquements y sont retenus, sur la base de procès-verbaux dressés les 30 avril et 2 juin 2026.
Quatre relèvent des exigences techniques : un avis d’impôt téléchargeable en PDF sans titre, sans langue définie ni balises de structuration, et sans alternative accessible, en infraction au critère 13.3 ; une messagerie sécurisée dont la rubrique d’écriture est inatteignable à la tabulation, contraire au critère 10.8 ; un menu de sélection de l’année d’imposition qui ne s’ouvre qu’à la souris, contraire au critère 12.11 ; et un tableau du formulaire de déclaration dont les cellules ne sont pas associées à leurs en-têtes, contraire au critère 5.7.
Les six autres ne concernent pas le code du site. Cinq portent sur les déclarations d’accessibilité et un sur le plan d’actions, publié pour l’année 2024 alors qu’il doit couvrir l’année en cours. Une déclaration datée du 16 janvier 2023 n’avait jamais été mise à jour, deux autres ne respectaient pas le format imposé, avec des rubriques mal ordonnées et des titres renommés ou absents.
Le manquement le plus parlant tient en une ligne. La déclaration du service Biens immobiliers affichait un taux de conformité de 42,11 % tout en annonçant une conformité totale au RGAA. Sous le seuil de 50 %, le référentiel impose la mention de non-conformité. Une quatrième déclaration ne mentionnait aucun taux, faute d’audit.
Les délais accordés achèvent de dessiner la hiérarchie des priorités. L’Arcom laisse neuf mois pour corriger les manquements techniques, mais seulement deux mois pour les obligations déclaratives et le plan d’actions. La leçon est contre-intuitive et mérite d’être formulée sans détour : une déclaration inexacte est un manquement autonome, indépendant de l’état réel du site, et c’est la première cause de sanction. C’est aussi, de loin, le point le plus rapide à corriger.
Que change le RGAA 5 et faut-il attendre sa publication ?
Non, il ne faut pas attendre, et la DINUM le dit elle-même. Dans son annonce du 4 mars 2026, elle place cette consigne avant toute description des évolutions à venir, ce qui en dit long sur la fréquence de la question : les travaux fondés sur le RGAA 4.1.2 gardent toute leur pertinence et ne doivent pas être suspendus.
Les travaux en cours ou à venir sur la base du RGAA 4.1.2 actuellement en vigueur gardent toute leur pertinence et ne doivent en aucun cas être suspendus ou reportés.
Direction interministérielle du numérique, annonce de la nouvelle version du RGAA, 4 mars 2026
L’argument technique suit l’argument institutionnel. Les critères du RGAA 5 viendront préciser ou compléter ceux du 4.1.2, sans les réfuter : un site conforme aujourd’hui restera en bonne position demain. Le travail engagé n’est donc pas menacé d’obsolescence, il constitue au contraire la base sur laquelle les nouveaux critères s’ajouteront.
Les évolutions annoncées portent sur deux volets. Côté obligations légales, l’Arcom est désignée autorité de contrôle et un téléservice de dépôt et de publication des déclarations sera mis en place, ce qui rendra la conformité traçable et vérifiable depuis un point unique. Côté méthode technique, le référentiel intégrera les WCAG 2.2, définira des critères et des tests pour les applications mobiles et les documents bureautiques, et reformulera certains critères pour les simplifier.
Le passage aux WCAG 2.2 ajoutera des exigences que les interfaces contemporaines ignorent largement : taille minimale des cibles tactiles, alternative aux gestes de glissement, et surtout une authentification qui ne repose pas sur un test cognitif comme la mémorisation d’un mot de passe recopié. Ces trois points touchent des composants que presque tous les sites possèdent.
Reste la question calendaire, qui a une réponse chiffrée. Les déclarations publiées avant la parution du RGAA 5 restent valables dix-huit mois, dans la limite des trois ans à compter de leur date de publication. Publier une déclaration maintenant n’est donc pas un travail perdu : c’est un délai gagné.
Votre site est-il aussi rapide que vos visiteurs l’espèrent ?
Un score Lighthouse de 100 signifie-t-il que le site est conforme au RGAA ?
Non, et l’écart entre les deux est considérable. Un score de 100 sur le volet accessibilité de Lighthouse signifie que l’outil n’a détecté aucun défaut parmi ceux qu’il sait détecter, ce qui est une information utile mais très partielle. WebAIM, éditeur de l’outil WAVE, le formule sans ambiguïté dans la méthodologie de son étude annuelle : l’absence d’erreurs détectées n’indique pas qu’une page est accessible ou conforme.
La raison tient à la nature des critères. Une machine vérifie très bien la présence d’un attribut, la valeur d’un contraste ou la validité d’un rôle ARIA. Elle est structurellement incapable de juger si une alternative textuelle décrit correctement l’image, si l’ordre de tabulation suit la logique visuelle, ou si un parcours de commande entier reste réalisable sans souris.
L’ordre de grandeur est documenté. WebAIM indique que WAVE détecte environ un quart des erreurs WCAG 2 possibles, et sa enquête auprès des praticiens de l’accessibilité montre que seuls 17,6 % d’entre eux estiment qu’au moins la moitié des problèmes est détectable automatiquement. Autrement dit, la majorité des critères RGAA se vérifie à la main, par un audit mené selon la méthodologie officielle.
Nous utilisons Lighthouse au quotidien pour le suivi des sites, et les rapports que nous produisons comportent un volet accessibilité aux côtés du volet performance, relevé en continu. C’est précisément cet usage régulier qui rend la limite visible : un site peut passer de 78 à 100 sur ce score en une après-midi de corrections mécaniques, sans que sa conformité RGAA ait bougé d’un point. Les deux mesures répondent à des questions différentes, et nous détaillons ce que chaque outil mesure réellement dans notre comparaison de PageSpeed Insights et Lighthouse.
Quels outils utiliser pour tester l’accessibilité de son site ?
L’outillage se répartit en trois familles qui ne se substituent pas les unes aux autres, et l’erreur classique consiste à s’arrêter à la première. Les extensions automatiques dégrossissent, les outils d’audit structurent la démarche officielle, les technologies d’assistance confrontent le résultat à l’usage réel.
- Ara, l’outil d’audit officiel de la DINUM, guide la passation des critères RGAA et produit un rapport ainsi qu’un taux de conformité exploitable pour la déclaration ;
- Assistant RGAA, extension de navigateur, met en évidence les éléments à vérifier critère par critère et accélère considérablement la partie manuelle ;
- axe DevTools et WAVE, extensions d’audit automatisé, repèrent en quelques secondes les défauts syntaxiques les plus courants ;
- Lighthouse, intégré aux outils de développement de Chrome, surveille les régressions dans le temps mais ne couvre qu’une fraction des critères ;
- NVDA, JAWS et VoiceOver, lecteurs d’écran, restituent la page telle qu’elle est réellement perçue par une partie des utilisateurs.
La démarche efficace enchaîne ces familles dans l’ordre. On passe d’abord un outil automatique pour éliminer le bruit, puis on mène l’audit RGAA sur un échantillon de pages représentatif du site, et on vérifie enfin les parcours critiques au clavier et au lecteur d’écran. Sauter la dernière étape revient à valider une conformité qu’aucun utilisateur ne constatera.
Faut-il tester avec un lecteur d’écran, et lequel ?
Oui, au moins sur les parcours qui comptent : formulaire de contact, tunnel de commande, espace personnel. Sur Windows, NVDA est gratuit et couvre l’essentiel des besoins de test ; sur macOS et iOS, VoiceOver est intégré au système. JAWS reste très répandu en environnement professionnel mais son coût le réserve aux audits approfondis.
Une précaution s’impose sur l’interprétation de ces tests. Savoir manipuler un lecteur d’écran demande de l’apprentissage, et un développeur qui découvre l’outil produira souvent un diagnostic pessimiste, faute de connaître les raccourcis que les utilisateurs quotidiens emploient. Le test sert à repérer les blocages francs, pas à juger du confort d’usage.
Ce qu’il révèle en quelques minutes reste néanmoins précieux : un bouton annoncé comme bouton sans plus de précision, une modale qui ne prend pas le focus, un message de confirmation invisible pour la synthèse vocale. Aucun de ces trois défauts n’apparaît dans un rapport automatique.
Peut-on rendre un site accessible avec une surcouche automatique ?
Non, et le consensus des praticiens est net sur ce point. Les surcouches d’accessibilité, ces widgets injectés en JavaScript qui affichent un pictogramme et proposent d’agrandir le texte ou d’inverser les contrastes, ne produisent pas la conformité et ne la produiront pas. La conformité se définit comme le respect de l’ensemble des critères, et aucun script tiers ne peut réparer à la volée une structure de document mal balisée.
Les chiffres de l’enquête WebAIM auprès des praticiens sont sans appel : 67 % des répondants jugent ces outils peu ou pas du tout efficaces, et la proportion monte à 72 % parmi les répondants en situation de handicap, ceux-là mêmes que le dispositif prétend servir. Seuls 2,4 % les estiment très efficaces.
S’ajoute un coût que nous sommes bien placés pour mesurer. Une surcouche, c’est un script tiers chargé sur toutes les pages, qui manipule le DOM après le rendu et ajoute une couche d’interface par-dessus l’existante. Sur le plan de la performance, c’est exactement le profil de ce que nous cherchons à supprimer dans un audit : du JavaScript tiers bloquant sur le chemin critique, pour un bénéfice non démontré.
Il existe un usage défendable de ces outils, et il faut le dire pour rester juste : certains proposent des préférences d’affichage qui rendent service à des utilisateurs précis. Ce qui est indéfendable, c’est de les vendre comme une mise en conformité, et de les afficher en lieu et place d’un audit.
L’accessibilité a-t-elle un effet sur le référencement naturel ?
La réponse honnête demande une nuance que la plupart des contenus sur le sujet escamotent. L’accessibilité n’est pas un facteur de classement de Google, et le score d’accessibilité de Lighthouse n’a aucun effet direct sur le positionnement d’une page. Écrire l’inverse est faux, et c’est la première chose qu’un lecteur technique relèverait.
Ce qui est exact, et bien plus intéressant, c’est que les deux disciplines travaillent sur le même matériau. L’arbre d’accessibilité que construit un navigateur pour les technologies d’assistance et la compréhension d’une page par un robot d’exploration reposent tous deux sur le balisage sémantique du document. Un document bien structuré pour un lecteur d’écran l’est aussi pour un moteur, et pour un moteur génératif, qui travaille lui aussi sur le texte et la structure.
La liste des recoupements est longue et concrète : alternatives textuelles des images, hiérarchie des titres, intitulés de liens explicites, attribut lang du document, étiquettes de formulaire, tableaux de données correctement structurés, usage des éléments sémantiques HTML plutôt que des div génériques. Chacun de ces points figure à la fois dans un critère RGAA et dans une recommandation de référencement technique.
Nous le constatons dans notre pratique. Nos audits de web performance relèvent régulièrement des points qui touchent directement à l’accessibilité, sans que ce soit leur objet : des images sans alternative repérées en travaillant sur le poids des médias, une hiérarchie de titres incohérente découverte en analysant le rendu du contenu principal, des états de focus supprimés par une règle CSS destinée à faire disparaître un contour jugé disgracieux. Le même fichier, lu pour deux raisons différentes.
Certaines corrections d’accessibilité ont même un effet performance direct, et c’est le cas le plus favorable. Retirer une surcouche JavaScript inutile, remplacer un carrousel inaccessible par une mise en page statique, simplifier un composant surchargé d’ARIA : chacune de ces actions allège la page tout en la rendant plus utilisable. La relation entre qualité technique et visibilité est le sujet que nous développons dans notre analyse de l’impact SEO de la web performance.
Quels défauts d’accessibilité sont les plus fréquents ?
L’étude annuelle de WebAIM, qui analyse le million de pages d’accueil les plus visitées, donne la photographie la plus fiable disponible. Dans son édition publiée en mars 2026 sur des données de février, 95,9 % des pages présentaient au moins un échec WCAG détectable automatiquement, avec une moyenne de 56,1 erreurs par page. Le chiffre est reparti à la hausse après six années d’amélioration progressive.
Six types de défauts concentrent 96 % des erreurs relevées, et ce sont les mêmes depuis sept ans. Les corriger réglerait donc l’essentiel du problème mesurable, ce qui rend leur persistance d’autant plus frappante.
| Défaut | Pages concernées | Critère RGAA associé | Effet pour l’utilisateur |
|---|---|---|---|
| Contraste de texte insuffisant | 83,9 % | Thématique 3, couleurs | Texte illisible en faible vision ou en plein soleil |
| Alternative textuelle manquante | 53,1 % | Thématique 1, images | Image muette au lecteur d’écran |
| Étiquette de formulaire absente | 51,0 % | Thématique 11, formulaires | Champ dont on ignore ce qu’il attend |
| Lien sans intitulé | 46,3 % | Thématique 6, liens | Lien annoncé sans destination |
| Bouton sans nom accessible | 30,6 % | Thématique 7, scripts | Commande dont l’action reste inconnue |
| Langue du document non déclarée | 13,5 % | Thématique 8, éléments obligatoires | Synthèse vocale avec le mauvais accent |
Deux enseignements se dégagent de ce tableau, au-delà des chiffres eux-mêmes. Aucun de ces six défauts n’est difficile à corriger techniquement : il s’agit d’attributs manquants et de valeurs de couleur, pas d’architecture à refondre. Et tous les six sont détectables automatiquement, ce qui signifie qu’un simple passage d’outil suffit à les identifier.
Un troisième élément mérite l’attention de quiconque travaille la performance. WebAIM relève que la complexité des pages d’accueil a augmenté de 22,5 % en un an, avec 1 437 éléments en moyenne, et que le volume d’attributs ARIA a progressé de 27 %. Les pages contenant de l’ARIA comptaient 59,1 erreurs en moyenne, contre 42 pour celles qui n’en contenaient pas.
Les bibliothèques de carrousel figurent parmi les technologies les plus corrélées aux erreurs relevées, entre 20 et 32 % au-dessus de la moyenne selon les cas. C’est une confirmation chiffrée de ce que nous écrivions déjà sur le coût réel des sliders : le composant cumule les défauts d’accessibilité, le poids et la faible utilité. Les choix typographiques et le traitement des images se lisent de la même façon à double entrée.
Combien coûte et combien de temps prend une mise en conformité ?
Aucun chiffre unique n’a de sens ici, et se méfier de ceux qu’on trouve en ligne est un bon réflexe. Le coût dépend de trois variables qui varient d’un facteur dix d’un projet à l’autre : la taille de l’échantillon de pages à auditer, la nature des composants en cause, et la qualité du code de départ.
La démarche se décompose en étapes dont les ordres de grandeur diffèrent nettement, et il est plus utile de les distinguer que d’annoncer un forfait.
- L’audit initial selon la méthodologie RGAA, mené sur un échantillon représentatif, se compte en jours et produit le taux de conformité ainsi que la liste des non-conformités ;
- Les corrections mécaniques, alternatives manquantes, contrastes, étiquettes de formulaire, attributs de langue, se traitent rapidement et couvrent souvent la majorité des occurrences ;
- Les corrections structurelles, composants interactifs à reprendre, navigation au clavier à rétablir, gestion du focus, représentent l’essentiel du budget et supposent du développement ;
- Les documents formels, déclaration, schéma pluriannuel et plan d’actions, se rédigent en quelques heures une fois l’audit disponible.
Cette décomposition explique pourquoi la première action à mener n’est presque jamais technique. Publier une déclaration exacte, adossée à un audit réel et annonçant honnêtement un taux de 40 %, coûte une fraction de ce que coûte la mise en conformité complète et éteint la part du risque réglementaire qui se déclenche le plus vite.
Le calendrier, lui, est contraint par un facteur qu’on ne maîtrise pas : la disponibilité des équipes qui doivent produire les corrections. Un audit se planifie ; une reprise de composants s’insère dans un cycle de développement déjà chargé, et c’est là que les projets s’enlisent.
Comment intégrer l’accessibilité dans un projet plutôt qu’en rattrapage ?
La différence de coût entre les deux approches est le seul argument qui compte, et il est massif. Poser un attribut alt pendant l’intégration d’un gabarit ne coûte rien ; le poser après coup sur plusieurs milliers d’images publiées suppose un inventaire, un arbitrage éditorial sur chaque visuel et une reprise en base. Le même travail change d’ordre de grandeur selon le moment où il est fait.
Trois moments du projet concentrent l’essentiel de l’effet. En conception, le choix des couleurs et des contrastes se valide avant que la maquette ne soit déclinée sur cinquante écrans. En intégration, le choix des éléments HTML sémantiques plutôt que des div stylés détermine la moitié de la conformité future. En développement, la gestion du focus et de la navigation au clavier se pense en même temps que le composant, pas six mois plus tard.
C’est dans cet esprit que nous travaillons les sites que nous concevons et développons, en intégrant les critères d’accessibilité dès la phase de développement plutôt qu’en couche de rattrapage. Cette approche ne dispense d’ailleurs pas d’un audit : la conformité reste un état mesuré, et personne ne peut l’affirmer sans l’avoir vérifiée critère par critère.
Une pratique simple change beaucoup de choses au quotidien : naviguer sur la page qu’on vient de développer en utilisant uniquement la touche de tabulation, avant de la livrer. L’exercice prend deux minutes et attrape une bonne partie des défauts que les outils automatiques ne voient pas.
Par où commencer concrètement
Un ordre de priorité se dégage naturellement de tout ce qui précède, et il n’est pas celui qu’on adopte spontanément. La tentation est de commencer par corriger le code ; l’ordre efficace commence par savoir où l’on se situe et le déclarer honnêtement.
La première étape consiste à déterminer si l’organisation est assujettie, et à quel titre. Un organisme public relève de l’article 47 dans son intégralité, une entreprise de commerce en ligne de l’European Accessibility Act depuis juin 2025, une grande entreprise privée des seules obligations d’affichage vis-à-vis de l’Arcom. Les trois régimes n’appellent pas les mêmes priorités.
La deuxième étape est l’audit, parce que rien de sérieux ne peut être publié sans lui. La troisième est la mise en ordre documentaire, qui est rapide et qui éteint le risque le plus immédiat. La quatrième seulement est le plan de correction technique, échelonné sur le schéma pluriannuel, en traitant d’abord les parcours critiques : ceux qui permettent d’accomplir la démarche pour laquelle les gens viennent.
Une dernière recommandation, moins évidente : intégrer un contrôle automatique dans la chaîne d’intégration continue. Il ne détectera qu’une fraction des critères, mais il empêchera les régressions, et c’est précisément là que se perd le bénéfice d’une mise en conformité réussie. Un site conforme au moment de l’audit redevient non conforme en quelques mois de publications si personne ne surveille.
Une exigence qui déborde largement le cadre réglementaire
Il y a quelque chose de paradoxal dans la façon dont le sujet est arrivé sur les tables de réunion. L’obligation existe depuis 2005, la matière technique est publique et documentée depuis des années, et c’est la perspective d’une sanction qui a déclenché le mouvement. La conformité a précédé l’intention, ce qui n’est pas la meilleure façon de construire quelque chose de durable.
Les chiffres de WebAIM invitent d’ailleurs à regarder plus loin que la case à cocher. Si 95,9 % des pages les plus visitées du web échouent sur des critères automatiquement détectables, et si les six mêmes défauts dominent depuis sept ans, le problème n’est pas la difficulté technique. Il est que personne, dans la chaîne de production, n’a la responsabilité explicite de ces points, et qu’ils tombent donc entre les mailles.
La question qui se pose aux équipes n’est peut-être pas de savoir comment atteindre un taux, mais quand cesser de traiter l’accessibilité comme un chantier ponctuel. Un contraste se valide en conception, une alternative s’écrit en même temps que le contenu, un composant se teste au clavier avant d’être livré. Aucune de ces trois habitudes ne demande un budget ; toutes les trois demandent qu’on décide qui s’en occupe.
