Une checklist d'audit d'accessibilite est un document structure qui vous guide a travers chaque etape de verification necessaire pour confirmer que votre site web fonctionne pour les personnes en situation de handicap. Plutot qu'une vague promesse de rendre les choses accessibles, une checklist transforme la conformite en questions concretes oui ou non. Cette image a-t-elle un texte alternatif ? Un utilisateur au clavier peut-il atteindre chaque element interactif ? Le contraste des couleurs respecte-t-il le ratio 4.5:1 ? Ce guide fournit plus de 50 points de controle organises selon les quatre principes WCAG, plus un workflow pour realiser l'audit lui-meme. Que vous prepariez l'echeance de la directive europeenne sur l'accessibilite (EAA) entree en vigueur en juin 2025, les exigences ADA Title II pour les collectivites americaines en avril 2026, ou que vous cherchiez simplement a construire un meilleur produit, cette checklist vous donne la structure pour y arriver.
Pourquoi une checklist d'audit structuree est indispensable
Realiser un audit d'accessibilite sans checklist, c'est comme inspecter un batiment de memoire. On repere les problemes evidents et on rate les subtils qui bloquent vraiment les utilisateurs.
Les outils de scan automatise constituent un bon point de depart, mais ils ne detectent qu'environ 30 a 40 pour cent des problemes WCAG. Le reste necessite un jugement humain. Ce texte alternatif est-il reellement descriptif ou dit-il simplement image ? L'ordre de tabulation est-il logique ? Une personne malvoyante peut-elle comprendre ce graphique sans se fier uniquement a la couleur ? Une checklist garantit que vous posez ces questions systematiquement.
La dimension juridique s'est considerablement renforcee. La directive europeenne sur l'accessibilite (EAA) est devenue applicable le 28 juin 2025, avec des amendes allant de 5 000 a 300 000 euros selon le pays membre de l'UE. En France specifiquement, les amendes peuvent atteindre 250 000 euros avec des penalites journalieres supplementaires pour non-conformite continue. La loi BFSG en Allemagne prevoit des amendes jusqu'a 100 000 euros. Une checklist constitue la preuve que vous avez pris la conformite au serieux et suivi un processus methodique.
Au-dela des exigences legales, l'argument commercial est solide. Les sites conformes en matiere d'accessibilite ont tendance a mieux se positionner dans les moteurs de recherche, a convertir davantage d'utilisateurs et a generer moins de tickets de support.
Avant de commencer : preparer votre audit
Un bon audit commence par la definition du perimetre. Tester chaque page d'un site volumineux est impraticable et inutile. Concentrez-vous sur ces categories :
Pages a fort trafic : votre page d'accueil, les principales landing pages et le top 10 des pages par nombre de visiteurs. C'est la que les defauts d'accessibilite touchent le plus de monde.
Parcours utilisateur cles : inscription, connexion, paiement, recherche et tout formulaire multi-etapes. Testez le parcours complet, pas les pages isolement.
Modeles de pages uniques : si votre site utilise 8 mises en page differentes, testez au moins une page representative de chaque modele. Un bug dans un modele affecte toutes les pages qui l'utilisent.
Pages riches en contenu : articles de blog, documentation et base de connaissances. Elles contiennent souvent des images, des tableaux, des videos integrees et des documents telechargeables qui necessitent chacun un traitement specifique en matiere d'accessibilite.
Pour un site d'entreprise typique de 50 a 200 pages, auditer 10 a 15 pages representatives couvre la grande majorite des variations de modeles et de composants. Documentez votre selection de pages et le raisonnement derriere. Cette documentation est importante si vous devez un jour demontrer votre diligence.
Les outils necessaires
Pas besoin de logiciels d'entreprise couteux pour realiser un audit approfondi. Voici une boite a outils pratique :
Scanner automatise : Utilisez notre verificateur d'accessibilite gratuit sur web-accessibility-checker.com pour obtenir un rapport de conformite WCAG 2.2 instantane. Il signale les problemes comme les textes alternatifs manquants, les defauts de contraste et les labels de formulaire absents.
DevTools du navigateur : Chrome et Firefox incluent tous deux des panneaux d'inspection d'accessibilite. L'onglet Accessibility de Chrome affiche l'arbre d'accessibilite calcule pour tout element.
Lecteur d'ecran : NVDA est gratuit sur Windows. VoiceOver est integre a macOS et iOS. TalkBack est integre a Android. Vous avez besoin d'au moins un lecteur d'ecran pour verifier que votre contenu est comprehensible a l'ecoute.
Clavier : Votre clavier physique. Debranchez votre souris et essayez de completer vos parcours utilisateur principaux en utilisant uniquement Tab, Shift+Tab, Entree, Espace et les fleches.
Analyseur de contraste : Le Colour Contrast Analyser de TPGi est gratuit et permet de verifier toute combinaison de couleurs par rapport aux seuils WCAG.
Verificateur PDF : Si votre site propose des PDF telechargeables, utilisez PAC 2024 pour verifier l'accessibilite des documents.
Principe 1 : Perceptible
Le premier principe WCAG demande : les utilisateurs peuvent-ils percevoir le contenu ? L'information ne doit pas etre invisible pour tous les sens d'un utilisateur. Voici les points de controle.
Images et contenu non textuel
Chaque image informative doit avoir un texte alternatif qui transmet la meme information que l'image. Photo de batiment est insuffisant. Siege social au 42 rue Principale, batiment en brique de trois etages est correct. Les images decoratives qui n'apportent aucune information doivent avoir des attributs alt vides pour que les lecteurs d'ecran les ignorent.
Verifiez que les images complexes comme les graphiques et les infographies ont des descriptions etendues. Un camembert montrant les parts de marche necessite soit une description longue dans le texte environnant, soit un tableau de donnees lie.
Verifiez que tous les boutons-images et images liees ont un texte alternatif decrivant l'action, pas l'image. Une icone de loupe utilisee comme bouton de recherche doit avoir un texte alt Rechercher, pas loupe.
Les CAPTCHAs doivent fournir des alternatives. Un CAPTCHA base sur des images necessite au minimum une alternative audio.
Contenu video et audio
Les videos pre-enregistrees necessitent des sous-titres synchronises. Les sous-titres generes automatiquement par YouTube sont un point de depart mais contiennent generalement des erreurs qui doivent etre corrigees manuellement, surtout pour la terminologie technique.
Le contenu audio pre-enregistre necessite une transcription textuelle. Podcasts, webinaires enregistres et instructions audio necessitent tous des transcriptions.
Le contenu video pre-enregistre necessite des audio-descriptions pour les informations visuelles qui ne sont pas transmises par la piste audio existante.
Les videos en direct avec audio necessitent des sous-titres en temps reel. Cela necessite generalement un service de sous-titrage professionnel ou un sous-titrage en direct par IA avec supervision humaine.
Texte et lisibilite
Le texte normal sous 18pt ou 14pt gras necessite un ratio de contraste d'au moins 4.5:1 par rapport a son arriere-plan. Le texte large a 18pt et plus ou 14pt gras et plus necessite au moins 3:1. Utilisez un outil de verification du contraste et portez une attention particuliere au texte sur les images ou les degrades ou le contraste varie.
La page doit rester fonctionnelle et lisible lorsque le texte est agrandi a 200 pour cent. Le contenu doit se reorganiser sans defilement horizontal a 320 pixels CSS de large, ce qui simule un ecran 1280px a 400 pour cent de zoom.
N'utilisez pas d'images de texte quand du texte reel peut obtenir le meme effet visuel. Les logos sont la seule exception.
Verifiez que le contenu ne s'appuie pas uniquement sur la couleur pour transmettre des informations. Un formulaire qui marque les champs obligatoires uniquement en rouge echoue. Ajouter un asterisque ou le mot obligatoire a cote de la couleur est conforme.
Principe 2 : Utilisable
Les utilisateurs peuvent-ils operer l'interface ? Chaque fonction doit fonctionner pour les personnes qui utilisent le clavier, les lecteurs d'ecran, les commandes vocales ou les contacteurs.
Accessibilite clavier
Chaque element interactif doit etre accessible et utilisable avec un clavier seul. Naviguez au Tab sur toute votre page. Pouvez-vous atteindre chaque lien, bouton, champ de formulaire, menu deroulant, modale et widget personnalise ?
Verifiez les pieges clavier. Un piege clavier se produit quand on peut naviguer dans un element mais pas en sortir. Les boites de dialogue modales sont le coupable le plus frequent. Quand une modale est ouverte, le focus doit cycler a l'interieur. Quand elle se ferme, le focus doit revenir a l'element qui l'a declenchee.
Verifiez que l'ordre de tabulation suit une sequence de lecture logique.
Les composants personnalises construits avec des elements div ou span au lieu de HTML natif necessitent une gestion clavier explicite. Un div agissant comme bouton a besoin d'un tabindex de 0, d'un role button et d'une gestion JavaScript pour Enter et Espace. Les boutons HTML natifs obtiennent tout cela gratuitement, c'est pourquoi le HTML semantique est important.
Visibilite du focus
Chaque element interactif doit avoir un indicateur de focus visible lorsqu'il recoit le focus clavier. Le contour par defaut du navigateur fonctionne. Un style de focus personnalise aussi, tant qu'il est clairement visible.
Selon le critere WCAG 2.2 2.4.11, l'element focalise ne doit pas etre entierement cache derriere des en-tetes fixes, des boutons flottants, des bannieres de cookies ou des widgets de chat.
Ne supprimez jamais les contours de focus sans fournir un remplacement tout aussi visible.
Taille des cibles et tactile
Le critere WCAG 2.2 2.5.8 exige que les cibles interactives fassent au moins 24 par 24 pixels CSS, ou aient un espacement suffisant pour qu'un cercle de 24px centre sur la cible ne chevauche pas les cibles adjacentes. Les liens texte en ligne dans les paragraphes sont exemptes.
Les defaillances courantes incluent les boutons d'icones sans padding, les boutons de fermeture de modales de seulement 16 pixels de large et les liens de pagination serres.
Pour toute fonctionnalite de glisser-deposer, le critere WCAG 2.2 2.5.7 exige une alternative par pointeur unique. Une liste triable a besoin de boutons haut et bas. Un curseur a besoin d'un champ de saisie.
Temporisation et mouvement
Si du contenu bouge, clignote ou defile automatiquement pendant plus de 5 secondes, les utilisateurs doivent pouvoir le mettre en pause, l'arreter ou le masquer. Les carrousels automatiques, les bannieres animees et les fonds video en lecture automatique necessitent tous des controles de pause.
Rien sur la page ne doit clignoter plus de trois fois par seconde. C'est une exigence de securite contre les crises d'epilepsie sans exception.
S'il y a une limite de temps sur une interaction, les utilisateurs doivent pouvoir la desactiver, l'ajuster ou la prolonger.
Principe 3 : Comprehensible
Les utilisateurs peuvent-ils comprendre le contenu et le fonctionnement de l'interface ? Un langage clair, un comportement previsible et une gestion utile des erreurs relevent de ce principe.
Langue et lisibilite
La page doit declarer sa langue dans l'attribut HTML lang. Pour les pages en francais, utilisez lang fr. Si une section de la page est dans une autre langue, marquez-la avec son propre attribut lang. Les lecteurs d'ecran utilisent cela pour changer les regles de prononciation.
Les menus de navigation et les composants repetes doivent apparaitre au meme emplacement relatif sur toutes les pages. Le critere WCAG 2.2 3.2.6 exige que les mecanismes d'aide restent dans une position coherente.
Verifiez que les instructions ne s'appuient pas uniquement sur des caracteristiques sensorielles.
Formulaires et gestion des erreurs
Chaque champ de formulaire a besoin d'un label visible associe programmatiquement via l'attribut for correspondant a l'id de l'input. Le texte placeholder seul n'est pas un label car il disparait quand l'utilisateur commence a saisir.
Lorsqu'une soumission de formulaire produit des erreurs, identifiez les champs specifiques en erreur et decrivez ce qui ne va pas. Un message d'erreur generique n'est pas suffisant.
Pour toute saisie entrainant un engagement juridique ou financier, fournissez un moyen de relire, confirmer et corriger la soumission avant sa finalisation.
Le critere WCAG 2.2 3.3.7 exige que les informations deja saisies dans un processus multi-etapes soient pre-remplies si elles sont a nouveau necessaires.
Pour l'authentification, le critere WCAG 2.2 3.3.8 exige que les processus de connexion ne bloquent pas les gestionnaires de mots de passe et fournissent des alternatives aux CAPTCHAs.
Principe 4 : Robuste
Les technologies d'assistance peuvent-elles interpreter correctement le contenu ? Ce principe se concentre sur un code propre et une utilisation correcte des API d'accessibilite.
HTML semantique et ARIA
Utilisez des elements HTML semantiques : header, nav, main, footer, article, section, aside. Ils creent des reperes sur lesquels les utilisateurs de lecteurs d'ecran s'appuient pour la navigation.
Les titres doivent suivre une hierarchie logique. Un H1 par page, suivi de H2 pour les sections principales, de H3 pour les sous-sections, et ainsi de suite. Ne sautez pas de niveaux.
Tous les elements interactifs doivent avoir des noms accessibles. Les boutons ont besoin de texte visible ou d'un aria-label. Les liens ont besoin de texte descriptif plutot que cliquez ici.
Utilisez les roles et proprietes ARIA uniquement quand le HTML natif ne fournit pas la semantique necessaire. La premiere regle d'ARIA est : n'utilisez pas ARIA si vous pouvez utiliser le HTML natif.
Verifiez que les mises a jour de contenu dynamique sont annoncees aux lecteurs d'ecran via des regions aria-live.
La checklist complete : reference rapide
Voici la checklist complete condensee dans un format scannable.
Controles Perceptible : - Toutes les images informatives ont un texte alt descriptif - Les images decoratives ont des attributs alt vides - Les images complexes ont des descriptions textuelles etendues - Les videos ont des sous-titres synchronises (verifies manuellement) - Le contenu audio a des transcriptions textuelles - Le contraste du texte est de 4.5:1 minimum (3:1 pour le grand texte) - La page est utilisable a 200% de zoom sans defilement horizontal - Le contenu ne s'appuie pas uniquement sur la couleur
Controles Utilisable : - Tous les elements interactifs sont accessibles au clavier - Aucun piege clavier n'existe - L'ordre de tabulation suit une sequence logique - Des indicateurs de focus visibles sont presents - Le focus n'est pas masque par des elements fixes ou flottants - Les cibles interactives font 24x24 pixels CSS minimum - Les fonctions glisser-deposer ont des alternatives - Le contenu auto-anime a des controles pause/stop - Un lien d'evitement est present et fonctionnel
Controles Comprehensible : - La langue est declaree dans l'attribut HTML lang - La navigation est coherente entre les pages - Tous les champs ont des labels visibles et programmes - Les messages d'erreur identifient les champs et decrivent le probleme - L'authentification ne bloque pas les gestionnaires de mots de passe
Controles Robuste : - Les landmarks HTML semantiques sont utilises - La hierarchie des titres est logique sans niveaux sautes - Tous les elements interactifs ont des noms accessibles - ARIA est utilise correctement et uniquement quand necessaire - Les mises a jour dynamiques utilisent des regions aria-live
Comment prioriser les problemes apres l'audit
Apres avoir parcouru la checklist, vous aurez probablement une liste de problemes. Tous les defauts ne sont pas aussi urgents. Voici un cadre de priorisation pratique.
Les problemes critiques empechent les utilisateurs de completer les taches essentielles. Un piege clavier sur un formulaire de connexion signifie que les utilisateurs clavier ne peuvent pas se connecter du tout. Corrigez-les en premier.
Les problemes eleves causent des difficultes significatives mais ont des contournements. Un mauvais contraste rend le texte difficile a lire mais ne bloque pas completement l'acces. Ce sont votre deuxieme priorite.
Les problemes moyens affectent l'utilisabilite sans empecher l'accomplissement des taches. Traitez-les dans votre cycle de developpement regulier.
Les problemes faibles sont des ameliorations de bonnes pratiques au-dela des exigences strictes WCAG.
Documentez chaque constat avec sa severite, l'URL de la page affectee, le critere WCAG pertinent et une correction recommandee.
Automatiser la surveillance continue
Un audit est un instantane. Les sites web changent constamment : du nouveau contenu est publie, des fonctionnalites sont mises a jour, des modeles sont modifies. Sans surveillance continue, les regressions d'accessibilite s'installent en quelques semaines.
Configurez un scan automatise sur un planning regulier. Notre verificateur d'accessibilite vous permet de lancer des scans reguliers sur vos pages cles et de suivre les changements dans le temps.
Integrez des verifications d'accessibilite dans votre workflow de developpement. Ajoutez des bibliotheques de test comme axe-core a votre pipeline CI/CD.
Planifiez des revues manuelles trimestrielles. Les outils automatises ratent les problemes dependants du contexte.
Formez votre equipe de contenu. Beaucoup de problemes d'accessibilite viennent du contenu, pas du code.
Suivez vos progres dans le temps. Maintenez un journal des dates d'audit, du nombre de problemes par severite et des taux de resolution.
Exigences legales a connaitre en 2026
Le paysage juridique de l'accessibilite web s'est considerablement renforce. Voici les cadres les plus susceptibles d'affecter votre audit.
La directive europeenne sur l'accessibilite (EAA) est entree en vigueur le 28 juin 2025. Elle s'applique aux entreprises du secteur prive vendant des produits ou services dans l'UE, couvrant les sites web, applications mobiles, plateformes e-commerce et services bancaires numeriques. La norme technique est l'EN 301 549, qui reference WCAG 2.1 Niveau AA. Les amendes varient par pays : jusqu'a 100 000 euros en Allemagne, 300 000 euros en Espagne et 250 000 euros en France avec des penalites journalieres supplementaires.
Le BFSG allemand (Barrierefreiheitsstaerkungsgesetz) est la transposition allemande de l'EAA, avec des exigences specifiques pour les produits et services numeriques vendus en Allemagne.
L'ADA Title II exige desormais explicitement l'accessibilite web pour les entites gouvernementales locales et etatiques americaines. La norme technique adoptee est WCAG 2.1 Niveau AA. Les penalites federales peuvent atteindre 150 000 dollars par infraction.
Cibler WCAG 2.2 AA dans votre audit couvre les exigences de tous ces cadres, puisque 2.2 est un sur-ensemble de 2.1.