Scan gratuit

26 octobre 2026

Authentification accessible et CAPTCHA : ce qu'exige le critère WCAG 3.3.8

Une authentification accessible, au sens du critère de succès 3.3.8 des WCAG (niveau AA), est une connexion qui n'oblige pas l'utilisateur à résoudre, mémoriser ou recopier quelque chose. Le texte du W3C est précis : aucun test de fonction cognitive, comme se souvenir d'un mot de passe ou résoudre un puzzle, ne doit être exigé à une étape du processus d'authentification, sauf si cette étape propose une alternative, un mécanisme d'aide, ou si le test consiste à reconnaître des objets ou à identifier un contenu non textuel que l'utilisateur a lui-même fourni. En pratique, un CAPTCHA à texte déformé ou à calcul mental, ou un champ de mot de passe qui bloque le collage, ne passent pas ce critère s'il n'existe aucune autre voie de connexion. Un formulaire avec identifiant et mot de passe reste en revanche acceptable s'il laisse le navigateur et les gestionnaires de mots de passe remplir les champs et accepte le copier-coller, à condition que les autres étapes respectent elles aussi le critère. Cet article détaille ce qui est interdit, ce qui est permis, puis les alternatives au CAPTCHA présentées dans la note « Inaccessibility of CAPTCHA » publiée sur le site du W3C.

Que dit le critère 3.3.8 Authentification accessible (minimum) ?

L'objectif affiché par le W3C est de rendre la connexion possible avec moins d'effort mental. Certaines personnes ayant un handicap cognitif ne peuvent pas résoudre des puzzles, mémoriser un identifiant et un mot de passe, ou ressaisir des codes à usage unique. Le W3C considère explicitement que mémoriser un mot de passe propre à un site est un test de fonction cognitive, et rappelle que retenir une suite de caractères aléatoires ou un geste à effectuer sur un écran tactile exclut certaines personnes.

Le critère ne vise pas toutes les étapes de la vie d'un compte de la même façon. Il porte sur l'authentification des utilisateurs existants et ne couvre pas la création d'un identifiant ou l'ouverture d'un compte, même si les mêmes techniques (autoriser le collage, ne pas imposer de transcription) allègent aussi l'inscription. En revanche, la récupération ou la modification de l'e-mail et du mot de passe fait partie de l'authentification : si l'utilisateur doit fournir d'autres informations pour récupérer son compte, il faut une méthode qui ne soit pas un test cognitif.

Authentification accessible et CAPTCHA : ce qui est interdit

Toutes les étapes comptent. Avec une authentification multifacteur, chaque étape doit respecter le critère : il doit exister un chemin complet de connexion qui ne repose sur aucun test cognitif. Le critère s'applique aussi aux CAPTCHA et tests qui n'apparaissent que dans certaines situations, par exemple en présence d'un bloqueur de publicité ou après plusieurs saisies erronées du mot de passe.

Le W3C répertorie notamment l'échec F109 : échec des critères 3.3.8 et 3.3.9 dû au fait d'empêcher la ressaisie d'un mot de passe ou d'un code dans le même format. La page décrit aussi des cas concrets qui forcent la transcription ou relèvent d'un test cognitif, et qui posent problème lorsqu'aucune autre méthode d'authentification sans test cognitif n'est proposée :

Ce qui est permis : gestionnaire de mots de passe, copier-coller et méthodes sans test

L'identifiant (ou l'e-mail) et le mot de passe restent utilisables, à condition de laisser le navigateur et les gestionnaires de mots de passe tiers remplir les champs. Selon le W3C, si le formulaire respecte le critère 1.3.5 (Input Purpose) et que les champs ont un nom accessible conforme au critère 4.1.2 (Name, Role, Value), les navigateurs et gestionnaires devraient pouvoir les reconnaître et les remplir de façon fiable. Le copier-coller permet aussi d'éviter la transcription : l'utilisateur copie ses identifiants depuis un gestionnaire autonome et les colle dans le formulaire.

