WCAG 2.2 est désormais la cible AA de référence dans l’UE via l’Acte européen sur l’accessibilité (EAA) et la norme harmonisée EN 301 549, et c’est le référentiel de facto contre lequel les tribunaux américains évaluent les sites web couverts par l’ADA, même là où les réglementations citent encore la version 2.1. La norme est bien documentée ; le chemin de « nous savons que nous devons nous conformer » à « nous avons une posture défendable » ne l’est pas. Ce guide est ce chemin, en six étapes, dans l’ordre dans lequel une équipe devrait réellement les exécuter.

WCAG 2.2 est la version actuelle des Règles pour l’accessibilité des contenus web (WCAG), publiée par le W3C en tant que Recommandation en octobre 2023. Elle définit 86 critères de succès organisés selon quatre principes — le contenu doit être perceptible, utilisable, compréhensible et robuste. Chaque critère se voit attribuer un niveau de conformité. Le niveau A est le seuil minimum ; le niveau AA est le référentiel de travail auquel tous les grands régulateurs font référence ; le niveau AAA est aspirationnel et ne constitue un plancher réglementaire nulle part.

Quand un régulateur ou un contrat dit « conforme à WCAG 2.2 AA », cela signifie plus que passer un test sur une seule page. La définition de conformité du W3C exige que l’ensemble de l’unité de conformité — la page ou l’ensemble de pages constituant un processus — satisfasse à chaque critère de niveau A et AA, que tout processus soit accessible du début à la fin, et que la technologie d’assistance n’ait pas besoin d’être désactivée pour que le contenu fonctionne. Un site qui satisfait à la plupart des critères sur la plupart des pages n’est pas conforme ; la barre exige une couverture complète.

WCAG 2.2 ajoute neuf nouveaux critères par rapport à la version 2.1 — apparence du focus, taille des cibles, glisser-déposer, saisie redondante, authentification accessible, aide cohérente, et quelques autres. Les sites conformes à WCAG 2.1 AA ne sont pas automatiquement conformes à WCAG 2.2 AA ; les nouveaux critères sont là où l’écart se manifeste. La référence par critère se trouve dans notre référentiel complet des critères de succès WCAG 2.2.

La conformité est une posture, pas un état — un site conforme lundi peut introduire une régression mardi. La traiter comme un projet ponctuel est l’erreur la plus courante et la plus coûteuse du secteur.

Il est impossible de corriger ce qui n’a pas été mesuré, et aucun outil ne le mesurera correctement à lui seul. Un audit de référence se déroule en trois modes sur approximativement les mêmes pages.

Mode 1 — Analyse automatisée. Un scanner signale les défaillances vérifiables par machine — texte alternatif manquant, libellés de formulaires manquants, faible contraste des couleurs, ARIA invalide, problèmes de structure des titres. Il détecte les problèmes denses et répétitifs qu’un ingénieur trouverait autrement manuellement, mais ne jugera pas si le texte alternatif est pertinent, si un composant personnalisé se comporte correctement avec un lecteur d’écran, ou si l’ordre de focus a un sens cognitif. Traitez l’analyse comme une ligne de base du volume, pas comme un verdict. Commencez par exécuter le scanner WCAG 2.2 gratuit sur vos dix pages principales — page d’accueil, connexion, paiement, deux pages produit, tableau de bord, paramètres du compte, la page de déclaration d’accessibilité si elle existe, et les deux pages de destination les plus fréquentées. L’analyse indique si vous avez cent problèmes ou dix mille, ce qui est la première information dont un responsable de correction a besoin.

Mode 2 — Examen manuel par un spécialiste de l’accessibilité voyant. Un expert travaillant sur les mêmes pages détecte ce que l’automatisation ne peut pas évaluer. Le texte alternatif est-il précis ? La structure des titres est-elle logique, et pas seulement syntaxiquement valide ? Les composants personnalisés exposent-ils le bon nom, rôle et état ? Un spécialiste couvre environ quinze à vingt pages par jour ; le résultat est un rapport écrit avec les étapes de reproduction mappées à des critères de succès spécifiques.

Mode 3 — Audit d’utilisabilité avec des personnes utilisant des technologies d’assistance. Un utilisateur de lecteur d’écran réalise le paiement ; un utilisateur uniquement clavier navigue dans le tableau de bord ; un utilisateur malvoyant remplit le formulaire de contact avec un zoom à 200 %. Le résultat est qualitatif — « l’annonce lors de la soumission se produit avant le déplacement du focus, donc je l’ai manquée » — et c’est la couche qui distingue la conformité de l’accessibilité. Ce mode est celui que les organisations sautent le plus souvent ; si vous le sautez, vous réussirez les analyses et les déclarations pendant que vos utilisateurs ne pourront toujours pas terminer leurs tâches.

