Un processus de test d'accessibilité que les équipes web peuvent vraiment tenir

Un processus reproductible pour tester l'accessibilité d'un site web : quoi automatiser, ce qu'une personne doit vérifier à la main, comment échantillonner les pages, qui valide, comment consigner et corriger les anomalies, et un contrôle avant publication qui empêche les nouveaux problèmes d'être mis en ligne.

La plupart des équipes web ont déjà réalisé au moins un audit d'accessibilité. Un consultant a testé 40 pages, produit un rapport de 90 pages, et six mois plus tard la moitié des corrections étaient faites et deux fois plus de nouveaux problèmes avaient été mis en ligne. L'audit n'était pas l'échec. Ce qui manquait, c'était un processus : une façon de tester qui s'applique à chaque changement, menée par des personnes déjà présentes dans l'équipe. Ce guide en présente un, dans l'ordre où vous l'introduiriez.

Le principe : trois niveaux, chacun repérant ce que les autres manquent

La Web Accessibility Initiative du W3C est claire : les outils d'évaluation aident, mais aucun outil ne peut à lui seul déterminer si un site respecte les normes d'accessibilité. Un processus raisonnable comporte donc trois niveaux.

Niveau	Repère	Manque	Quand il s'applique
Vérifications automatisées	Attributs alt manquants, faible contraste des couleurs sur du texte simple, libellés de formulaire manquants, liens vides, identifiants en double, langue de la page manquante	Si le texte alternatif a du sens, si l'ordre du focus est logique, si un composant sur mesure fonctionne avec un lecteur d'écran, si des consignes reposent sur la couleur ou la forme	À chaque modification de page, idéalement automatiquement
Vérifications manuelles par l'équipe	Pièges au clavier, focus invisible, titres confus, intitulés de liens peu clairs, zoom et réorganisation défaillants, messages d'erreur médiocres	Les frictions réelles vécues par les personnes qui utilisent des technologies d'assistance au quotidien	Avant chaque mise en production et sur les nouveaux modèles
Tests avec des utilisateurs en situation de handicap	Si la tâche peut vraiment être accomplie : payer une facture, réserver une salle, demander un permis	La couverture complète de la norme	Une ou deux fois par an sur les tâches les plus importantes

Les équipes qui ne s'appuient que sur un niveau obtiennent des résultats prévisibles. Celles qui n'automatisent que passent le scanner et échouent auprès des vrais utilisateurs. Celles qui ne testent qu'à la main ne peuvent pas suivre le volume de changements. Celles qui ne font que des tests utilisateurs trouvent les gros problèmes et manquent des centaines de petits.

Choisissez votre cible et écrivez-la

Décidez de la norme par rapport à laquelle vous testez et inscrivez-la dans votre politique. Beaucoup d'organisations utilisent les WCAG 2.1 niveau AA, car c'est la norme retenue par la règle du ministère de la Justice pour les administrations d'État et locales au titre de l'ADA Title II. Les WCAG 2.2 sont la recommandation actuelle du W3C ; elles ajoutent des critères (par exemple sur le focus qui ne doit pas être masqué et sur la taille des cibles) et suppriment le critère 4.1.1 Parsing devenu obsolète. Tester selon les 2.2 AA couvre aussi les 2.1 AA, Parsing excepté : beaucoup d'équipes testent donc selon les 2.2 et rendent compte selon la version que nomme leur obligation légale. Consultez Section 508 vs ADA Title II vs WCAG pour savoir ce qui s'applique à qui.