Les techniques suffisantes listées par le W3C incluent l'authentification par lien envoyé par e-mail (G218) et des champs e-mail et mot de passe correctement balisés (H100). Les exemples cités sur la page incluent aussi :

Le cas des CAPTCHA de reconnaissance d'objets et du contenu personnel

Un CAPTCHA demandant de sélectionner toutes les images contenant une voiture relève de l'exception « reconnaissance d'objets » au niveau AA. Un objet s'entend ici comme une chose matérielle que l'on peut voir et toucher, y compris des véhicules et des animaux. Mais dès que le test va au-delà de la reconnaissance, par exemple multiplier le nombre de chats par le nombre de chiens, l'exception ne s'applique plus. Et un test fondé sur un élément fixé par le site, comme retenir ou recopier un mot, est bien un test de fonction cognitive.

Le contenu personnel fonctionne ainsi : à la création du compte, l'utilisateur téléverse une image, puis la sélectionne parmi plusieurs propositions lors de la connexion. Le W3C demande alors de veiller à la sécurité, car une personne non légitime pourrait deviner la bonne image. Surtout, il rappelle que ces deux exceptions ne soutiennent pas pleinement les personnes concernées par l'accessibilité cognitive et devraient être évitées si possible : elles ne sont pas acceptées par le critère 3.3.9 Authentification accessible (renforcée), de niveau AAA.

Enfin, le W3C signale qu'une option pour afficher le mot de passe en clair peut améliorer les chances de réussite de certaines personnes, quand une saisie reste nécessaire, par exemple pour créer un mot de passe enregistré ensuite par un gestionnaire.

Codes de vérification et double authentification

Un service qui impose la transcription manuelle d'un code de vérification n'est pas conforme. Il doit au minimum être possible de coller le code (depuis un gestionnaire de mots de passe, une application de SMS ou une clé de sécurité logicielle) et de laisser le navigateur remplir le champ automatiquement.

Lorsque le code arrive sur un second appareil, par exemple un SMS reçu sur un téléphone pour une connexion sur un ordinateur portable, la question du transfert du code entre appareils est hors du périmètre du critère. Pour l'évaluation, on suppose que le code est disponible dans le presse-papiers : il suffit donc de vérifier que le champ du code accepte bien le collage. Le W3C précise enfin que les systèmes à deux facteurs qui ne reposent pas sur des codes ne sont pas des tests cognitifs : clés matérielles comme une YubiKey, applications qui demandent de confirmer que c'est bien vous qui vous connectez, ou méthodes du système d'exploitation comme Windows Hello, Touch ID et Face ID.

Pourquoi la note « Inaccessibility of CAPTCHA » juge les CAPTCHA inaccessibles

La note « Inaccessibility of CAPTCHA » est un projet de note de groupe (Group Draft Note) du 16 décembre 2021, publié par le groupe de travail Accessible Platform Architectures. C'est une mise à jour de la note publiée en 2019 ; elle n'est pas endossée par le W3C ni ses membres et se présente comme un travail en cours. Son constat est net : la nature même de la tâche interactive exclut de nombreuses personnes handicapées, ce qui revient à leur refuser le service.

Les exemples sont parlants. Demander à des personnes aveugles, malvoyantes ou dyslexiques de lire des caractères déformés, c'est leur demander la tâche qu'elles sont le moins à même d'accomplir ; il en va de même pour un CAPTCHA audio face aux personnes sourdes ou malentendantes. Les CAPTCHA traditionnels supposent aussi souvent la maîtrise de l'anglais, et un dispositif qui prévoit plusieurs tentatives comme allant de soi est, selon la note, sans doute inaccessible par conception aux personnes souffrant d'un trouble anxieux, ainsi qu'à de nombreuses personnes ayant d'autres handicaps cognitifs ou d'apprentissage. La note cite également des données de Cloudflare selon lesquelles il faut en moyenne 32 secondes pour résoudre un CAPTCHA.

