Aller au contenu
Antisy

CAPTCHA et accessibilité : ce que disent les WCAG et le W3C

Un CAPTCHA demande à une personne de prouver qu’elle est humaine, et certaines ne peuvent pas le faire : une image à reconnaître pour quelqu’un qui ne la voit pas, des lettres déformées pour quelqu’un qui lit difficilement. La norme d’accessibilité du W3C, les WCAG 2.2, contient deux critères qui le concernent ; le W3C recommande aussi d’en demander aussi peu que possible.

État au .

Par Thibault Peray, fondateur d’Antisy Sàrl. · Tous les articles

Pourquoi un CAPTCHA pose-t-il un problème d’accessibilité ?

Parce qu’une épreuve suppose une capacité : voir, entendre, lire, se souvenir, viser avec précision. Un CAPTCHA qui repose sur une seule d’entre elles ferme la porte aux personnes qui ne l’ont pas, à l’endroit même où le visiteur veut écrire, s’inscrire ou se connecter.

Voir : Glossaire : CAPTCHA

Que disent les WCAG 2.2 du CAPTCHA ?

Les WCAG 2.2 sont une Recommandation du W3C, publiée une première fois le 5 octobre 2023 ; la version lue ici est celle du 12 décembre 2024. Deux de leurs critères touchent le CAPTCHA. Les citations ci-dessous sont celles de la traduction française publiée par le W3C ; en cas de litige, l’anglais fait foi.

Le critère 1.1.1, « Contenu non textuel » (niveau A), exige un équivalent textuel pour tout contenu non textuel, sauf dans des situations qu’il énumère. Celle du CAPTCHA : « si ce contenu non textuel vise à confirmer que le contenu est consulté par une personne plutôt que par un ordinateur, alors un équivalent textuel est fourni pour identifier et décrire la fonction du contenu non textuel, et des formes alternatives du CAPTCHA sont proposées pour différents types de perception sensorielle afin d’accommoder différents types de limitations fonctionnelles. »

Le critère 3.3.8, « Authentification accessible (minimum) » (niveau AA) : « Aucune étape d’un processus d’authentification ne requiert de test cognitif (comme la mémorisation d’un mot de passe ou la résolution d’une énigme), à moins que cette étape ne fournisse au moins l’un des éléments suivants : » (chacun est introduit par son nom dans la norme)

  • Alternative : « une autre méthode d’authentification, qui ne repose pas sur un test cognitif. »
  • Mécanisme : « un mécanisme est disponible pour aider l’utilisateur à compléter le test cognitif. »
  • Reconnaissance d’objets : « le test cognitif consiste à reconnaître des objets. »
  • Contenu personnel : « le test cognitif consiste à identifier un contenu non textuel que l’utilisateur a fourni au site web. »

Le document d’explication du W3C en tire cette conséquence : si un CAPTCHA fait partie d’une authentification, il doit exister une méthode sans test cognitif, sauf si le test relève d’une exception. La reconnaissance d’objets et le contenu personnel sont des exceptions au niveau AA, mais pas au niveau AAA (critère 3.3.9), et le document recommande de les éviter si possible. Une alternative audio qu’il faut retranscrire ne remplit pas l’exception « Alternative ».

Le critère 3.3.8 vise la connexion à un compte existant : le document d’explication précise qu’il ne couvre ni la création d’un identifiant ni l’ouverture d’un compte. Le critère 1.1.1 vise le contenu non textuel d’un CAPTCHA, où qu’il soit, y compris dans un formulaire de contact.

Que dit le W3C des alternatives ?

Le groupe de travail du W3C sur l’accessibilité (Accessible Platform Architectures) a rédigé une note, « Inaccessibility of CAPTCHA », en anglais. La version lue est une version de travail de cette note, datée du 16 décembre 2021 : le W3C et ses membres ne l’ont pas approuvée, et le document indique qu’il ne faut la citer que comme un travail en cours. Ses conclusions, résumées :

  • un visiteur ne devrait pas subir plus d’épreuves que ce que la sécurité du site exige strictement ;
  • quand un CAPTCHA interactif est jugé nécessaire, il est très utile de limiter autant que possible la fréquence à laquelle il est montré, et il faut proposer plusieurs épreuves alternatives, qui font appel à différentes capacités sensorielles et cognitives ;
  • le W3C préfère les approches sans interaction, qui ne posent pas de difficulté d’accessibilité ; elles peuvent en revanche exposer l’utilisateur à une collecte de données personnelles ;
  • il n’existe pas de solution idéale : l’objectif et l’efficacité de tout CAPTCHA déployé doivent être examinés avant son adoption, puis suivis de près.