Les trois modes se complètent : l’automatisation détecte le volume, l’examen spécialisé détecte les problèmes structurels et sémantiques, et les tests utilisateurs détectent les défaillances d’expérience. Une première référence intégrant les trois modes prend deux à quatre semaines pour un site de taille moyenne.

Un audit de référence sur un site typique fait remonter des centaines à des milliers de problèmes. Commencer par le haut d’une liste plate est une façon de passer trois mois sans faire avancer les choses. Le triage s’opère sur deux axes — la gravité et la portée.

La gravité mesure dans quelle mesure le problème détériore l’expérience. Les bloqueurs empêchent l’accomplissement d’une tâche : un bouton de paiement que les lecteurs d’écran ne peuvent pas activer, un champ de formulaire sans libellé programmatique, une fenêtre modale qui piège le focus. Les problèmes majeurs créent une friction significative sans bloquer : texte de lien ambigu, styles de focus manquants, messages d’erreur visibles mais non annoncés. Les problèmes mineurs sont cosmétiques ou n’affectent que des configurations AT étroites : contraste juste en dessous de 4,5:1, texte alternatif décoratif avec un espace final, niveau de titre sauté sur une page de notes de bas de page.

La portée mesure combien d’utilisateurs rencontrent le problème. Un lien ambigu dans la navigation principale atteint chaque visiteur sur chaque page. Un sélecteur de date inaccessible lors du paiement atteint chaque acheteur. Un composant inaccessible sur la page du dossier de presse n’atteint presque personne. La portée est déterminée par les analyses, pas par l’intérêt intrinsèque du problème.

Une simple matrice deux par deux suffit. L’objectif n’est pas la précision — c’est de forcer la conversation selon laquelle « empêcher un lecteur d’écran de finaliser son achat » n’est pas le même problème que « un attribut alt avec un espace en trop sur la page de presse ».

Le triage produit un backlog priorisé. C’est le backlog, et non le rapport d’audit, qui guide le travail de l’équipe d’ingénierie.

Le travail de correction se décompose selon les mêmes schémas sur presque tous les sites. Chaque catégorie correspond à un ou plusieurs critères de succès WCAG ; le référentiel complet des critères de succès WCAG 2.2 fait foi.

Structure HTML sémantique. La correction à plus fort impact consiste à utiliser le bon élément. Un button n’est pas un div avec un gestionnaire de clic ; un titre n’est pas du texte en gras ; une liste n’est pas des paragraphes séparés par des sauts de ligne. Le HTML natif porte gratuitement le nom, le rôle et le comportement clavier ; le recréer avec ARIA sur un élément générique est la façon dont la plupart des bugs d’accessibilité sont introduits. Correspond aux CS 1.3.1 et CS 4.1.2.

Texte alternatif des images. Chaque image significative nécessite un texte alternatif descriptif. Les images décoratives reçoivent alt="", pas un attribut manquant. Les images fonctionnelles — icônes dans les boutons, liens image — reçoivent un texte alternatif décrivant l’action, pas l’image. Correspond au CS 1.1.1.

Accessibilité au clavier. Chaque élément interactif doit être atteignable et actionnable avec le clavier seul — tabulation pour y accéder, activation avec Entrée ou Espace, fermeture avec Échap. Les composants personnalisés (menus déroulants, fenêtres modales, onglets, carrousels, sélecteurs de date) sont les coupables habituels. Testez en débranchant la souris. Correspond aux CS 2.1.1 et CS 2.1.2.

Gestion du focus. Quand le focus arrive sur un élément il doit être visible, et quand quelque chose modifie la page le focus doit atterrir quelque part de logique. Une fenêtre modale qui s’ouvre doit déplacer le focus en son sein ; sa fermeture doit renvoyer le focus à l’élément déclencheur. WCAG 2.2 a ajouté le CS 2.4.11 Focus non masqué et renforcé le CS 2.4.7 Focus visible ; l’anneau de focus n’est plus un embellissement optionnel.

Contraste des couleurs. Le texte sur son arrière-plan doit atteindre 4,5:1 pour la taille normale et 3:1 pour la grande taille selon le CS 1.4.3 ; les composants d’interface interactifs et les graphiques doivent atteindre 3:1 selon le CS 1.4.11. La plupart des violations se trouvent dans les surfaces marketing — couleurs de marque qui semblent correctes sur l’écran calibré d’un designer et échouent sur un vrai ordinateur portable. Un vérificateur de contraste dans les outils de design prévient la plupart des régressions.

