WCAG 3.3.8 : Authentification accessible (minimum)

Ce que signifie cette règle

WCAG 3.3.8 Authentification accessible (Minimum) est un critère de niveau AA introduit dans WCAG 2.2. Il stipule qu’un test de fonction cognitive — défini comme une tâche qui exige de l’utilisateur qu’il mémorise, manipule ou retranscrive des informations — ne doit pas être le seul moyen de réaliser une étape d’authentification, à moins qu’au moins une des conditions suivantes ne soit remplie :

• Méthode alternative : Une autre voie d’authentification est disponible et ne repose pas sur un test de fonction cognitive (par exemple, un lien magique envoyé par e-mail, une connexion biométrique ou une passkey).
• Mécanisme d’assistance : L’agent utilisateur ou un outil tiers est autorisé à réaliser l’étape au nom de l’utilisateur — par exemple, un gestionnaire de mots de passe qui remplit automatiquement les identifiants, ou une action de copier-coller pour un code à usage unique.
• Exception de reconnaissance d’objets : Le test de fonction cognitive consiste à identifier un objet dans une image (par exemple, sélectionner toutes les images contenant un feu de circulation) — ce type de test est autorisé au niveau Minimum (AA).
• Exception de contenu personnel : Le test repose sur du contenu fourni par l’utilisateur lui-même, comme sélectionner une photo précédemment téléversée dans une grille.

Concrètement, un formulaire de connexion qui ne demande qu’un nom d’utilisateur et un mot de passe est conforme à ce critère, à condition que le formulaire permette le remplissage automatique par le navigateur et le fonctionnement des gestionnaires de mots de passe (c’est-à-dire que les champs utilisent un <input type='password'> standard et ne bloquent pas le collage). Un CAPTCHA qui exige de retranscrire un texte déformé sans aucune autre voie d’authentification est clairement non conforme. Un CAPTCHA qui demande aux utilisateurs de sélectionner des images correspondant à une catégorie (reconnaissance d’objets) est autorisé au niveau AA mais est traité plus strictement au niveau AAA (3.3.9).

Le critère s’applique à toutes les étapes d’un processus d’authentification : connexion initiale, authentification renforcée, vérification multifacteur, récupération de compte et réauthentification de session. Il s’applique également à tout processus qui protège l’accès à une fonctionnalité, et pas seulement à l’écran principal de connexion.

Une implication technique clé est que les développeurs ne doivent pas utiliser autocomplete='off' sur les champs d’authentification, ne doivent pas désactiver le collage via des gestionnaires d’événements JavaScript, et ne doivent pas rompre les sémantiques d’entrée standard qui permettent aux technologies d’assistance et au remplissage automatique du navigateur de fonctionner correctement.

Pourquoi c’est important

L’authentification est la porte d’entrée de presque tous les services numériques dont les personnes dépendent au quotidien — services bancaires, portails de santé, services publics, e-commerce et plateformes de communication. Lorsque cette porte d’entrée impose des obstacles cognitifs, elle exclut systématiquement une part significative de la population.

Les handicaps cognitifs couvrent un large spectre : dyslexie, dyscalculie, troubles de l’attention, lésions cérébrales acquises, démence, déficiences intellectuelles et troubles anxieux. L’Organisation mondiale de la Santé estime qu’environ 1 personne sur 6 dans le monde présente une forme de handicap significatif, et les troubles cognitifs et neurologiques représentent l’une des plus grandes catégories. Pour ces utilisateurs, des tâches comme retranscrire avec précision une chaîne de caractères déformés, résoudre un puzzle visuel sous pression temporelle, ou passer d’une application d’authentification à un formulaire de connexion peuvent être réellement impossibles ou profondément épuisantes.

Considérons un scénario concret : une personne dyslexique tente de se connecter à son portail d’assurance santé pour consulter des résultats d’examens. Le site présente un CAPTCHA textuel sans alternative audio et sans possibilité de le contourner. Les formes de lettres déformées sont indiscernables pour cette personne, et le champ de saisie bloque le collage. Après plusieurs tentatives infructueuses, le compte est verrouillé. L’utilisateur ne peut pas accéder à des informations médicales sensibles dans les temps. Ce n’est pas un cas hypothétique marginal — c’est une expérience courante pour des millions de personnes.

