Les WCAG 2.2 sont devenues une recommandation du W3C en octobre 2023 et constituent aujourd’hui la version à laquelle se mesure la plupart du travail en accessibilité. Elles ajoutent neuf critères de succès aux WCAG 2.1 et en retirent un. Ce guide explique chaque changement en langage clair — ce qu’il exige, à qui il profite, comment les sites y échouent habituellement et comment corriger le problème — et comment vérifier la conformité aux WCAG 2.2 d’un site Web d’entreprise de Toronto.
Ce qui a changé dans les WCAG 2.2
Les WCAG 2.2 conservent tout ce que contenaient les WCAG 2.1 (qui conservaient tout ce que contenait la version 2.0) et ajoutent neuf critères de succès. Six sont de niveau A ou AA et font donc partie de toute déclaration de conformité WCAG 2.2 AA; trois sont de niveau AAA. Un ancien critère, 4.1.1 Analyse syntaxique, a été retiré parce que les navigateurs et les technologies d’assistance modernes n’en dépendent plus.
Les nouveaux critères visent trois groupes que les versions précédentes servaient moins bien : les utilisateurs du clavier (un focus qui reste visible), les personnes ayant un handicap moteur (des solutions de rechange au glissement, des cibles plus grandes) et les personnes ayant un handicap cognitif (une aide cohérente, aucune ressaisie, une connexion sans test de mémoire).
La LAPHO exige-t-elle les WCAG 2.2?
Pas encore. La LAPHO (Loi sur l’accessibilité pour les personnes handicapées de l’Ontario) exige toujours le niveau AA des WCAG 2.0 de la part des organismes du secteur public et des organisations de 50 employés ou plus. Mais comme chaque version contient la précédente, un site qui respecte le niveau AA des WCAG 2.2 respecte aussi celui des WCAG 2.0 — et il reflète la façon dont les gens utilisent réellement le Web aujourd’hui, sur téléphone et sur écran tactile. C’est pourquoi le niveau AA des WCAG 2.2 est la cible raisonnable pour tout nouveau projet. Pour le portrait juridique complet, consultez notre guide sur l’accessibilité des sites Web et la conformité aux WCAG.
Les six nouveaux critères de niveaux A et AA
2.4.11 Focus non masqué (minimum) — niveau AA
Lorsqu’un élément reçoit le focus du clavier, il ne doit pas être entièrement caché par un autre contenu de la page. Les coupables habituels sont les en-têtes et pieds de page fixes, les bandeaux de témoins (cookies) et les fenêtres de clavardage : un utilisateur du clavier atteint un lien avec la touche Tab, et le lien disparaît derrière l’en-tête.
Comment corriger le problème : réglez scroll-padding-top de la page à la hauteur de tout en-tête fixe (et scroll-padding-bottom pour les pieds de page fixes), et assurez-vous que les bandeaux et les boutons de clavardage ne recouvrent pas le contenu qui a le focus — permettez aux gens de les fermer, ou gardez-les à l’écart du contenu principal.
2.5.7 Mouvements de glissement — niveau AA
Tout ce qui peut se faire par glissement doit aussi être possible avec une seule action de pointeur — un clic ou un toucher —, à moins que le glissement soit essentiel. Les curseurs de plage, les listes triables, les tableaux kanban, le déplacement dans une carte et les zones de « glisser pour téléverser » sont des échecs courants. Bien des personnes qui ont des tremblements, une dextérité limitée ou qui utilisent un pointeur frontal ne peuvent pas maintenir et faire glisser avec précision.
Comment corriger le problème : associez chaque glissement à des boutons ou à des champs — des boutons plus et moins ou un champ numérique à côté d’un curseur, des commandes « monter / descendre » sur les éléments triables, des boutons de zoom et de déplacement sur les cartes et un sélecteur de fichiers ordinaire à côté de la zone de dépôt.
2.5.8 Taille de la cible (minimum) — niveau AA
Les cibles de pointeur — boutons, liens, icônes, commandes de formulaire — doivent mesurer au moins 24 pixels CSS sur 24, avec des exceptions raisonnables : une cible plus petite est conforme si elle a assez d’espace autour d’elle, si la même fonction est offerte par une autre cible de la bonne taille, s’il s’agit d’un lien dans une phrase ou si sa taille est déterminée par le navigateur.
Comment corriger le problème : donnez aux boutons-icônes (fermeture, réseaux sociaux, flèches de carrousel, pagination) une zone cliquable d’au moins 24 px — le remplissage compte — et espacez les petites cibles. Sur écran tactile, plus c’est grand, mieux c’est : 44 px demeure une bonne cible de conception pour les commandes principales.
3.2.6 Aide cohérente — niveau A
Si un site Web offre de l’aide — un numéro de téléphone ou une adresse courriel, un formulaire de contact, du clavardage, un lien vers une FAQ — sur plusieurs pages, cette aide doit apparaître dans le même ordre relatif sur chaque page. Les personnes qui comptent trouver de l’aide à un endroit familier ne devraient pas avoir à la chercher de nouveau.
Comment corriger le problème : placez l’aide dans un composant d’en-tête ou de pied de page partagé, et ne la réordonnez pas dans les gabarits individuels.
3.3.7 Saisie redondante — niveau A
L’information qu’une personne a déjà saisie au cours d’un processus ne doit pas avoir à être tapée de nouveau dans le même processus — elle devrait être remplie automatiquement ou offerte comme choix. Les exceptions sont la ressaisie essentielle (par exemple, dans un jeu de mémoire), exigée pour des raisons de sécurité ou nécessaire parce que l’information précédente n’est plus valide.
Comment corriger le problème : offrez une option « adresse de facturation identique à l’adresse de livraison », reportez les renseignements d’une étape à l’autre dans un formulaire de plusieurs pages et présentez les réponses précédentes comme des choix plutôt que comme des champs vides.
3.3.8 Authentification accessible (minimum) — niveau AA
La connexion ne doit pas reposer sur un test de fonction cognitive — se souvenir d’un mot de passe, résoudre une énigme, transcrire des caractères — à moins qu’il existe une solution de rechange ou un mécanisme d’aide. Permettre les gestionnaires de mots de passe et le copier-coller satisfait au critère; c’est aussi le cas des clés d’accès (passkeys), des liens de connexion envoyés par courriel et d’autres méthodes qui ne font pas appel à la mémoire.
Comment corriger le problème : ne bloquez jamais le collage dans les champs de mot de passe ou de code, utilisez les bons attributs autocomplete pour que les gestionnaires de mots de passe fonctionnent et remplacez les CAPTCHA de transcription de texte par des options qui ne testent ni la mémoire ni la transcription.
Les trois nouveaux critères de niveau AAA
- 2.4.12 Focus non masqué (amélioré) : aucune partie de l’élément qui a le focus ne peut être cachée — une version plus stricte du critère 2.4.11.
- 2.4.13 Apparence du focus : l’indicateur de focus doit être suffisamment grand — au moins aussi grand qu’un contour de 2 pixels CSS autour de l’élément — et présenter un contraste de 3:1 entre ses états avec et sans focus.
- 3.3.9 Authentification accessible (améliorée) : comme le critère 3.3.8, mais sans les exceptions pour la reconnaissance d’objets ou de contenu personnel.
Le niveau AAA n’est pas exigé pour l’ensemble d’un site, mais le critère 2.4.13 vaut quand même la peine d’être adopté : un style de focus marqué et uniforme est l’une des améliorations d’accessibilité les moins coûteuses qu’un système de design puisse apporter.
Ce qui a été retiré : 4.1.1 Analyse syntaxique
Les WCAG 2.2 ont retiré le critère 4.1.1 Analyse syntaxique, qui exigeait un balisage propre et bien formé. Les navigateurs et les technologies d’assistance gèrent maintenant les erreurs de balisage de façon uniforme, si bien que ce critère ne protégeait plus les utilisateurs; le W3C a indiqué qu’il devrait aussi être considéré comme satisfait pour les WCAG 2.0 et 2.1. Un HTML propre demeure une bonne pratique — les problèmes comme les identifiants en double ou les relations brisées sont détectés par d’autres critères, comme 1.3.1 Information et relations et 4.1.2 Nom, rôle et valeur.
Comment vérifier la conformité aux WCAG 2.2
Les outils automatisés ont ajouté des vérifications pour certains nouveaux critères — la taille des cibles en particulier —, mais la plus grande partie des WCAG 2.2 exige une intervention humaine. Combinez les outils avec ces vérifications manuelles :
| Critère | Vérification manuelle |
|---|---|
| 2.4.11 Focus non masqué | Parcourez chaque page avec la touche Tab, en-têtes fixes, bandeaux et clavardage ouverts. Le focus disparaît-il à un moment? |
| 2.5.7 Mouvements de glissement | Essayez chaque curseur, liste triable, carte et zone de dépôt uniquement avec des clics ou des touchers. |
| 2.5.8 Taille de la cible | Mesurez les boutons-icônes et les liens rapprochés dans les outils de développement du navigateur. |
| 3.2.6 Aide cohérente | Comparez l’ordre des options de contact et des liens d’aide d’un gabarit à l’autre. |
| 3.3.7 Saisie redondante | Remplissez chaque formulaire en plusieurs étapes. Vous demande-t-on quoi que ce soit deux fois? |
| 3.3.8 Authentification accessible | Connectez-vous avec un gestionnaire de mots de passe et en collant. Un test de mémoire ou une énigme est-il inévitable? |
Des outils gratuits comme axe DevTools, WAVE, Lighthouse et Accessibility Insights demeurent le bon premier passage pour le reste des WCAG; notre guide d’audit d’accessibilité numérique explique le processus complet.
Mettre à jour un système de design pour les WCAG 2.2
La plupart des correctifs WCAG 2.2 relèvent des composants partagés, pas des pages individuelles. Si votre site est bâti à partir d’un système de design ou d’un ensemble de gabarits, ces mises à jour couvrent d’un coup la plupart des nouveaux critères :
- Un style de focus unique utilisé par chaque composant interactif — assez épais et assez contrasté pour respecter le critère 2.4.13 Apparence du focus, même s’il est de niveau AAA. Un seul jeton, défini une seule fois.
- Une zone cliquable minimale de 24 × 24 px intégrée aux boutons, aux boutons-icônes, à la pagination et aux commandes de fermeture, au moyen du remplissage pour que le design visuel n’ait pas à changer.
- Une marge de défilement globale égale à la hauteur de l’en-tête fixe, pour que les liens internes et le focus du clavier n’aboutissent jamais en dessous.
- Des composants de curseur, de liste et de carte livrés avec leurs boutons de rechange, pour qu’aucune équipe n’ait à penser à les ajouter.
- Des modèles de formulaires qui reportent l’information d’une étape à l’autre, offrent l’option « identique à l’adresse de livraison » et utilisent les bonnes valeurs
autocomplete. - Des modèles de connexion qui permettent le collage et les gestionnaires de mots de passe, et qui prennent en charge les clés d’accès ou les liens de connexion par courriel lorsque c’est possible.
- Un en-tête et un pied de page partagés qui placent l’aide et les options de contact dans le même ordre partout.
Documentez chaque modèle avec sa référence WCAG, pour que les designers et les développeurs sachent pourquoi il est conçu ainsi — et testez les composants eux-mêmes au clavier et avec un lecteur d’écran avant qu’ils ne se retrouvent sur une page.
Les WCAG 2.2 sur téléphone et écran tactile
Plusieurs des nouveaux critères comptent surtout sur mobile. Les petites cibles tactiles entassées sont l’échec mobile le plus courant, et les gestes de glissement exclusifs — faire défiler un carrousel, déplacer une carte, réordonner une liste — excluent les personnes qui ne peuvent pas les exécuter de façon fiable. Les barres fixes au bas de l’écran et les bandeaux de témoins occupent une plus grande part d’un petit écran et risquent davantage de recouvrir les champs qui ont le focus. Lorsque vous vérifiez la conformité aux WCAG 2.2, faites vos tests sur un vrai téléphone avec le lecteur d’écran activé (VoiceOver sur iOS, TalkBack sur Android), et pas seulement dans un navigateur d’ordinateur.
Liste de contrôle de la conformité aux WCAG 2.2
- Les en-têtes, pieds de page et bandeaux fixes ne cachent jamais l’élément qui a le focus.
- Chaque interaction de glissement offre une solution de rechange par clic ou par toucher.
- Les cibles de pointeur mesurent au moins 24 × 24 px, ou sont assez espacées pour ne pas s’entasser.
- L’aide et les options de contact apparaissent dans le même ordre sur chaque page.
- Les formulaires en plusieurs étapes ne demandent jamais deux fois la même information.
- La connexion fonctionne avec les gestionnaires de mots de passe et le collage, sans test de mémoire ni énigme.
- Les styles de focus sont clairement visibles partout — idéalement en respectant aussi le critère 2.4.13.
- Tout ce qui relève du niveau AA des WCAG 2.1 est toujours conforme : contraste, redistribution, espacement du texte, étiquettes, sous-titres.
Questions fréquentes
Quelle est la différence entre les WCAG 2.0, 2.1 et 2.2?
Les WCAG 2.0 (2008) ont posé les fondations. Les WCAG 2.1 (2018) ont ajouté des critères pour les appareils mobiles, la basse vision et les handicaps cognitifs, comme la redistribution et le contraste des icônes et des commandes. Les WCAG 2.2 (2023) ajoutent neuf critères — dont six aux niveaux A et AA — portant sur la visibilité du focus, le glissement, la taille des cibles, l’aide cohérente, la saisie redondante et la connexion accessible, et retirent le critère 4.1.1 Analyse syntaxique. Chaque version comprend la précédente.
Un site conforme au niveau AA des WCAG 2.1 est-il déjà conforme aux WCAG 2.2?
Pas nécessairement. Il doit aussi respecter les six nouveaux critères de niveaux A et AA. Bien des sites échouent aux critères 2.4.11 (en-têtes fixes), 2.5.8 (petits boutons-icônes) ou 3.3.8 (collage bloqué dans les champs de mot de passe) sans que personne ne s’en aperçoive.
Combien coûte un audit WCAG 2.2?
Les outils gratuits sont un bon point de départ. Un audit manuel professionnel d’un site Web d’entreprise typique de Toronto de 10 à 50 pages coûte généralement de 2 000 à 8 000 $, selon sa taille, ses fonctionnalités interactives et ses documents. Les coûts de correction dépendent de ce que révèle l’audit.
Une petite entreprise de Toronto peut-elle recevoir une amende pour un site Web inaccessible?
L’exigence de la LAPHO concernant les sites Web s’applique aux organismes du secteur public et aux organisations de 50 employés ou plus, et des pénalités s’appliquent à celles qui ne s’y conforment pas. Les plus petites entreprises ne sont pas visées par cette disposition, mais des plaintes peuvent tout de même être déposées en vertu du Code des droits de la personne de l’Ontario — bâtir selon le niveau AA des WCAG 2.2 protège donc toute entreprise.
Vous voulez savoir comment votre site se mesure aux WCAG 2.2? PerfectPixels audite, corrige et crée des sites Web conformes au niveau AA des WCAG 2.2. Communiquez avec nous pour parler de votre site Web.
Pour aller plus loin : What’s new in WCAG 2.2 — W3C WAI.