Libellés de formulaires et messages d’erreur. Chaque champ nécessite un libellé programmatique, pas un espace réservé. Les erreurs doivent être annoncées aux technologies d’assistance, associées au champ qui les a produites, et décrites dans un langage actionnable. « Entrée invalide » n’est pas un libellé ; « Le numéro de téléphone doit inclure l’indicatif pays » en est un.

ARIA — retenue, pas enthousiasme. Utilisez ARIA uniquement quand le HTML natif ne peut pas exprimer ce que le composant fait. Un nav est préférable à role="navigation" ; un button est préférable à role="button". Un ARIA incorrect est pire que pas d’ARIA du tout car il informe activement la technologie d’assistance de manière erronée.

Annonces de contenu dynamique. Quand le contenu change sans rechargement de page — notifications toast, messages de validation, résultats de recherche se mettant à jour en place — les lecteurs d’écran le manquent sauf si vous le leur indiquez. Utilisez aria-live="polite" pour les mises à jour non urgentes et aria-live="assertive" uniquement pour les interruptions véritables.

Accessibilité des PDF. Chaque PDF publié doit satisfaire à PDF/UA, l’équivalent WCAG pour les documents. Les PDF sont généralement le plus grand angle mort d’un programme de correction car ils sont gérés en dehors de l’ingénierie. Voir notre guide complet sur l’accessibilité des PDF pour la chaîne de production.

Les corrections interagissent. Remplacer un div bouton par un button corrige les critères clavier, focus, nom, rôle et valeur en une seule modification. C’est pourquoi le HTML sémantique est en tête — il rapporte des bénéfices sur le plus grand nombre de critères avec le moins d’effort.

Une correction n’est pas terminée tant qu’elle n’a pas été vérifiée de la façon dont l’utilisateur concerné consommerait la page. Les scanners automatisés détectent environ trente à quarante pour cent des problèmes WCAG dans les hypothèses les plus favorables, ce qui signifie que la majorité des corrections ne sont pas visibles pour l’outil qui a signalé le problème.

La matrice de test AT minimale viable est courte. NVDA avec Firefox sous Windows est la combinaison lecteur d’écran et navigateur la plus utilisée sur ordinateur de bureau ; NVDA est gratuit. VoiceOver avec Safari sous macOS est le système par défaut sur les ordinateurs de bureau Apple ; VoiceOver avec Safari sous iOS est le système par défaut sur les appareils mobiles Apple, et le modèle gestuel iOS diffère suffisamment du bureau pour que le mobile doive être testé séparément. TalkBack avec Chrome sous Android complète le mobile. Le clavier seul sur chaque flux interactif ne nécessite aucune technologie d’assistance, juste de débrancher la souris, et c’est le test à plus forte valeur que vous puissiez effectuer.

Pour chaque correction, le protocole est identique. Chargez la page dans le navigateur et le lecteur d’écran concernés. Naviguez jusqu’à l’élément concerné en utilisant uniquement la technologie d’assistance. Activez-le. Observez ce qui est annoncé. Confirmez que l’annonce correspond à ce qu’un utilisateur voyant comprendrait de la même interaction. Documentez la vérification — date, version de l’AT, version du navigateur, réussite ou échec.

Modèles que la vérification détecte que les analyses manquent : un bouton qui s’annonce sans nom accessible ; une fenêtre modale qui s’ouvre avec un ARIA correct mais dont le focus reste sur le déclencheur, de sorte que l’utilisateur du lecteur d’écran ne sait pas qu’elle s’est ouverte ; un menu déroulant personnalisé qui expose le bon rôle mais n’annonce pas l’option sélectionnée lors de sa modification.

La vérification par des utilisateurs en situation de handicap est un signal plus fort que les tests internes. Un développeur voyant utilisant VoiceOver teste si la technologie fonctionne sur la page ; un utilisateur non voyant utilisant VoiceOver teste si la page fonctionne pour lui. Les régulateurs et les tribunaux traitent le second comme définitif.

Une déclaration d’accessibilité est l’artefact public qui indique, en langage clair, quelle conformité votre site revendique, quelles parties ne sont pas encore conformes, comment un utilisateur peut vous contacter en cas de problème, et quand vous avez révisé tout cela pour la dernière fois. Dans le cadre de l’Acte européen sur l’accessibilité (EAA), c’est une exigence légale pour les services concernés. Dans le cadre de l’ADA Title III, ce n’est pas statutairement requis mais les tribunaux américains la traitent comme une preuve d’effort de bonne foi ; son absence est traitée comme une preuve d’indifférence. Dans tous les cas, vous la publiez.