Les utilisateurs ayant un handicap moteur qui s’appuient sur un accès par contacteur ou des dispositifs de suivi oculaire sont également concernés. Retaper un code à usage unique complexe depuis un appareil distinct, ou faire glisser des vignettes d’images dans un ordre spécifique, peut être physiquement impossible avec ces méthodes de saisie. Autoriser le copier-coller ou l’authentification par passkey supprime entièrement cet obstacle.

Les personnes âgées représentent un autre groupe important. Le déclin cognitif lié à l’âge affecte la mémoire et la vitesse de traitement, ce qui rend les CAPTCHAs complexes et les tâches de mémorisation en plusieurs étapes disproportionnellement difficiles. À mesure que les populations en Turquie et dans le monde vieillissent, l’argument commercial et réglementaire en faveur d’une authentification accessible se renforce chaque année.

Du point de vue de l’ergonomie et de la conversion, les frictions dans les parcours d’authentification augmentent directement les taux d’abandon. Les plateformes d’e-commerce qui remplacent les CAPTCHAs textuels par une authentification basée sur le risque ou des passkeys constatent systématiquement des taux de complétion de connexion plus élevés et des coûts de support plus faibles liés aux comptes verrouillés.

Règles Axe-core associées

WCAG 3.3.8 est classé comme nécessitant des tests manuels, car les outils automatisés ne peuvent pas évaluer pleinement si un processus d’authentification impose un test de fonction cognitive inaccessible. Déterminer si un parcours de connexion n’a pas de voie alternative, ou si le collage est bloqué de manière dépendante du contexte, exige un jugement humain et une interaction avec un flux d’authentification réel. Cela dit, certains contrôles automatisés soutiennent ce critère :

• Revue manuelle — audit du flux d’authentification : Les testeurs doivent parcourir chaque étape d’authentification et déterminer si un test de fonction cognitive est présent, et, le cas échéant, si une alternative conforme ou un mécanisme d’assistance existe. Aucune règle axe-core ne se déclenche actuellement automatiquement pour ce critère, car la logique dépend de la compréhension de la finalité et du contexte des champs de formulaire et de l’interface environnante, et pas seulement de leur balisage.
• Contrôles de l’attribut autocomplete (connexes) : La règle autocomplete-valid d’axe-core signale les champs de saisie dont les valeurs de l’attribut autocomplete ne sont pas tirées de la liste de jetons de WCAG 1.3.5. Bien que cette règle cible directement 1.3.5, c’est un contrôle de soutien pour 3.3.8 : si autocomplete='username' et autocomplete='current-password' sont absents ou mal définis, les gestionnaires de mots de passe ne peuvent pas remplir automatiquement, supprimant le mécanisme d’assistance qui rend la connexion par mot de passe standard conforme à 3.3.8.
• Détection du blocage du collage — manuel : Les analyseurs automatisés ne peuvent pas détecter de manière fiable le JavaScript qui intercepte les événements paste et les supprime sur les champs d’authentification. Un testeur manuel doit tenter de coller un identifiant ou un OTP dans chaque champ pertinent et confirmer que l’action réussit.
• Détection d’alternatives au CAPTCHA — manuel : Axe-core peut détecter la présence de widgets CAPTCHA courants (par exemple, des iframes reCAPTCHA) mais ne peut pas déterminer si une voie d’authentification alternative est proposée ailleurs sur la page ou via un autre parcours. Cette détermination nécessite une inspection manuelle de l’expérience d’authentification complète.

Comment tester

