Voici une vérité inconfortable : 94,8 % des sites parmi le top un million échouent aux vérifications élémentaires d'accessibilité, selon le rapport WebAIM Million 2025. Ce chiffre n'a quasiment pas bougé en cinq ans malgré une prise de conscience croissante, de nouvelles lois et une avalanche d'outils automatisés promettant de tout résoudre. Alors qu'est-ce qui ne va pas ? La plupart du temps, les gens sautent les étapes difficiles. Ils lancent un scan automatisé, corrigent quelques problèmes de contraste et considèrent le travail terminé. Sauf que les outils automatisés ne détectent qu'entre 30 % et 57 % des violations WCAG. Le reste exige qu'un être humain s'assoie, range la souris, lance un lecteur d'écran et essaie réellement d'utiliser le site. Avec l'Acte européen sur l'accessibilité (EAA) en vigueur depuis juin 2025, les exigences numériques du Titre II de l'ADA prévues pour avril 2026 et plus de 5 100 procès en accessibilité déposés rien qu'en 2025, les enjeux n'ont jamais été aussi élevés. Ce guide vous accompagne à travers un processus d'audit complet en huit étapes concrètes. Pas de théorie inutile, pas de cadres méthodologiques que vous n'utiliserez jamais. Juste des techniques pratiques qui trouvent de vrais problèmes sur de vrais sites.
Qu'est-ce qu'un audit d'accessibilité web exactement ?
Un audit d'accessibilité web est une évaluation structurée d'un site par rapport aux standards d'accessibilité établis, principalement les Règles pour l'accessibilité des contenus web (WCAG). L'objectif est simple : identifier chaque barrière qui empêche les personnes en situation de handicap de percevoir, comprendre, naviguer et interagir avec votre site.
Pensez-y comme une inspection de bâtiment, mais pour votre propriété numérique. Un inspecteur vérifie les rampes, les boutons d'ascenseur, les largeurs de porte et la signalétique. Un auditeur en accessibilité vérifie la navigation au clavier, la compatibilité avec les lecteurs d'écran, le contraste des couleurs, les labels de formulaires et des dizaines d'autres critères.
Il existe trois types d'audits d'accessibilité, et comprendre la différence est important car elle conditionne vos attentes et votre budget.
Les trois types d'audits
Le premier type est un audit purement automatisé. Vous exécutez un outil comme axe, WAVE, Lighthouse ou web-accessibility-checker.com sur vos pages et obtenez un rapport des problèmes détectables par la machine. C'est rapide et peu coûteux, mais cela ne détecte que 30 % à 57 % des violations WCAG selon les études. Un alt manquant sur une image ? Les outils automatisés le trouvent instantanément. Un alt de mauvaise qualité qui dit « image123.jpg » au lieu de décrire le contenu ? Ils n'en ont aucune idée. Le deuxième type est un audit manuel réalisé par des spécialistes en accessibilité. Ils naviguent au clavier, testent avec des lecteurs d'écran, évaluent la qualité du contenu et vérifient les interactions qu'aucun algorithme ne peut analyser. Cela trouve les 43 % à 70 % de problèmes restants mais nécessite des personnes formées et un temps conséquent. Le troisième type, et celui que vous devriez viser, est un audit hybride combinant les deux approches. Commencez par le scan automatisé pour attraper les violations évidentes à grande échelle, puis ajoutez des tests manuels pour les problèmes nuancés. C'est exactement ce que nous allons détailler étape par étape. Pour une version de référence rapide à imprimer, consultez notre checklist d'audit d'accessibilité.Étape 1 : Définir le périmètre de l'audit
Avant de toucher à un outil, vous devez répondre à trois questions. Quelles pages allez-vous tester ? Quel standard utiliserez-vous comme référence ? Et quelle est la taille de votre échantillon ? Pour le standard, WCAG 2.1 Niveau AA est la base que pratiquement toutes les législations en accessibilité référencent. L'Acte européen sur l'accessibilité le rend obligatoire. Les procès ADA le citent. Si vous débutez, visez WCAG 2.1 AA. Si vous voulez aller plus loin, WCAG 2.2 a ajouté neuf nouveaux critères de succès en octobre 2023, incluant des exigences sur l'apparence du focus, les mouvements de glissement et le placement cohérent de l'aide. Notre guide WCAG détaille les différences. Pour la sélection des pages, n'essayez pas d'auditer chaque page d'un gros site. Sélectionnez plutôt un échantillon représentatif qui couvre chaque modèle unique et chaque parcours utilisateur critique. Cela signifie généralement : la page d'accueil, les pages de navigation principales, au moins une page de chaque type de contenu (article, produit, listing, formulaire), le parcours complet de conversion ou d'achat, les pages de connexion et de compte, les résultats de recherche, les pages d'erreur et toute page contenant des composants interactifs complexes comme des modales, carrousels ou tableaux de données. Pour un site de moins de 50 pages, auditez tout. Pour les sites plus grands, un échantillon de 20 à 40 pages capture généralement tous les patterns uniques. L'insight clé est que corriger un modèle corrige chaque page qui l'utilise, ce qui crée un effet de cascade en concentrant les efforts sur les templates plutôt que sur les pages individuelles.Étape 2 : Lancer le scan automatisé
Commencez votre audit par les outils automatisés car ils donnent des résultats immédiats et quantifiables sur de nombreuses pages. Considérez cette étape comme un triage : vous identifiez les problèmes les plus évidents avant d'aller plus en profondeur. Passez votre site sur web-accessibility-checker.com pour obtenir un score de référence rapide. Le scan gratuit vérifie votre page par rapport aux critères WCAG en moins d'une seconde pour les problèmes liés au DOM, avec une analyse approfondie qui suit. Vous obtiendrez une ventilation par sévérité et principe WCAG qui vous aide à comprendre l'ampleur du travail à venir. Puis croisez avec au moins un autre outil. Chaque scanner automatisé utilise des règles et heuristiques légèrement différentes, donc combiner deux outils détecte plus de problèmes que chacun pris isolément. Parmi les bons outils gratuits : WAVE (excellent pour la visualisation avec une surcouche sur la page), axe DevTools (extension navigateur de référence avec des explications détaillées) et Lighthouse (intégré à Chrome, bon pour l'accessibilité combinée à la performance et au SEO). Pa11y fonctionne bien pour l'intégration en ligne de commande et les pipelines CI/CD. Documentez chaque constat dans un tableur ou un outil de suivi. Pour chaque problème, enregistrez l'URL de la page, le critère WCAG violé, une capture d'écran ou un extrait de code, le niveau de sévérité et quel outil l'a signalé. Cette documentation devient la colonne vertébrale de votre plan de remédiation. Un avertissement : ne vous arrêtez pas là. J'ai vu trop d'organisations lancer un scan automatisé, corriger tout ce qu'il trouve et se déclarer accessibles. Cela laisse au minimum 43 % des problèmes totalement non traités. Pour une comparaison plus poussée des outils de test, consultez notre guide des meilleurs outils de vérification d'accessibilité.Étape 3 : Tests manuels au clavier
Rangez votre souris dans un tiroir. Sérieusement. Pour cette étape, vous naviguez sur la totalité de votre échantillon uniquement au clavier, et vous serez surpris de la vitesse à laquelle les choses se dégradent sur beaucoup de sites.
Voici les touches dont vous avez besoin : Tab avance vers l'élément interactif suivant. Shift plus Tab recule. Entrée active les liens et boutons. Espace active les boutons, cases à cocher et bascules. Échap ferme les modales et menus déroulants. Les touches fléchées naviguent au sein des composants comme les menus, onglets, groupes de boutons radio et curseurs.
Commencez sur la page d'accueil et appuyez sur Tab de manière répétée. Surveillez ces problèmes spécifiques :
Visibilité du focus. Pouvez-vous toujours voir quel élément est actuellement ciblé ? Un indicateur de focus visible est requis par le WCAG 2.4.7 (Niveau AA). De nombreux sites suppriment le contour par défaut du navigateur pour des raisons esthétiques et oublient de le remplacer par quelque chose de mieux. Si vous perdez la trace de votre position sur la page, c'est un échec.
Ordre de tabulation. Le focus se déplace-t-il à travers la page dans un ordre logique ? Il devrait suivre l'ordre de lecture visuel, généralement de gauche à droite et de haut en bas pour les langues LTR. Si le focus saute de manière erratique sur la page, l'ordre du DOM sous-jacent ne correspond probablement pas à la disposition visuelle.
Pièges clavier. Pouvez-vous toujours quitter l'élément courant ? Essayez de tabber dans et hors de chaque composant interactif : menus, modales, sélecteurs de date, lecteurs vidéo, cartes embarquées, carrousels. Si vous êtes coincé et ne pouvez pas sortir avec Tab ou Échap, c'est un piège clavier et c'est un échec de Niveau A, le plus grave.
Fonctionnalité interactive. Pouvez-vous utiliser chaque fonctionnalité ? Ouvrir chaque menu déroulant, soumettre chaque formulaire, lire chaque vidéo, fermer chaque popup, compléter chaque processus multi-étapes. Si une fonctionnalité nécessite la souris, elle est inaccessible.
Lien d'évitement. Le site propose-t-il un lien « aller au contenu principal » qui apparaît au Tab ? Sans lui, les utilisateurs au clavier doivent tabber à travers toute la navigation sur chaque page.
Étape 4 : Tests avec lecteur d'écran
Les tests avec lecteur d'écran révèlent une dimension complètement différente de votre site. Un contenu qui semble parfaitement organisé visuellement peut être un chaos incohérent quand il est lu à voix haute de manière séquentielle.
Selon l'enquête WebAIM Screen Reader User Survey numéro 10, JAWS détient 41 % de part de marché sur desktop, NVDA suit à 38 %, et VoiceOver domine le mobile à 70,6 %. Vous n'avez pas besoin de tester avec tous, mais vous devriez tester avec au moins un lecteur desktop et un lecteur mobile.
En pratique, commencez avec NVDA sous Windows (il est gratuit) ou VoiceOver sur Mac (intégré, activez avec Commande plus F5). Sur mobile, utilisez VoiceOver sur iOS ou TalkBack sur Android.
Ce qu'il faut écouter pendant les tests avec lecteur d'écran :
Structure de la page. Quand vous naviguez par titres (appuyez sur H dans NVDA ou utilisez le rotor dans VoiceOver), les titres reflètent-ils fidèlement la hiérarchie du contenu ? Y a-t-il des niveaux sautés, comme passer de h2 à h4 ? Chaque section a-t-elle un titre significatif ?
Descriptions des images. Naviguez jusqu'à chaque image et écoutez le texte alternatif. Est-il descriptif et utile ? Un alt de « photo » sur une image produit échoue au test même si les outils automatisés le marqueraient comme ayant un alt présent. Les images décoratives devraient avoir des attributs alt vides pour que les lecteurs d'écran les ignorent.
Interactions avec les formulaires. Tabulez à travers chaque formulaire. Chaque champ annonce-t-il son label ? Les champs obligatoires sont-ils indiqués ? Quand vous soumettez avec des erreurs, les messages d'erreur sont-ils annoncés et associés aux bons champs ? Pouvez-vous naviguer facilement entre les messages d'erreur ?
Utilisation d'ARIA. C'est là que de nombreux sites créent plus de problèmes qu'ils n'en résolvent. Les pages avec des attributs ARIA avaient en fait 34,2 % d'erreurs détectées en plus que les pages sans ARIA, selon le WebAIM Million 2025. Ce n'est pas parce qu'ARIA est mauvais, mais parce qu'il est fréquemment mal utilisé. Écoutez les annonces de rôles incorrectes, les états manquants et les widgets qui annoncent une chose mais en font une autre.
Contenu dynamique. Quand le contenu change sur la page, le lecteur d'écran l'annonce-t-il ? Cela inclut les messages de validation de formulaire, les états de chargement, les bannières de notification, les widgets de chat en direct et tout contenu mis à jour via JavaScript sans rechargement de page. Les régions ARIA live gèrent cela, mais elles doivent être implémentées correctement.
Étape 5 : Vérifier les couleurs et le contraste
Les problèmes de contraste des couleurs sont le problème d'accessibilité le plus courant sur le web, affectant 79,1 % des pages d'accueil du top un million selon WebAIM. La bonne nouvelle, c'est que les problèmes de contraste sont simples à identifier et à corriger.
Les WCAG définissent trois seuils de contraste. Le texte normal (moins de 18pt ou moins de 14pt gras) nécessite un ratio de contraste de 4,5 pour 1 par rapport à son arrière-plan. Le texte large (18pt et plus, ou 14pt gras et plus) nécessite 3 pour 1. Les composants d'interface utilisateur et les objets graphiques porteurs d'information nécessitent 3 pour 1.
Utilisez le Colour Contrast Analyser (gratuit, de TPGi) pour vérifier des combinaisons de couleurs spécifiques, ou exécutez les vérifications de contraste intégrées à vos outils automatisés de l'étape 2. Portez une attention particulière au texte sur des images ou des dégradés, où le contraste peut varier d'un bout à l'autre de l'élément. Le texte placeholder dans les champs de formulaire est tristement célèbre pour échouer aux exigences de contraste.
Au-delà des ratios de contraste, vérifiez que votre site ne repose pas uniquement sur la couleur pour transmettre une information. Les messages d'erreur ne doivent pas simplement devenir rouges ; ils ont besoin d'une icône ou d'un label textuel également. Les graphiques et diagrammes ont besoin de motifs ou de labels en plus du code couleur. Le texte des liens dans les paragraphes devrait avoir un indicateur non colorimétrique comme un soulignement, pas juste une couleur différente.
Étape 6 : Examiner la qualité du contenu
Cette étape va au-delà de la conformité technique pour évaluer l'efficacité du contenu. Les outils automatisés signalent la présence ou l'absence d'éléments, mais ils ne peuvent pas juger la qualité. Vous avez besoin d'yeux humains et de jugement ici. Qualité du texte alternatif. Chaque image informative a besoin d'un alt qui remplit la même fonction que l'image. Une photo de réunion d'équipe devrait décrire les détails pertinents, pas simplement dire « réunion ». Un graphique devrait transmettre le point de données clé ou la tendance qu'il illustre. Les images complexes comme les infographies peuvent nécessiter une description plus longue via une alternative textuelle liée. Structure des titres. Votre hiérarchie de titres devrait se lire comme une table des matières. Les utilisateurs de lecteurs d'écran naviguent fréquemment par titres pour parcourir le contenu d'une page, donc vos titres doivent être descriptifs et correctement imbriqués. Pas de niveaux sautés. Pas d'utilisation de balises de titre juste pour agrandir le texte. Langue de la page. Chaque page doit déclarer sa langue dans l'attribut HTML lang. Le contenu dans une langue différente au sein de la page (une citation en anglais sur une page française, par exemple) nécessite un attribut lang sur son conteneur. La langue de document manquante est l'une des violations WCAG les plus courantes. Conception des formulaires. Chaque champ de formulaire a besoin d'un label visible et associé. Regroupez les champs liés avec fieldset et legend. Fournissez des instructions claires avant le formulaire, pas uniquement à l'intérieur. Les messages d'erreur doivent identifier le problème spécifiquement (« L'adresse email doit contenir un @ ») plutôt que de manière générique (« Saisie invalide »). Assurez-vous que la récupération d'erreur est facile et n'efface pas les données valides précédemment saisies. Tableaux de données. Utilisez des en-têtes de tableau appropriés (éléments th) avec des attributs scope. Évitez d'utiliser les tableaux pour la mise en page. Les tableaux complexes avec des cellules fusionnées nécessitent un balisage supplémentaire comme les attributs headers pour rester compréhensibles par les technologies d'assistance. Pour un contexte plus large sur les exigences de conformité, notre guide de conformité ADA couvre les standards légaux que votre contenu doit respecter.Étape 7 : Tester sur appareils mobiles
Les tests d'accessibilité mobile détectent des problèmes que les tests desktop manquent complètement. Plus de 60 % du trafic web provient d'appareils mobiles, et les personnes en situation de handicap sont de gros utilisateurs mobiles car les smartphones disposent d'excellentes fonctionnalités d'accessibilité intégrées.
Taille des zones tactiles. WCAG 2.2 exige que les éléments interactifs mesurent au moins 24 par 24 pixels CSS pour la conformité Niveau AA, avec une recommandation de 44 par 44 pixels pour AAA. Mesurez vos boutons, liens, champs de formulaire et tout élément cliquable. Portez une attention particulière aux éléments proches les uns des autres, comme les liens de navigation dans un pied de page ou les boutons d'action dans une liste. Des cibles petites et serrées sont un cauchemar pour les utilisateurs ayant des déficiences motrices.
Zoom et redistribution. Zoomez à 200 % puis à 400 %. Le contenu devrait se redistribuer en une seule colonne sans défilement horizontal, sans chevauchement d'éléments et sans perte de fonctionnalité. Les utilisateurs malvoyants zooment fréquemment, et un site qui casse à 200 % échoue au WCAG 1.4.4.
Orientation. Votre site devrait fonctionner en orientation portrait et paysage, sauf si une orientation spécifique est essentielle (ce qui est extrêmement rare). Certains utilisateurs fixent leurs appareils dans une orientation donnée en raison de limitations physiques.
Gestes tactiles. Si votre site utilise des gestes complexes comme le pincement, le glissement multi-doigt ou l'appui long, fournissez des alternatives à pointeur unique. Un carrousel qui nécessite un glissement a aussi besoin de boutons précédent et suivant.
Testez avec VoiceOver sur iOS et TalkBack sur Android. L'expérience est notablement différente des lecteurs d'écran desktop, et vous pourrez trouver des problèmes spécifiques aux patterns d'interaction des technologies d'assistance mobiles.
Étape 8 : Documenter et rapporter vos résultats
Tout ce que vous avez trouvé aux étapes 2 à 7 doit être organisé en un rapport actionnable. Ce n'est pas de la documentation pour le plaisir de documenter ; un rapport bien structuré détermine si les problèmes sont réellement corrigés ou s'ils restent éternellement dans un backlog. Un bon rapport d'audit contient six sections. Commencez par un résumé exécutif qui communique le niveau de conformité global et le risque aux parties prenantes non techniques. Incluez un score numérique ou une note et une déclaration claire de ce que cela signifie. Les décideurs doivent comprendre la situation en moins de deux minutes. Ensuite, documentez votre périmètre et méthodologie : quelles pages ont été testées, quels outils et techniques ont été utilisés, quelle version WCAG et quel niveau de conformité vous avez mesuré, et les éventuelles limitations de l'audit. Puis organisez les résultats par principe WCAG. Regroupez les problèmes sous Perceptible, Utilisable, Compréhensible et Robuste. Au sein de chaque principe, listez les critères de succès spécifiques qui ont échoué. Cette structure s'aligne sur l'organisation des WCAG et facilite la recherche de recommandations pertinentes par les développeurs. Pour chaque problème individuel, incluez le critère WCAG, le niveau de sévérité (critique, grave, modéré ou mineur), les pages ou composants affectés, une description claire du problème, une capture d'écran ou un extrait de code démontrant le problème, et une recommandation de remédiation spécifique avec des exemples de code quand c'est possible. Après les résultats, fournissez une feuille de route de remédiation avec des phases priorisées. Plus de détails sur la priorisation dans la section suivante. Enfin, incluez un plan de retest qui précise quand et comment vous vérifierez que les corrections ont été correctement implémentées. Un audit sans cycle de retest ne fait que la moitié du travail. Si vous devez publier une déclaration d'accessibilité après votre audit, notre modèle de déclaration d'accessibilité vous offre un format prêt à l'emploi.Comment prioriser les corrections
Vous avez votre rapport d'audit. Il liste probablement des dizaines, peut-être des centaines de problèmes. Par où commencer ?
D'abord, classifiez chaque problème par sévérité. Les problèmes critiques bloquent complètement l'accès : un piège clavier qui empêche le paiement, un formulaire sans aucun label, une vidéo sans sous-titres. Les problèmes graves rendent les tâches très difficiles mais pas impossibles. Les problèmes modérés causent de la frustration. Les problèmes mineurs sont techniquement non conformes mais ont un impact limité dans le monde réel.
Puis appliquez une formule de priorisation : portée multipliée par impact multiplié par effort. La portée demande combien de pages ou d'utilisateurs sont affectés. L'impact demande à quel point le problème affecte la complétion des tâches. L'effort demande combien de travail la correction nécessite. Les problèmes à haute portée, fort impact et faible effort vont en haut de la liste.
En pratique, voici l'ordre qui fonctionne le mieux. Corrigez d'abord les problèmes au niveau des templates car ils se propagent sur chaque page utilisant ce template. Un lien d'évitement manquant dans votre template d'en-tête ? Corrigez-le une fois, et chaque page est corrigée. C'est un effet de levier énorme.
Ensuite, corrigez les problèmes critiques sur les pages à fort trafic et à forte conversion. Votre page d'accueil, vos pages produit, votre parcours d'achat et vos formulaires de contact méritent la priorité car ils affectent le plus d'utilisateurs et le plus de revenus.
Puis traitez les problèmes graves et modérés systématiquement. Regroupez-les par composant : corrigez tous les problèmes de titres d'un coup, puis tous les problèmes de formulaires, puis tous les problèmes d'images. Traiter par type est plus efficace que corriger page par page.
Gardez les problèmes mineurs purement cosmétiques ou marginaux pour une phase de maintenance. Ils comptent, mais ils ne devraient pas retarder le travail à plus fort impact.
Les meilleurs outils pour l'audit d'accessibilité
Après avoir testé des dizaines d'outils sur des centaines d'audits, voici ce qui fonctionne vraiment en pratique. Pour les outils gratuits, WAVE est excellent pour les visuels car il superpose des icônes directement sur votre page montrant où se trouvent les problèmes. axe DevTools est l'extension navigateur de référence pour les développeurs, avec des explications claires et un détail au niveau du code. Lighthouse est pratique car il est intégré à Chrome et combine accessibilité avec performance et vérifications SEO. Pa11y est puissant pour l'intégration CI/CD, permettant d'automatiser les contrôles d'accessibilité dans votre pipeline de déploiement. Le Colour Contrast Analyser de TPGi gère la vérification du contraste avec un outil pipette qui fonctionne dans toute application. Web-accessibility-checker.com offre un scan gratuit qui vérifie votre page en moins d'une seconde pour les problèmes DOM et suit avec une analyse PageSpeed Insights plus approfondie. Les plans de monitoring payants ajoutent un scanning programmé, un suivi historique et une couverture multi-pages. Pour les outils payants entreprise, Siteimprove est complet mais coûteux à environ 28 000 $ par an. AudioEye commence à 45 $ par mois pour le monitoring automatisé. axe Monitor de Deque étend le moteur axe gratuit avec un tableau de bord de reporting et des fonctionnalités d'équipe. Level Access fournit un audit complet avec des consultants experts. La vérité honnête est qu'aucun outil seul ne suffit. Combinez un scanner gratuit pour les vérifications rapides, une extension navigateur pour le développement et des tests manuels pour l'exhaustivité. Le meilleur outil est celui que votre équipe utilise réellement de manière cohérente.Ce que les outils automatisés ne détectent pas
Comprendre les limites de l'automatisation fait de vous un meilleur auditeur. Voici les catégories qui nécessitent systématiquement un jugement humain.
La qualité du texte alternatif est l'exemple classique. Les outils automatisés vérifient que les attributs alt existent mais ne peuvent pas évaluer s'ils sont significatifs. Une image avec un alt défini sur « DSC_0042.jpg » passe les contrôles automatisés mais échoue complètement pour les vrais utilisateurs.
La détection des pièges clavier est partiellement automatisable mais peu fiable. Les outils automatisés peuvent vérifier la navigation Tab basique, mais les widgets complexes avec une gestion de focus conditionnelle nécessitent souvent une vraie personne qui appuie sur les touches pour découvrir les pièges.
L'ordre de lecture versus l'ordre visuel. CSS Grid et Flexbox facilitent la création de mises en page où l'ordre visuel diffère de l'ordre du DOM. Les outils automatisés vérifient le DOM ; seul un humain utilisant un lecteur d'écran ou la touche Tab remarque quand les choses sont lues dans le mauvais ordre.
L'accessibilité cognitive est presque entièrement une question de jugement humain. Le langage est-il trop complexe ? Les instructions sont-elles claires ? La navigation est-elle prévisible ? Les messages d'erreur sont-ils utiles ? Ces questions nécessitent de comprendre le contexte et les attentes des utilisateurs.
La correction ARIA au-delà de la syntaxe. Les outils automatisés peuvent vérifier qu'un attribut ARIA a une valeur valide, mais ils ne peuvent pas vous dire si role="button" sur un div qui ressemble et se comporte comme un lien est sémantiquement faux. Ils ne peuvent pas déterminer si un aria-label contredit le texte visible. Le WebAIM Million a trouvé que les pages utilisant ARIA avaient 34,2 % d'erreurs en plus que les pages sans, principalement parce que les développeurs utilisent ARIA incorrectement.
L'expérience utilisateur réelle. Aucun outil ne peut vous dire si votre parcours d'achat est réellement utilisable avec un lecteur d'écran. Cela nécessite un humain qui traverse l'ensemble du processus, rencontre la séquence réelle d'interactions et évalue si l'expérience globale a du sens.
Les critères WCAG les plus souvent échoués
Connaître les échecs les plus courants vous aide à cibler votre audit et calibrer vos attentes. Le WebAIM Million 2025 a analysé les pages d'accueil du top un million de sites et a trouvé ces problèmes principaux. Le texte à faible contraste apparaissait sur 79,1 % des pages. C'est la violation d'accessibilité la plus répandue sur le web, et de loin. Le texte gris clair sur fond blanc, les palettes de couleurs tendance à faible contraste et le contraste insuffisant du texte placeholder sont les coupables habituels. Le texte alternatif manquant pour les images touchait 55,5 % des pages. Cela inclut les images sans attribut alt du tout et les images avec un alt vide sur du contenu non décoratif. Les labels de champs de formulaire manquants affectent un nombre énorme de pages. Quand un champ n'a pas de label programmatique, les utilisateurs de lecteurs d'écran doivent deviner quelle information saisir. Le texte placeholder n'est pas un substitut acceptable pour un label car il disparaît quand on commence à taper et a un contraste médiocre dans la plupart des navigateurs. Les liens vides et boutons vides sont des liens ou boutons qui ne contiennent aucun texte accessible. Un lien enveloppant uniquement une icône sans alt text ni aria-label, ou un bouton avec seulement une image de fond, échoue à ce critère. La langue du document manquante est l'un des problèmes les plus faciles à corriger. Ajouter lang="fr" à votre balise HTML prend cinq secondes, pourtant un pourcentage substantiel de pages l'omet encore. Sans elle, les lecteurs d'écran peuvent utiliser les mauvaises règles de prononciation pour toute la page. Tous ces problèmes sont des violations de Niveau A, le niveau le plus basique d'accessibilité. Si votre site échoue au Niveau A, il a des problèmes fondamentaux qui nécessitent une attention urgente. Notre page conformité EAA explique comment ces critères se transposent en exigences légales européennes.Coûts, ROI et argumentaire business
Les audits d'accessibilité ont des coûts clairs et des retours encore plus clairs. Comprendre les chiffres vous aide à obtenir un budget et à justifier l'investissement.
Côté coûts, un audit professionnel d'un site petit à moyen coûte généralement entre 1 250 et 5 500 dollars selon le périmètre et la complexité. Les audits de niveau entreprise avec des centaines de templates et des applications complexes vont de 25 000 à 40 000 dollars ou plus. Les audits en interne avec le processus de ce guide coûtent principalement en temps de personnel.
Maintenant considérons le risque. Le règlement moyen pour un procès ADA en accessibilité web est d'environ 25 000 dollars, et cela n'inclut pas les frais juridiques, les coûts de remédiation ni les dommages réputationnels. Avec plus de 5 100 procès déposés en 2025, ce n'est pas un risque théorique.
Les chiffres de retour sur investissement sont convaincants. La recherche Forrester a trouvé environ 100 dollars de retour pour chaque dollar investi dans les améliorations d'accessibilité. Les sites qui améliorent leur accessibilité voient en moyenne une augmentation de 23 % du trafic organique car les améliorations d'accessibilité s'alignent étroitement avec les bonnes pratiques SEO : HTML propre, titres appropriés, textes de liens descriptifs, temps de chargement rapides. Construire l'accessibilité dès le départ économise 67 % par rapport à la mise en conformité ultérieure.
Peut-être le chiffre le plus frappant : les taux d'abandon de panier passent d'environ 69 % sur les sites e-commerce inaccessibles à environ 23 % sur les sites accessibles. Quand les gens peuvent réellement utiliser votre site, ils achètent. Cela seul peut justifier la totalité du coût d'un audit et d'un programme de remédiation plusieurs fois.
L'argumentaire business se construit tout seul. Un audit n'est pas une dépense. C'est un investissement qui réduit le risque juridique, élargit votre marché, améliore le SEO et augmente les conversions. La seule question est de savoir si vous le faites proactivement ou attendez qu'un procès vous y oblige.