WCAG 2.2 — Les 9 nouveaux critères d'accessibilité expliqués
Le W3C a publié les WCAG 2.2 en octobre 2023. Voici les nouveaux critères et comment les appliquer.
WCAG 2.2 en bref
Les WCAG (Web Content Accessibility Guidelines = directives d'accessibilité des contenus web) sont le standard international de référence pour l'accessibilité numérique, publié par le W3C (World Wide Web Consortium). La version 2.2, publiée le 5 octobre 2023, est la mise à jour la plus récente.
9
Nouveaux critères de succès ajoutés
1
Critère retiré (4.1.1 Parsing)
3
Niveaux couverts : A, AA et AAA
Critère retiré : Le critère 4.1.1 « Parsing » a été supprimé car les technologies d'assistance modernes ne parsent plus directement le HTML. Les navigateurs corrigent automatiquement les erreurs de balisage, rendant ce critère obsolète.
Les 9 nouveaux critères détaillés
Les nouveaux critères couvrent trois axes majeurs : la navigation au clavier, les interactions tactiles et l'authentification accessible.
2.4.11Focus non masqué (minimum)
Quand un élément interactif reçoit le focus clavier, il ne doit pas être entièrement masqué par d'autres éléments de la page (bandeau cookie, en-tête fixe, modale, barre latérale).
Exemple : Un lien dans le pied de page reçoit le focus, mais un bandeau cookie fixé en bas le recouvre complètement. L'utilisateur ne sait pas où se trouve le focus.
Impact utilisateur : Les utilisateurs naviguant au clavier (handicap moteur, malvoyants avec zoom) perdent le repère visuel du focus et ne peuvent pas interagir avec l'élément masqué.
2.4.12Focus non masqué (amélioré)
Version renforcée du critère 2.4.11 : l'élément recevant le focus doit être entièrement visible, pas seulement partiellement. Aucune partie ne doit être masquée.
Exemple : Un bouton d'action reçoit le focus, mais un en-tête fixe (sticky header) recouvre la moitié supérieure du bouton. Même si une partie est visible, ce n'est pas suffisant.
Impact utilisateur : Garantit une expérience optimale pour les utilisateurs au clavier en s'assurant que l'indicateur de focus est toujours entièrement visible et lisible.
2.4.13Apparence du focus
L'indicateur de focus doit avoir une taille minimale (au moins 2 pixels de contour autour du périmètre du composant) et un contraste suffisant (ratio de 3:1 minimum).
Exemple : Un champ de formulaire avec un outline de focus de 1 pixel en gris clair sur fond blanc : le contraste est insuffisant et l'indicateur trop fin.
Impact utilisateur : Les personnes malvoyantes ou avec des troubles de l'attention ont besoin d'un indicateur de focus clairement visible pour suivre leur position dans la page.
2.5.7Mouvements de glissement
Toute fonctionnalité utilisant un mouvement de glissement (drag-and-drop, swipe, slider) doit avoir une alternative accessible via un simple clic ou pression.
Exemple : Un carrousel d'images nécessitant un swipe pour naviguer doit aussi proposer des boutons « Précédent » et « Suivant ».
Impact utilisateur : Les personnes avec un handicap moteur (tremblements, paralysie partielle) ne peuvent pas toujours effectuer des gestes de glissement précis. L'alternative via simple clic leur permet d'utiliser la fonctionnalité.
2.5.8Taille de cible (minimum)
Les zones interactives (boutons, liens, cases à cocher) doivent mesurer au moins 24x24 pixels CSS, ou disposer d'un espacement suffisant pour compenser une taille plus petite.
Exemple : Une icône de fermeture (X) de 16x16 pixels sans marge suffisante autour : trop petite pour être cliquée facilement sur mobile ou par une personne avec des tremblements.
Impact utilisateur : Les utilisateurs sur mobile, les personnes âgées et celles avec un handicap moteur ont besoin de cibles suffisamment grandes pour éviter les erreurs de clic.
3.2.6Aide cohérente
Les mécanismes d'aide (lien de contact, chat, FAQ, numéro de téléphone) doivent apparaître au même endroit relatif sur chaque page du site.
Exemple : Le lien « Contactez-nous » est dans le pied de page sur la page d'accueil mais dans l'en-tête sur la page produit. L'utilisateur doit chercher à chaque page.
Impact utilisateur : Les personnes avec des troubles cognitifs ou des difficultés d'apprentissage comptent sur la cohérence de la navigation pour trouver l'aide dont elles ont besoin.
3.3.7Saisie redondante
Les informations déjà fournies par l'utilisateur dans un même processus ne doivent pas être redemandées, sauf si c'est essentiel (confirmation de mot de passe, par exemple).
Exemple : Un formulaire de commande en 3 étapes qui redemande l'adresse e-mail à chaque étape, alors qu'elle a été saisie à la première.
Impact utilisateur : Les personnes avec des troubles cognitifs, des difficultés motrices ou utilisant des technologies d'assistance trouvent la saisie répétée fatigante et source d'erreurs.
3.3.8Authentification accessible (minimum)
Les processus d'authentification ne doivent pas reposer sur des tests cognitifs (mémorisation de mot de passe, CAPTCHA visuel, puzzle) sans proposer d'alternative accessible.
Exemple : Un CAPTCHA demandant de reconnaître des objets dans des images sans alternative audio ou possibilité de coller un mot de passe depuis un gestionnaire.
Impact utilisateur : Les personnes avec des troubles cognitifs, des déficiences visuelles ou des difficultés de mémorisation sont bloquées par les CAPTCHA et les tests de mémorisation.
3.3.9Authentification accessible (amélioré)
Extension du critère 3.3.8 avec des conditions plus strictes : aucun test cognitif ne doit être requis, même avec des alternatives. L'authentification doit être possible sans effort de mémorisation ou de résolution.
Exemple : Le site propose uniquement une connexion par mot de passe sans possibilité de coller, ni de connexion par lien e-mail ou biométrie.
Impact utilisateur : Garantit l'accès aux services numériques pour tous les utilisateurs, y compris ceux avec des handicaps cognitifs sévères, en éliminant toute barrière cognitive à l'authentification.
WCAG 2.2 et le RGAA
Le RGAA (Référentiel Général d'Amélioration de l'Accessibilité) est le cadre technique français pour l'accessibilité numérique. Le RGAA 4.1 actuel est basé sur les WCAG 2.1. Le RGAA 5, prévu fin 2026, intégrera les WCAG 2.2 et leurs 9 nouveaux critères.
Norme EN 301 549
La norme européenne EN 301 549 référence désormais les WCAG 2.2. Le RGAA 5 s'alignera sur cette norme pour garantir la conformité européenne.
EAA (European Accessibility Act)
L'EAA (loi européenne sur l'accessibilité), en vigueur depuis juin 2025, exige la conformité aux WCAG 2.2 pour les entreprises de l'UE. Le RGAA 5 sera l'outil technique français pour répondre à cette obligation.
Calendrier RGAA 5
Publication prévue fin 2026. Les déclarations RGAA 4.1 existantes resteront valides 18 mois après la publication, laissant le temps de migrer.
Pas d'attente nécessaire
La DINUM recommande de ne pas attendre le RGAA 5 pour agir. Un audit RGAA 4.1 aujourd'hui couvre déjà plus de 90 % des exigences du futur RGAA 5.
Ce qui est automatisable
Sur les 9 nouveaux critères WCAG 2.2, un seul est entièrement automatisable par les outils de test comme axe-core : le critère 2.5.8 Target Size (Minimum). Les 8 autres nécessitent une vérification manuelle ou semi-automatisée.
| Critère | Nom | Automatisable |
|---|---|---|
| 2.4.11 | Focus non masqué (min.) | Manuel |
| 2.4.12 | Focus non masqué (amél.) | Manuel |
| 2.4.13 | Apparence du focus | Manuel |
| 2.5.7 | Mouvements de glissement | Manuel |
| 2.5.8 | Taille de cible (min.) | Oui |
| 3.2.6 | Aide cohérente | Manuel |
| 3.3.7 | Saisie redondante | Manuel |
| 3.3.8 | Auth. accessible (min.) | Manuel |
| 3.3.9 | Auth. accessible (amél.) | Manuel |
RGAAudit couvre les deux : les critères automatisables sont testés automatiquement par axe-core, et les critères manuels sont identifiés dans le rapport d'audit avec des guides de vérification intégrés pour vous accompagner.
Auditez votre site dès maintenant
N'attendez pas le RGAA 5 pour vérifier votre accessibilité. Un audit RGAA 4.1 aujourd'hui identifie déjà les non-conformités qui seront contrôlées demain. Anticipez et corrigez avant les sanctions.