1. Analyse automatisée (axe DevTools / Lighthouse) : Exécutez axe DevTools sur chaque page d’authentification (connexion, inscription, récupération de compte, MFA). Recherchez les violations autocomplete-valid sur les champs de nom d’utilisateur et de mot de passe. Dans Lighthouse, examinez l’audit Accessibilité pour les problèmes liés aux formulaires. Notez qu’aucune règle automatisée ne signalera de manière définitive un échec 3.3.8 — les résultats automatisés ne sont qu’un point de départ.
2. Identifier tous les tests de fonction cognitive : Répertoriez manuellement chaque étape du flux d’authentification. Notez toute étape qui exige de l’utilisateur qu’il se rappelle des informations non fournies sur l’écran actuel, retranscrive des caractères, résolve un puzzle ou effectue un calcul. Vérifiez si chaque étape de ce type dispose d’une alternative conforme (reconnaissance d’objets, contenu personnel, méthode de connexion alternative ou mécanisme d’assistance).
3. Tester la fonctionnalité de collage : Sur chaque champ d’authentification (nom d’utilisateur, mot de passe, OTP, code de récupération), tentez de coller du texte à l’aide du raccourci clavier (Ctrl+V sur Windows/Linux, Cmd+V sur macOS). Confirmez que le contenu collé apparaît dans le champ. Répétez l’opération via le menu contextuel du clic droit. Si le collage est bloqué, c’est un échec, sauf si une alternative sans fonction cognitive existe.
4. Tester le remplissage automatique avec un gestionnaire de mots de passe : En utilisant un navigateur doté d’un gestionnaire de mots de passe (natif ou via extension), enregistrez les identifiants lors de l’inscription puis revenez à la page de connexion. Confirmez que le gestionnaire de mots de passe peut détecter les champs et les remplir automatiquement. Testez dans Firefox avec NVDA, Safari avec VoiceOver (macOS/iOS) et Chrome avec JAWS pour couvrir les principales combinaisons TA+navigateur. Si les champs utilisent un balisage non standard ou un JavaScript qui efface les valeurs remplies automatiquement, c’est un échec.
5. NVDA + Firefox — parcours avec lecteur d’écran : Parcourez le formulaire de connexion en utilisant uniquement le clavier et NVDA. Confirmez que chaque champ est atteignable, que les libellés des champs sont correctement annoncés, et que tout widget CAPTCHA dispose d’une alternative accessible. Si le CAPTCHA est purement visuel sans option audio et sans voie de connexion alternative, consignez un échec.
6. VoiceOver + Safari (iOS) : Sur un appareil mobile, tentez de vous connecter en utilisant Face ID ou Touch ID si le site propose une connexion biométrique. Confirmez que l’option biométrique est atteignable via la navigation par balayage et que VoiceOver l’annonce correctement. Cela permet de vérifier qu’une alternative sans fonction cognitive est effectivement accessible en pratique, et pas seulement présente de manière nominale.
7. Vérifier les limites de temps sur les étapes cognitives : Si un CAPTCHA ou la saisie d’un OTP impose une limite de temps, vérifiez si l’utilisateur peut la prolonger ou la désactiver (pertinent pour 2.2.1), et notez séparément si l’étape chronométrée constitue un test de fonction cognitive sans alternative.

Comment corriger

CAPTCHA textuel sans alternative — Incorrect

<!-- Fails 3.3.8: only authentication method is transcribing distorted text;
     no alternative login path is offered, and paste is disabled -->
<form action='/login' method='post'>
  <label for='user'>Username</label>
  <input type='text' id='user' name='username'>

  <label for='pass'>Password</label>
  <input type='password' id='pass' name='password'
         autocomplete='off'
         onpaste='return false;'>

  <img src='/captcha-image.png' alt=''>
  <label for='captcha'>Type the characters above</label>
  <input type='text' id='captcha' name='captcha'
         autocomplete='off'
         onpaste='return false;'>

  <button type='submit'>Log in</button>
</form>

CAPTCHA textuel sans alternative — Correct

<!-- Passes 3.3.8: text CAPTCHA is replaced with a passkey / magic-link option;
     password field supports autofill and paste so password managers can assist -->
<form action='/login' method='post'>
  <label for='user'>Username or email</label>
  <input type='text' id='user' name='username'
         autocomplete='username'>

  <label for='pass'>Password</label>
  <input type='password' id='pass' name='password'
         autocomplete='current-password'>

  <!-- No CAPTCHA; bot protection handled server-side via risk-based signals -->
  <button type='submit'>Log in</button>
</form>

<!-- Cognitive-function-free alternative always visible -->
<p><a href='/magic-link'>Send me a sign-in link by email instead</a></p>
<p><a href='/passkey-login'>Sign in with a passkey or biometrics</a></p>

Champ OTP bloquant le collage — Incorrect