Étape 1 : choisir quoi tester (l'échantillonnage)

Vous ne pouvez pas tester chaque page à la main à chaque mise en production. Utilisez un échantillon représentatif du site, une idée tirée de la méthodologie d'évaluation du W3C (WCAG-EM).

Chaque modèle. Accueil, page d'atterrissage, article, liste, résultats de recherche, formulaire, page d'erreur, événement, actualité, annuaire du personnel. Les bogues d'un modèle se répètent sur chaque page qui l'utilise : en corriger un en corrige des centaines.
Chaque composant. Menus, accordéons, onglets, carrousels, fenêtres modales, sélecteurs de date, cartes, lecteurs vidéo, bandeaux de cookies, widgets de discussion.
Les tâches principales. Les cinq à dix choses que la plupart des gens viennent faire. Pour une ville, cela peut être payer une facture d'eau, signaler un nid-de-poule, trouver les ordres du jour des séances et demander un permis.
Une poignée au hasard. Cinq à dix pages choisies au hasard, pour repérer les problèmes de contenu que les modèles n'expliquent pas.

Consignez l'échantillon dans un court tableau et gardez-le sous gestion de versions. Complétez-le quand un nouveau modèle ou composant apparaît.

Étape 2 : la vérification manuelle que chaque testeur effectue

C'est le cœur du processus. Elle prend 15 à 30 minutes par page une fois que l'on a l'habitude, et ne nécessite aucun logiciel particulier hormis un navigateur et le lecteur d'écran gratuit du système d'exploitation.

#	Vérification	Comment	À quoi ressemble un échec
1	Clavier seul	Rangez la souris. Parcourez toute la page avec Tab, utilisez Entrée, Espace, les flèches et Échap	Un élément ne peut être atteint ou actionné ; le focus reste bloqué ; un menu ne peut pas être fermé
2	Focus visible	En tabulant, voyez-vous toujours où vous êtes ?	Le focus disparaît, ou se cache derrière un en-tête fixe
3	Ordre du focus	Le focus se déplace-t-il dans un ordre logique ?	Saute de l'en-tête au pied de page et inversement ; une fenêtre modale s'ouvre mais le focus reste derrière
4	Zoom et réorganisation	Zoomez à 200 % et 400 % ; réduisez la largeur de la fenêtre	Texte coupé, défilement horizontal pour le corps du texte, éléments qui se chevauchent
5	Titres	Affichez la structure des titres avec une extension de navigateur ou un lecteur d'écran	Pas de H1, niveaux sautés pour des raisons de style, titres qui ne sont que du texte en gras
6	Images	Lisez le texte alternatif hors contexte	« image1.jpg », « photo », ou la description d'une arabesque décorative ; graphiques informatifs sans équivalent textuel
7	Liens et boutons	Listez tous les liens ; ont-ils un sens isolément ?	Dix liens qui disent « Cliquez ici » ou « En savoir plus »
8	Formulaires	Envoyez-les vides, puis avec des valeurs erronées	Erreurs signalées uniquement en rouge, non annoncées ou non liées au champ ; libellés qui disparaissent pendant la saisie
9	Passage au lecteur d'écran	Activez le lecteur d'écran et accomplissez la tâche principale de la page	Boutons sans libellé, contenu annoncé deux fois, changements dynamiques non annoncés
10	Mouvement et médias	Lancez les vidéos, observez les animations	Pas de sous-titres, animations en lecture automatique sans pause, clignotements
11	Dépendance à la couleur	La page aurait-elle encore un sens en niveaux de gris ?	Champs obligatoires ou statuts indiqués uniquement par la couleur
12	Documents	Ouvrez chaque PDF ou fichier bureautique lié dans l'échantillon	Images numérisées de texte, pas de balises, pas d'ordre de lecture

Notre liste de contrôle d'accessibilité web passe en revue chaque critère si vous voulez la version longue. Le tableau ci-dessus est la version que les gens appliqueront vraiment chaque semaine.

Étape 3 : consigner les anomalies pour qu'elles soient corrigées

Une bonne anomalie est une anomalie qu'un développeur ou un éditeur peut corriger sans poser de question. Utilisez un seul modèle pour toutes les anomalies.

Champ	Exemple
Où	Modèle : page d'événement. URL : /events/summer-concert
Ce qui se passe	Le menu « Ajouter au calendrier » s'ouvre avec Entrée mais ne peut pas être fermé avec Échap ; le focus reste à l'intérieur
Qui est concerné	Les utilisateurs du clavier et des lecteurs d'écran
Critère	WCAG 2.1.2 Pas de piège au clavier
Gravité	Bloquante / Majeure / Mineure (définitions ci-dessous)
Comment reproduire	Tabulez jusqu'à « Ajouter au calendrier », appuyez sur Entrée, puis sur Échap
Correction suggérée	Fermer le menu avec Échap et renvoyer le focus sur le bouton déclencheur
Responsable	Développeur front-end (modèle) ou éditeur de contenu (contenu)

Des définitions de gravité écourtent les débats :

Bloquante : quelqu'un ne peut pas accomplir une tâche. À corriger avant la mise en production ; si c'est déjà en ligne, à corriger cette semaine.
Majeure : la tâche est possible mais beaucoup plus difficile. À corriger dans la prochaine mise en production.
Mineure : agaçante, sans être bloquante. À corriger lors de la prochaine intervention sur la page.

Répartissez les anomalies par responsable. Les bogues de modèles et de composants vont aux développeurs et sont corrigés une fois. Les problèmes de contenu (texte alternatif, titres, intitulés de liens, documents) vont au service propriétaire de la page. Les mélanger dans une même file, c'est la garantie que les problèmes de contenu restent non corrigés pendant un an.

Étape 4 : placer un contrôle avant la publication

Tester après publication ne fait que mesurer les dégâts. La correction la moins chère est celle faite avant la mise en ligne d'une page. Trois contrôles, du plus léger au plus fort :

Auto-vérification par l'éditeur. Une liste de contrôle de cinq lignes dans la formation des éditeurs : titres dans l'ordre, texte alternatif pertinent, liens explicites, pas de nouveaux PDF là où une page suffirait, sous-titres sur les vidéos.
Vérification automatisée à l'enregistrement. Si votre plateforme ou votre chaîne de publication le permet, lancez un scanner sur les pages modifiées et montrez les résultats à l'éditeur.
Relecture avant mise en ligne. Un relecteur formé examine les nouvelles pages, les nouveaux sites et les modifications importantes avant leur publication. C'est le contrôle qui repère les problèmes que les outils ne voient pas.

Pour les organisations qui gèrent de nombreux sites, c'est sur ce troisième contrôle que les plateformes se distinguent. Sur We.Inc, une organisation peut configurer n'importe quel site pour que la publication nécessite une approbation en une étape avant la mise en ligne, et la demande arrive dans une file d'approbation. Cela ne teste pas l'accessibilité à votre place ; cela donne à votre relecteur un moment fixe pour le faire.

Réglages par défaut de la marque intitulés Ce que vos clients peuvent faire, avec un interrupteur pour chaque droit et une liste d'équipe — Les droits par défaut de chaque site de l'organisation, définis une seule fois.

Une file d'approbation listant un site avec les boutons Approuver et publier et Demander des modifications — Un relecteur peut approuver ou demander des modifications. La demande affichée a été créée pour la capture ; l'écran est celui du vrai produit.

L'éditeur visuel avec un titre sélectionné et ses réglages de police, de taille et de couleur ouverts — Les éditeurs modifient titres et styles dans un éditeur visuel. Les niveaux de titres et le contraste doivent tout de même être vérifiés lors de la relecture.

Un panneau de code affichant l'arborescence des fichiers et la source d'un composant Hero, avec un bouton Download — Les développeurs peuvent lire et télécharger la source du site, ce qui aide quand une correction au niveau du modèle est nécessaire.

Étape 5 : rythme et reporting

Fréquence	Quoi	Qui
À chaque modification	Scan automatisé ; auto-vérification par l'éditeur	Éditeurs, chaîne de publication
À chaque mise en production	Vérification manuelle en 12 points sur les modèles et composants modifiés	Testeur de l'équipe web
Chaque mois	Vérification manuelle de l'échantillon ; décompte des anomalies ouvertes par gravité	Référent accessibilité
Deux fois par an	Tests par tâches avec des utilisateurs en situation de handicap sur les tâches principales	Référent accessibilité, participants rémunérés
Chaque année	Audit indépendant selon la norme choisie ; révision de l'échantillon ; mise à jour de la déclaration d'accessibilité	Auditeur externe

Communiquez deux chiffres à la direction chaque mois : les anomalies bloquantes ouvertes et les anomalies majeures ouvertes. Pas un score. Les scores des outils automatisés montent et descendent pour des raisons qui n'ont rien à voir avec les utilisateurs, et ils incitent à tricher.

Les ressources : qui fait quoi

Référent accessibilité. Responsable du processus, de l'échantillon et de la file des anomalies. Pas forcément à temps plein dans une petite organisation, mais il doit être nommé.
Testeurs. Tout développeur, designer ou personne de la QA formé à la vérification en 12 points. Formez-en au moins deux pour que les congés ne bloquent pas les mises en production.
Éditeurs. Formés à l'auto-vérification. La plupart des problèmes de contenu sont créés par des éditeurs bien intentionnés à qui personne n'a montré comment fonctionnent les titres et le texte alternatif.
Participants en situation de handicap. Rémunérés, recrutés via des associations locales de personnes handicapées ou un panel de recherche, et invités à accomplir des tâches, pas à « donner leur avis sur le site ».
Achats. Tout nouveau produit fournisseur passe la même vérification manuelle avant l'achat, pas après. Notre liste de contrôle pour les achats propose des questions à poser.

Les erreurs qui défont le processus

Acheter une surcouche au lieu de corriger le code. Les scripts qui prétendent rendre un site accessible automatiquement ne corrigent pas le balisage sous-jacent, et certains créent de nouveaux problèmes pour les utilisateurs de lecteurs d'écran.
Considérer l'audit annuel comme le processus. C'est un contrôle du processus.
Ne tester que sur ordinateur. Effectuez aussi les vérifications au clavier et au lecteur d'écran sur un téléphone ; beaucoup de visiteurs des services publics n'utilisent que leur mobile.
Accepter le mot « conforme » d'un fournisseur sans preuve. Demandez comment il a testé, selon quelle version, et voyez les résultats. Aucune plateforme, y compris la nôtre, ne peut promettre que les contenus ajoutés par votre équipe seront accessibles.

Si vous gérez de nombreux sites et voulez une étape de relecture devant chacun d'eux, réservez une démo et nous vous montrerons les réglages d'approbation et de droits sur une vraie marque.

Sources

Dernière vérification le 2026-10-25.

W3C WAI, Evaluating Web Accessibility Overview (les outils ne peuvent pas déterminer seuls la conformité ; WCAG-EM).
W3C, Web Content Accessibility Guidelines (WCAG) 2.2 (critère 4.1.1 Parsing obsolète et supprimé).
ADA.gov, Fact Sheet: Title II web and mobile app rule (WCAG 2.1 AA ; dates de mise en conformité modifiées).

Ce guide fournit des informations générales, pas un conseil juridique.

Questions fréquentes

Les outils automatisés peuvent-ils tester l'accessibilité à eux seuls ?

Non. Le W3C indique qu'aucun outil ne peut à lui seul déterminer si un site respecte les normes d'accessibilité. Les vérifications automatisées repèrent rapidement une partie des problèmes ; les vérifications manuelles et les tests avec des utilisateurs en situation de handicap repèrent le reste.

Combien de pages faut-il tester à la main ?

Testez un échantillon représentatif plutôt que chaque page : chaque modèle, chaque composant, les cinq à dix tâches principales, plus quelques pages au hasard. Complétez l'échantillon quand de nouveaux modèles apparaissent.

Faut-il tester selon les WCAG 2.1 ou 2.2 ?

Testez selon la version que nomme votre obligation ; l'ADA Title II retient les WCAG 2.1 AA. Beaucoup d'équipes testent selon les WCAG 2.2 AA, qui couvrent aussi les 2.1 AA à l'exception du critère Parsing supprimé.

Comment prioriser les problèmes d'accessibilité ?

Utilisez trois niveaux de gravité : les anomalies bloquantes empêchent une tâche et sont corrigées avant la mise en production, les majeures rendent une tâche beaucoup plus difficile et sont corrigées à la mise en production suivante, les mineures sont corrigées lors de la prochaine intervention sur la page.

We.Inc rend-il les sites accessibles automatiquement ?

Non. We.Inc peut exiger une approbation en une étape avant la mise en ligne d'un site, ce qui donne à votre relecteur un moment fixe pour tester, mais votre équipe doit toujours tester chaque site.