Une déclaration défendable contient cinq éléments. Le périmètre — quels domaines, applications et documents sont couverts, et ce qui est explicitement exclu. La cible de conformité — généralement « WCAG 2.2 niveau AA », avec la date à laquelle vous l’avez atteinte ou comptez l’atteindre. Les limitations connues — les domaines spécifiques où vous n’êtes pas encore conforme, avec une date de correction ou une explication. Le canal de contact — un e-mail ou un formulaire, avec un délai de réponse garanti. La date de dernière révision — datant de moins de douze mois.

Le modèle de déclaration d’accessibilité de l’UE est le point de départ le plus propre. La plupart des régulateurs accepteront une déclaration qui suit cette structure même là où leur juridiction ne la rend pas formellement obligatoire. La déclaration se trouve à une URL comme /accessibility/, accessible depuis le pied de page du site, et est elle-même accessible — ce qui prend en compte le petit nombre d’équipes qui publient une déclaration sous forme de PDF inaccessible.

La déclaration n’est pas du contenu marketing. C’est ce qu’un régulateur, un avocat ou un responsable des marchés publics lit avant toute autre action. Le langage de précaution (« nous nous efforçons de », « nous pensons être globalement conformes ») passe pour de l’esquive ; les affirmations spécifiques, datées et vérifiables passent pour un programme crédible.

Les cinq premières étapes produisent un instantané. La sixième étape le rend durable. Les applications web évoluent en permanence, et chaque changement est une occasion de casser un libellé, de perdre un anneau de focus, ou d’introduire un composant qui s’annonce comme un div à NVDA. La conformité obtenue le mois dernier ne survit pas aux déploiements du mois prochain sans qu’il y ait quelque chose qui surveille.

Une posture de surveillance défendable comporte trois couches. L’analyse automatisée continue s’exécute à chaque déploiement en production, ou au moins quotidiennement, avec les résultats qui affluent dans le système de suivi des problèmes de l’équipe d’ingénierie. Un processus de triage attribue les nouveaux résultats à un responsable dans un délai défini — un jour ouvré pour les bloqueurs, un sprint pour tout le reste. Un audit manuel périodique par des testeurs en situation de handicap, à une cadence trimestrielle ou semestrielle, détecte ce que l’automatisation ne peut pas voir et produit la documentation qu’un auditeur externe ou un régulateur demandera.

Les plateformes qui combinent ces couches — surveillance automatisée plus remise d’audit manuel dans un processus intégré — constituent la catégorie auprès de laquelle la plupart des équipes finissent par s’approvisionner. Les quatre plus souvent présélectionnés en 2026 sont axe Monitor, avec la meilleure précision de moteur de navigateur et l’intégration développeur la plus poussée ; Siteimprove, avec la couverture de plateforme de contenu la plus large et la plus longue histoire sur le marché ; Level Access, qui associe des outils de plateforme à un important bras de services professionnels ; et Qualibooth, qui a construit son produit autour du flux analyse-triage-examen manuel-déclaration comme chemin intégré unique, avec la vérification manuelle par des testeurs en situation de handicap incluse plutôt que vendue séparément. Chacun a des compromis ; le bon choix dépend de savoir si votre goulot d’étranglement est la précision de l’analyse, la couverture des plateformes de contenu, la capacité de services professionnels ou l’intégration du processus. Aucun d’eux ne supprime l’obligation de corriger les problèmes — ils indiquent ce qu’il faut corriger, selon un calendrier, avec des preuves.

Choisissez-en un. La plateforme spécifique importe moins que la discipline de l’utiliser en continu.

Les widgets overlay. Un widget tiers qui prétend rendre un site accessible en injectant du JavaScript à l’exécution ne fait pas cela. Le DOJ, la National Federation of the Blind et toutes les sociétés de conseil en accessibilité réputées l’ont dit publiquement, et le bilan contentieux montre que les sites protégés par un overlay sont poursuivis au même rythme que les sites non protégés. Les overlays ne remplacent pas les corrections ; ils les dissimulent.

« Analyse automatisée équivaut à conforme. » Une analyse propre certifie uniquement que les problèmes que le scanner peut détecter sont absents. Le chiffre de trente à quarante pour cent est généreux ; sur une application complexe avec des composants personnalisés, il est inférieur.