<!-- Fails 3.3.8: user must manually type a 6-digit OTP;
     paste is suppressed, forcing a transcription task -->
<label for='otp'>Enter the 6-digit code from your authenticator app</label>
<input type='text' id='otp' name='otp'
       inputmode='numeric'
       maxlength='6'
       autocomplete='off'
       onpaste='event.preventDefault();'
       ondrop='event.preventDefault();'>

Champ OTP bloquant le collage — Correct

<!-- Passes 3.3.8: paste and autofill are permitted;
     autocomplete='one-time-code' enables OS-level SMS/OTP autofill on mobile -->
<label for='otp'>Enter the 6-digit code from your authenticator app</label>
<input type='text' id='otp' name='otp'
       inputmode='numeric'
       maxlength='6'
       autocomplete='one-time-code'>
<!-- Remove all paste/drop prevention handlers.
     Risk of credential stuffing is managed server-side, not by blocking paste. -->

CAPTCHA de sélection d’images sans solution de repli (préoccupation AAA, conforme AA) — Correct au niveau AA

<!-- Passes 3.3.8 (AA): object recognition CAPTCHAs are explicitly
     exempted at the Minimum level. Selecting images of bicycles
     qualifies as object recognition, not character transcription.
     Note: this would fail 3.3.9 (AAA) — provide an alternative for full conformance. -->
<fieldset>
  <legend>Select all images that contain a bicycle</legend>
  <ul role='list'>
    <li>
      <input type='checkbox' id='img1' name='captcha' value='1'>
      <label for='img1'>
        <img src='/grid/img1.jpg' alt='A city street with parked vehicles'>
      </label>
    </li>
    <!-- additional grid items -->
  </ul>
</fieldset>

Erreurs courantes

• Définir autocomplete='off' sur les champs de mot de passe : Cela désactive le remplissage automatique des gestionnaires de mots de passe, supprimant le mécanisme d’assistance qui rend l’authentification par mot de passe standard conforme. Utilisez plutôt autocomplete='current-password' et laissez le navigateur gérer le stockage des identifiants.
• Bloquer le collage avec onpaste='return false;' ou addEventListener('paste', e => e.preventDefault()) : Cela oblige les utilisateurs à saisir manuellement leurs identifiants, créant une tâche de transcription inaccessible. Supprimez tous les gestionnaires de prévention du collage sur les champs d’authentification.
• Proposer une option de passkey qui n’est pas accessible au clavier : Une alternative biométrique ne satisfait 3.3.8 que si elle est atteignable et opérable via le clavier et les technologies d’assistance. Un bouton de passkey caché derrière un menu au survol ou rendu comme un <div> non focalisable ne compte pas comme une alternative conforme.
• Utiliser un CAPTCHA textuel comme seule stratégie de mitigation des bots : Passer à une détection de bots côté serveur basée sur le risque (analyse de l’empreinte de l’appareil, cadence de frappe, réputation IP) élimine entièrement le test de fonction cognitive sans sacrifier la sécurité. S’appuyer uniquement sur un CAPTCHA côté client est à la fois un échec d’accessibilité et une mauvaise pratique de sécurité.
• Scinder un OTP en plusieurs champs à caractère unique et bloquer le collage inter-champs : Certaines implémentations utilisent six champs <input maxlength='1'> distincts pour la saisie de l’OTP et font avancer le focus automatiquement via JavaScript. Ce modèle casse régulièrement le collage depuis les gestionnaires de mots de passe et viole 3.3.8, sauf si l’implémentation gère explicitement le collage d’un code complet dans le premier champ et répartit correctement les caractères.
• Exiger un CAPTCHA basé sur l’image uniquement sur les parcours de récupération de compte : Les équipes ajoutent souvent des alternatives de connexion accessibles à la page de connexion principale mais oublient l’authentification renforcée, la réinitialisation de mot de passe et les parcours de déverrouillage de compte. Chacun de ces parcours est une étape d’authentification distincte et doit respecter indépendamment 3.3.8.
• Considérer le CAPTCHA audio comme une alternative complète au CAPTCHA textuel : Une alternative audio répond aux besoins des personnes aveugles mais n’aide pas les personnes ayant des handicaps cognitifs ou celles dans des environnements bruyants. Les CAPTCHAs audio imposent également leur propre exigence de transcription. La bonne solution est d’éliminer le CAPTCHA ou de fournir une voie qui n’implique aucun test de fonction cognitive.
• Générer dynamiquement des identifiants de champs qui perturbent la détection par les gestionnaires de mots de passe : Lorsque les attributs id des champs de nom d’utilisateur et de mot de passe sont randomisés à chaque chargement de page (une technique anti-bot mal conçue), les gestionnaires de mots de passe ne peuvent pas identifier les champs de manière fiable. Cela désactive de fait le remplissage automatique et supprime le mécanisme d’assistance conforme.
• Supposer que les widgets CAPTCHA tiers sont automatiquement conformes : Les services CAPTCHA populaires peuvent proposer des variantes accessibles, mais elles ne sont pas activées par défaut. Les développeurs doivent configurer explicitement la version accessible, et doivent toujours vérifier qu’elle répond aux exigences de la norme plutôt que d’ajouter simplement un nouveau type de test inaccessible.
• Effacer les valeurs remplies automatiquement via JavaScript au focus : Certains formulaires effacent le contenu d’un champ lorsqu’il reçoit le focus pour afficher un texte indicatif ou inciter à une nouvelle saisie. Si ce comportement efface une valeur remplie automatiquement par un gestionnaire de mots de passe, il impose une ressaisie manuelle et enfreint 3.3.8.