La note souligne en outre que l'efficacité du CAPTCHA comme solution de sécurité diminue : les approches à base d'images, de problèmes logiques ou d'audio peuvent être largement cassées par des algorithmes. Elle cite une étude de l'université du Maryland ayant obtenu 90 % de réussite contre le reCAPTCHA audio de Google.

Les alternatives au CAPTCHA présentées dans la note

Les auteurs de la note sur les CAPTCHA préfèrent, à conditions égales, les approches non interactives, car elles ne posent pas de difficulté d'accessibilité, tout en signalant qu'elles peuvent exposer des données personnelles de l'utilisateur. La page Understanding du critère 3.3.8 mentionne aussi la limitation du débit d'accès, la géolocalisation du client et l'authentification privée du client : aucune n'est efficace à 100 %, mais elles peuvent réduire la probabilité d'afficher un CAPTCHA.

Comment vérifier votre parcours de connexion

Parcourez chaque étape, y compris la double authentification, la récupération de compte et les tests qui ne se déclenchent qu'après des erreurs. Collez un mot de passe et un code depuis un gestionnaire : ils doivent être acceptés en entier. Vérifiez que le gestionnaire de mots de passe remplit les champs et que ceux-ci ont un nom accessible. Si un CAPTCHA subsiste, assurez-vous qu'une autre voie de connexion sans test cognitif existe. Pour le reste de vos pages, un test gratuit et une surveillance continue avec Conformly vous aident à suivre votre niveau d'accessibilité dans le temps.

Questions fréquentes

Le CAPTCHA est-il interdit par les WCAG ?

Pas en soi. Le critère 3.3.8 exige qu'une étape d'authentification ne repose pas sur un test cognitif sans alternative ou mécanisme d'aide ; un CAPTCHA de reconnaissance d'objets reste admis au niveau AA. Par ailleurs, la note du W3C rappelle que les WCAG autorisent les CAPTCHA s'ils ont une alternative textuelle décrivant leur fonction et des formes alternatives utilisant d'autres modes de perception.

Bloquer le copier-coller du mot de passe est-il conforme au critère 3.3.8 ?

Non. Empêcher le collage dans les champs d'authentification force la transcription et fait échouer le critère, sauf si une autre méthode d'authentification sans test cognitif est proposée.

Un CAPTCHA « sélectionnez les voitures » est-il accessible ?

Il bénéficie de l'exception de reconnaissance d'objets prévue au critère 3.3.8 (niveau AA), mais cette exception n'existe pas au critère 3.3.9 (niveau AAA). Le W3C recommande de l'éviter si possible, et l'exception tombe dès que le test va au-delà de la simple reconnaissance. Toutes les autres étapes de l'authentification doivent aussi respecter le critère.

L'alternative audio d'un CAPTCHA suffit-elle ?

Non, si l'utilisateur doit transcrire ce qu'il entend : elle ne peut pas servir d'alternative au sens du critère 3.3.8. La note sur les CAPTCHA ajoute que les CAPTCHA audio imposent à tous les utilisateurs une surcharge cognitive par rapport à la compréhension d'une parole normale, et que transcrire un CAPTCHA audio est précisément la tâche que les personnes sourdes, malentendantes ou ayant un trouble du traitement auditif sont le moins susceptibles d'accomplir.

Le critère 3.3.8 s'applique-t-il à la création de compte ?

Non, il porte sur l'authentification des utilisateurs existants, y compris la récupération du compte. Autoriser le collage et éviter la transcription allègent toutefois aussi l'inscription.

Quelle est l'alternative la plus accessible au CAPTCHA ?

Les auteurs de la note sur les CAPTCHA préfèrent les approches non interactives, comme le honeypot, le filtrage du spam, les heuristiques ou la preuve de travail, qui selon eux ne posent pas de difficulté d'accessibilité, tout en notant qu'elles peuvent exposer des données personnelles. Ils conseillent d'adapter le niveau de protection au risque réel, par exemple en utilisant un honeypot tant qu'il suffit.

À lire aussi sur Conformly

Sources

Article appuyé sur les sources officielles citées en fin de page.