Que faire concrètement ?

  • Enlevez l’épreuve quand vous le pouvez : validation côté serveur, limitation des envois et contrôle anti-bot invisible (on parle parfois de « CAPTCHA invisible ») ne demandent rien au visiteur.
  • Si vous gardez un CAPTCHA, offrez plusieurs formes d’épreuve, et sur une connexion un moyen de s’en passer.
  • Prévoyez un autre moyen de vous joindre quand un envoi est refusé : une adresse e-mail, par exemple.
  • Testez au clavier seul et avec un lecteur d’écran, puis suivez les refus à tort après la mise en service.
  • Regardez ce qu’un contrôle sans épreuve mesure : le W3C rappelle qu’il peut exposer des données personnelles.

Voir : Glossaire : CAPTCHA invisible · Questions fréquentes : Antisy risque-t-il de bloquer de vrais visiteurs ? · Documentation : données collectées et vie privée

Où Antisy se place

Antisy n’affiche rien au visiteur : ni case à cocher ni énigme. Il n’y a donc pas d’épreuve à rendre accessible. Cela ne rend pas un formulaire accessible pour autant, et Antisy ne dit pas que votre formulaire respecte les WCAG : les libellés, les contrastes, la navigation au clavier restent ceux de votre formulaire.

Le contrôle a ses propres limites, que le site dit. Le navigateur fait un court calcul en arrière-plan : un appareil très lent qui ne l’achève pas à temps est refusé, quel que soit le mode. Si le script est bloqué, le formulaire part sans jeton, et un envoi sans jeton ne passe pas quand la collecte du navigateur est allumée pour le site. La réponse est allow ou deny, sans raison : à vous de prévoir une page de refus qui offre un autre moyen de vous joindre.

Antisy n’annonce aucun taux de détection.

Voir : Questions fréquentes : quelle différence avec un CAPTCHA ? · Glossaire : calcul en arrière-plan · Documentation : si le script ne tourne pas · Documentation : un vrai visiteur est refusé · Documentation : à quel point refuser · Accueil : ce que le script mesure, et combien de temps

Où en est Antisy ?

L’accès se fait sur liste d’attente. L’API et le tableau de bord sont en service depuis le 27 octobre 2026, hébergés chez Infomaniak à Genève ; aucun client n’est encore en production. Le pilote a commencé le 9 novembre 2026 sur nos propres formulaires.

Voir : Le pilote · Rejoindre la liste d’attente

Questions fréquentes

Un CAPTCHA est-il autorisé par les WCAG ?

Elles ne l’interdisent pas, elles posent des conditions : pour un CAPTCHA fait de contenu non textuel, un équivalent textuel et des formes alternatives (critère 1.1.1) ; pour une authentification, une méthode sans test cognitif, sauf exceptions (critère 3.3.8).

Les WCAG sont-elles obligatoires ?

Ce sont une norme technique du W3C. Leur caractère obligatoire dépend du droit applicable à votre organisation, que cet article ne traite pas : adressez-vous à la personne qui vous conseille en droit.

Un contrôle invisible est-il accessible ?

Il n’impose pas d’épreuve, donc il n’a pas cette barrière-là. Il peut en avoir d’autres, comme un refus à tort, et il mesure des données du navigateur. Testez-le avec vos visiteurs avant la mise en production.

Voir aussi : Spam sur un formulaire de contact : que faire, mesure par mesure · Cas d’usage : protéger une connexion · Cas d’usage : protéger un formulaire de contact · Comparatifs : ce que chaque service affiche, d’après sa documentation · Questions fréquentes : Antisy arrête-t-il tous les robots ?