Lien avec la réglementation d’accessibilité en Turquie

La Circulaire présidentielle 2025/10 de la Turquie, publiée au Journal officiel n° 32933 le 21 juin 2025, établit des obligations d’accessibilité web et mobile alignées sur WCAG 2.2. La circulaire exige des entités concernées qu’elles atteignent la conformité de niveau AA pour l’ensemble de leurs produits et services numériques. WCAG 3.3.8, en tant que critère de niveau AA dans WCAG 2.2, relève donc directement du champ d’application des exigences de conformité obligatoires introduites par cette circulaire.

La circulaire couvre un large éventail d’entités publiques et privées. Les institutions publiques et les organismes gouvernementaux doivent atteindre une conformité AA complète. Dans le secteur privé, la circulaire s’applique aux plateformes d’e-commerce, aux banques et institutions financières, aux hôpitaux et prestataires de santé privés, aux opérateurs de télécommunications comptant 200,000 abonnés ou plus, aux agences de voyage, aux entreprises de transport privé et aux écoles privées autorisées par le ministère de l’Éducation nationale (MoNE). Pour ces organisations, des parcours d’authentification inaccessibles — comme des pages de connexion avec des CAPTCHAs non pris en charge ou des champs OTP qui bloquent le collage — créent un risque réglementaire direct.

Le Logo d’accessibilité (Erişilebilirlik Logosu), délivré par le ministère de la Famille et des Services sociaux, est la marque officielle de certification de la conformité en matière d’accessibilité numérique en Turquie. L’obtention de ce logo nécessite une conformité démontrée au niveau AA, qui inclut 3.3.8. Pour les opérateurs d’e-commerce, les banques et autres fournisseurs de services numériques à fort trafic, le logo sert de signal de confiance publique et peut être mentionné dans les exigences de passation de marchés et d’appels d’offres. Des parcours d’authentification reposant sur des tests cognitifs inaccessibles bloqueraient la certification et exposeraient l’organisation à des plaintes et à des mesures d’exécution.

D’un point de vue pratique de conformité, les organisations turques devraient auditer chaque point de contact d’authentification — y compris la connexion, l’inscription, la MFA, la réinitialisation de mot de passe et le déverrouillage de compte — au regard de 3.3.8 avant de déposer une demande d’évaluation pour le Logo d’accessibilité. Remplacer les CAPTCHAs textuels par des contrôles côté serveur basés sur le risque, activer autocomplete sur tous les champs d’identifiants, et proposer des alternatives de type passkey ou lien magique sont les actions correctives les plus impactantes. Ces changements satisfont simultanément l’exigence réglementaire et améliorent l’expérience d’authentification pour les quelque 8,5 millions de personnes handicapées en Turquie qui utilisent des services numériques.