Résumé rapide des changements
Les WCAG 2.2, publiées en octobre 2023, introduisent 9 nouveaux critères de succès et suppriment le critère 4.1.1 Parsing. Ces modifications visent principalement à améliorer l'accessibilité pour les personnes en situation de handicap cognitif et les utilisateurs de dispositifs mobiles. La répartition par niveau montre 2 critères de niveau A, 5 de niveau AA et 2 de niveau AAA.
Cette mise à jour reste entièrement rétrocompatible avec WCAG 2.1 : tout site conforme à 2.2 est automatiquement conforme à 2.1. Les nouveaux critères ciblent des problématiques concrètes comme la visibilité du focus clavier, la taille des zones de clic, l'authentification accessible et l'élimination des saisies redondantes. Pour les développeurs déjà familiers avec WCAG 2.1, la transition vers 2.2 représente une évolution naturelle plutôt qu'une refonte complète.
Nouveaux critères de succès dans WCAG 2.2
Les 9 nouveaux critères de WCAG 2.2 répondent à des besoins identifiés lors de consultations avec les communautés d'utilisateurs en situation de handicap. Contrairement aux versions précédentes qui se concentraient davantage sur l'accessibilité pour les lecteurs d'écran, WCAG 2.2 élargit le spectre pour inclure les handicaps cognitifs, la navigation au clavier et l'ergonomie mobile.
Chaque nouveau critère s'accompagne de techniques de mise en œuvre détaillées et d'exemples de cas d'échec. Les critères de niveau AA constituent la priorité pour la plupart des organisations, car ils correspondent aux exigences légales dans de nombreux pays européens via la directive européenne sur l'accessibilité. Les critères AAA, bien que recommandés, restent optionnels pour la conformité de base.
2.4.11 Focus non masqué (minimum) - Niveau AA
Ce critère garantit qu'un élément qui reçoit le focus clavier ne soit pas entièrement masqué par du contenu superposé comme des en-têtes fixes, des bannières de cookies ou des fenêtres modales. Au minimum, une partie de l'élément doit rester visible à l'écran. Par exemple, si vous naviguez au clavier sur un site avec un menu sticky de 80px, les éléments focalisés ne doivent pas disparaître complètement derrière ce menu.
La solution technique la plus courante consiste à implémenter un scroll automatique avec un offset correspondant à la hauteur des éléments fixes. En JavaScript, utilisez `element.scrollIntoView({block: 'center'})` plutôt que `'start'` pour centrer l'élément focalisé. Les frameworks CSS comme Tailwind proposent désormais des utilitaires `scroll-mt-*` pour gérer ces offsets de manière déclarative.
2.4.12 Focus non masqué (amélioré) - Niveau AAA
Version renforcée du critère 2.4.11, ce critère AAA exige que l'élément focalisé soit entièrement visible, sans aucune partie masquée par du contenu superposé. Cela va au-delà du minimum AA qui tolère un masquage partiel. Ce niveau d'exigence profite particulièrement aux utilisateurs avec troubles de l'attention ou déficiences visuelles légères qui ont besoin de voir l'intégralité du contexte.
Pour satisfaire ce critère, ajustez les marges de scroll pour garantir une visibilité totale. Testez avec des éléments de grande taille comme des cartes ou des formulaires complexes. Une approche consiste à calculer dynamiquement l'espace nécessaire : `const offset = header.offsetHeight + 20`, puis appliquer `scroll-margin-top: calc(var(--header-height) + 20px)` en CSS.
2.4.13 Apparence du focus - Niveau AAA
Ce critère définit des exigences précises pour l'indicateur de focus : il doit avoir une aire minimale équivalente à un périmètre de 2px CSS autour du composant, un ratio de contraste d'au moins 3:1 avec les couleurs adjacentes, et ne pas être masqué par d'autres contenus. Cela remplace les recommandations floues des versions précédentes par des métriques mesurables.
En pratique, un outline de 2px solide avec une couleur contrastée suffit généralement. Évitez les `outline: none` sans alternative. Pour les designs épurés, utilisez `outline-offset: 2px` pour détacher visuellement le focus de l'élément. Les propriétés CSS `:focus-visible` permettent d'afficher le focus uniquement lors de navigation clavier, évitant ainsi de perturber les utilisateurs de souris tout en respectant l'accessibilité.
2.5.7 Mouvements de glissement - Niveau AA
Tout mécanisme nécessitant un mouvement de glissement (drag-and-drop, swipe, slider) doit proposer une alternative utilisable avec des actions simples comme des clics ou des pressions. Ce critère reconnaît que les gestes complexes posent problème aux personnes avec tremblements, précision réduite ou utilisant des technologies d'assistance.
Pour un carrousel tactile, ajoutez des boutons Précédent/Suivant. Pour un curseur de fourchette de prix, proposez des champs de saisie numériques en complément. Sur les tableaux Kanban avec drag-and-drop, implémentez un menu contextuel avec options "Déplacer vers..." accessibles au clavier. La librairie React DnD Kit offre un support clavier natif pour ces cas d'usage.
2.5.8 Taille de cible (minimum) - Niveau AA
Les cibles interactives doivent mesurer au minimum 24×24 pixels CSS, sauf exceptions définies (éléments inline dans une phrase, contrôles natifs du navigateur, présentation essentielle). Ce critère est moins strict que le 2.5.5 de niveau AAA qui exigeait 44×44px, reconnaissant ainsi les contraintes d'interfaces denses tout en garantissant un minimum d'accessibilité.
Pour respecter ce critère, utilisez `min-width: 24px; min-height: 24px` sur tous les boutons, liens et contrôles. Si l'icône visible est plus petite, étendez la zone cliquable avec du padding transparent. En CSS : `padding: 8px; margin: -8px;` agrandit la zone interactive sans modifier l'apparence. Les frameworks comme Chakra UI et Material-UI appliquent désormais ces dimensions par défaut sur leurs composants.
3.2.6 Aide cohérente - Niveau A
Lorsqu'un mécanisme d'aide apparaît sur plusieurs pages (contact, FAQ, chatbot), il doit être positionné de manière cohérente dans l'ordre relatif de la page. Si le lien "Contactez-nous" apparaît en 3ᵉ position dans le footer de la page d'accueil, il doit occuper la même position relative sur toutes les pages où il apparaît.
Cette cohérence réduit la charge cognitive pour les utilisateurs ayant des troubles de mémoire ou d'orientation. En pratique, créez des composants de footer/header réutilisables avec ordre d'éléments fixe. Attention aux variations responsives : l'ordre doit rester cohérent entre desktop et mobile, quitte à utiliser `order` en flexbox pour réorganiser visuellement tout en préservant l'ordre DOM.
3.3.7 Saisie redondante - Niveau A
Les informations déjà saisies par l'utilisateur dans un processus ne doivent pas être demandées une seconde fois, sauf si c'est essentiel pour la sécurité, que l'information précédente n'est plus valide, ou que l'utilisateur peut modifier les données. Ce critère cible les tunnels de commande, formulaires multi-étapes et processus d'inscription où redemander l'adresse ou le nom devient une friction inutile.
Implémentez la persistance avec sessionStorage pour les données temporaires ou localStorage pour les préférences durables. Pour les formulaires complexes, utilisez des librairies comme React Hook Form avec `defaultValues` chargées depuis le contexte. Les attributs HTML5 `autocomplete` aident également les navigateurs à pré-remplir les champs standards (name, email, address-line1, etc.).
3.3.8 Authentification accessible (minimum) - Niveau AA
Les processus d'authentification ne doivent pas reposer sur des tests cognitifs comme mémoriser des mots de passe complexes ou résoudre des CAPTCHA visuels. Les gestionnaires de mots de passe, l'authentification biométrique, les codes par email ou SMS, et les liens magiques constituent des alternatives acceptables. Ce critère reconnaît que la sécurité et l'accessibilité ne sont pas incompatibles.
En pratique, ajoutez `autocomplete="username"` et `autocomplete="current-password"` sur vos champs de connexion pour permettre aux gestionnaires de mots de passe de fonctionner. Remplacez les CAPTCHA visuels par reCAPTCHA v3 (scoring invisible) ou hCaptcha en mode accessible. Pour l'authentification multi-facteurs, proposez plusieurs options : SMS, email, application d'authentification, clé de sécurité physique.
3.3.9 Authentification accessible (améliorée) - Niveau AAA
Ce niveau AAA va plus loin en éliminant tous les tests cognitifs, y compris la reconnaissance d'objets ou la transcription de texte. Seuls les mécanismes ne nécessitant aucun effort de mémorisation ou de reconnaissance sont acceptés : biométrie, tokens physiques, liens magiques, authentification déléguée (OAuth avec Google/Microsoft).
Pour atteindre ce niveau, implémentez WebAuthn pour l'authentification sans mot de passe via clés de sécurité ou biométrie. Les librairies comme SimpleWebAuthn (Node.js) ou Passkey (Python) simplifient l'intégration. Proposez OAuth comme alternative principale : les utilisateurs s'authentifient via un compte existant sans créer de nouvelles credentials à mémoriser.
Critère supprimé : 4.1.1 Parsing
Le critère 4.1.1 qui exigeait un code HTML valide sans erreurs de parsing a été retiré de WCAG 2.2. Cette décision reconnaît que les navigateurs modernes implémentent désormais le parsing HTML5 de manière cohérente et tolèrent les erreurs mineures sans impact sur l'accessibilité. Les technologies d'assistance s'appuient sur l'arbre d'accessibilité (accessibility tree) généré par le navigateur plutôt que sur le DOM brut.
Cette suppression ne signifie pas que la qualité du code HTML n'est plus importante. Un HTML sémantique et bien structuré reste essentiel pour satisfaire d'autres critères WCAG, notamment 1.3.1 Info et relations, 4.1.2 Nom, rôle et valeur, et 4.1.3 Messages de statut. Validez votre HTML avec le W3C Validator pour détecter les erreurs graves, mais ne vous focalisez plus sur la conformité stricte comme exigence d'accessibilité.
Ce que l'Acte européen sur l'accessibilité exige
L'European Accessibility Act (EAA), qui entrera en vigueur en juin 2025, fait référence à la norme EN 301 549 v3.2.1, elle-même basée sur WCAG 2.1 niveau AA. Techniquement, la conformité WCAG 2.1 AA suffit donc pour respecter les obligations légales européennes. Cependant, de nombreux experts recommandent de viser directement WCAG 2.2 pour plusieurs raisons stratégiques.
Premièrement, WCAG 2.2 étant rétrocompatible, la conformité 2.2 garantit automatiquement la conformité 2.1 et donc l'EAA. Deuxièmement, la norme EN 301 549 sera mise à jour pour intégrer WCAG 2.2 dans les prochaines révisions, anticipant cette évolution vous évite une seconde migration. Enfin, les 9 nouveaux critères de WCAG 2.2 corrigent des lacunes réelles d'accessibilité identifiées par les utilisateurs, améliorer votre conformité dès maintenant bénéficie directement à vos utilisateurs.
Devriez-vous viser WCAG 2.2 ?
La réponse est oui pour la plupart des organisations, particulièrement si vous démarrez un nouveau projet ou planifiez une refonte. La rétrocompatibilité avec WCAG 2.1 signifie qu'aucun travail existant n'est perdu : vous construisez sur des fondations solides plutôt que de repartir de zéro. Les 9 nouveaux critères représentent un effort de mise en conformité modéré par rapport aux bénéfices d'accessibilité apportés.
Pour les sites déjà conformes WCAG 2.1 AA, priorisez les 5 nouveaux critères AA (2.4.11, 2.5.7, 2.5.8, 3.3.7, 3.3.8) qui constituent l'écart minimal vers WCAG 2.2 AA. Les deux critères A (3.2.6, 3.3.7 déjà mentionné) sont généralement simples à implémenter. Les critères AAA (2.4.12, 2.4.13, 3.3.9) peuvent attendre une phase 2 sauf si votre audience inclut une forte proportion d'utilisateurs avec handicaps cognitifs ou moteurs.
Comment tester la conformité WCAG 2.2
Le test de conformité WCAG 2.2 combine outils automatisés et audits manuels. Les outils automatisés comme Axe DevTools, WAVE ou Pa11y détectent environ 30-40% des problèmes d'accessibilité, principalement techniques (contraste, attributs alt, labels de formulaires). Pour WCAG 2.2, vérifiez que votre outil de test est à jour : Axe Core 4.8+ et Pa11y 7.0+ supportent les nouveaux critères.
La checklist manuelle pour WCAG 2.2 inclut : testez la navigation clavier complète avec focus toujours visible derrière headers fixes (2.4.11), mesurez les zones de clic avec l'inspecteur navigateur pour vérifier le 24×24px minimum (2.5.8), parcourez un processus multi-étapes pour confirmer l'absence de saisies redondantes (3.3.7), tentez de vous connecter avec un gestionnaire de mots de passe (3.3.8), vérifiez les alternatives aux drag-and-drop (2.5.7), et confirmez la position cohérente des mécanismes d'aide entre pages (3.2.6). Pour un audit complet, engagez des utilisateurs en situation de handicap pour des tests réels.