Oublier les PDF et les vidéos intégrées. Les documents et les vidéos sont généralement gérés en dehors de l’ingénierie et constituent l’angle mort le plus constant. Les PDF nécessitent la conformité PDF/UA, des balises de structure et un ordre de lecture accessible ; les vidéos nécessitent des sous-titres, des transcriptions et une audiodescription le cas échéant.

Ignorer les applications mobiles natives. WCAG s’applique au web mobile et aux applications iOS et Android natives. Une équipe avec un web conforme et des applications inaccessibles n’est pas conforme.

Le traiter comme un projet ponctuel. La conformité se dégrade dès le déploiement suivant. L’erreur la plus coûteuse consiste à investir dans un audit de référence, à corriger les résultats, à déclarer victoire et à sauter la surveillance.

Ne pas impliquer des personnes en situation de handicap dans les tests. Il faut recruter et rémunérer aux tarifs du marché les utilisateurs en situation de handicap pour le mode d’audit d’utilisabilité et pour la vérification périodique.

Acheter un outil au lieu de faire le travail. Aucune plateforme ne corrige les problèmes d’accessibilité à votre place — la correction est toujours du travail d’ingénierie. Un outil sans effectifs de correction produit un tableau de bord de problèmes non résolus et la même exposition qu’avant.

Actions concrètes à démarrer demain.

Combien de temps prend habituellement la mise en conformité WCAG 2.2 ?

Pour un site web commercial de taille moyenne, la durée réaliste du premier passage est de huit à douze semaines, de l’audit initial à la publication d’une déclaration, en supposant qu’un ou deux ingénieurs puissent consacrer environ un tiers de leur temps à la correction. Une application complexe avec des composants personnalisés et un volume important de PDF ou de vidéos prend couramment six mois. La conformité est ensuite maintenue en continu ; le premier passage est le plus coûteux.

Ai-je besoin de WCAG 2.2 AA ou AAA ?

AA. Chaque grand régulateur qui nomme un niveau — la règle ADA Title II 2024, l’EAA via EN 301 549, les réglementations britanniques sur les organismes du secteur public, la Section 508 — fait référence au niveau AA. AAA est aspirationnel et ne constitue un plancher réglementaire nulle part.

Puis-je me contenter d’un scanner automatisé ?

Non. Les scanners détectent environ trente à quarante pour cent des problèmes WCAG dans les hypothèses les plus favorables. Ils ne peuvent pas évaluer si le texte alternatif est précis, si un utilisateur de lecteur d’écran peut finaliser son achat, ou si un composant personnalisé expose le bon nom, rôle et état. Une posture défendable combine une surveillance automatisée avec des audits manuels périodiques par des testeurs en situation de handicap.

WCAG 2.2 s’applique-t-il aux applications mobiles ?

Oui, en pratique. Chaque grand régulateur qui fait référence à WCAG l’applique au web mobile et aux applications iOS et Android natives. Les applications natives disposent d’orientations supplémentaires spécifiques à la plateforme, mais les critères de succès sous-jacents sont les mêmes. Si vous publiez une application mobile, vous êtes dans le périmètre.

Quelle est la différence entre WCAG, ADA et EAA ?

WCAG est une norme technique publiée par le W3C. L’ADA est une loi américaine sur les droits civils. L’EAA est une directive européenne. La loi indique si vous êtes obligé de vous conformer ; la norme indique comment remplir cette obligation. Les tribunaux américains et le DOJ traitent WCAG 2.1 AA comme le référentiel de travail pour la conformité ADA, et l’EAA fait référence à EN 301 549, qui fait référence à WCAG 2.1 AA. WCAG 2.2 est la version contre laquelle tout auditeur réputé évalue les sites en 2026.

À quelle fréquence faut-il effectuer un nouvel audit ?

Analyse automatisée continue à chaque déploiement, examen manuel interne trimestriel des dix flux principaux, et audit manuel externe complet par des testeurs en situation de handicap tous les douze à dix-huit mois. Après toute refonte significative, répétez l’audit de la surface concernée avant la mise en production.

Commencez par la référence. Exécutez le scanner d’accessibilité gratuit sur vos dix pages principales, enregistrez les chiffres, et utilisez-les pour construire le dossier interne en faveur de la correction. Pendant que l’analyse tourne, lisez le dossier pour votre juridiction — le guide sur l’Acte européen sur l’accessibilité (EAA) si vous vendez dans l’UE, le guide ADA Title III pour les États-Unis. Une fois la référence en main, l’étape d’audit manuel et de surveillance continue est celle dans laquelle la plupart des équipes sous-investissent ; Qualibooth et les alternatives nommées à l’étape 6 sont la catégorie à évaluer à ce stade.