WCAG 3.3.9 : Authentification accessible (améliorée)

Ce que signifie cette règle

WCAG 3.3.9 — Authentification accessible (renforcée) est l’équivalent au niveau AAA de WCAG 3.3.8 (Authentification accessible — Minimum, AA). Ensemble, ces deux critères, introduits dans WCAG 2.2, visent à garantir que le processus de preuve d’identité sur un site web ou une application ne devienne pas lui-même un obstacle à l’accessibilité.

Au niveau AAA, 3.3.9 renforce considérablement les exigences. Le critère stipule : Un test de fonction cognitive ne doit pas être requis pour une étape quelconque d’un processus d’authentification, à moins que cette étape ne fournisse au moins l’un des éléments suivants : une méthode d’authentification alternative qui ne repose pas sur un test de fonction cognitive ; un mécanisme permettant d’aider l’utilisateur à réaliser le test de fonction cognitive ; ou que le test de fonction cognitive consiste à reconnaître des objets. Point crucial : contrairement à la version AA (3.3.8), le critère AAA supprime l’exception qui autorisait la reconnaissance de contenus non-objets (comme des images d’éléments non-objets qu’un utilisateur avait sélectionnés auparavant). À ce niveau, seule la véritable reconnaissance d’objets — reconnaître des objets courants du monde réel comme des images d’un chat, d’un vélo ou d’une maison — est autorisée comme test de fonction cognitive, et uniquement si les autres conditions ne sont pas remplies.

Un test de fonction cognitive est défini comme toute tâche qui exige de l’utilisateur qu’il se souvienne, manipule ou transcrive des informations. Cela inclut : se souvenir d’un nom d’utilisateur ou d’un mot de passe, résoudre un problème mathématique, compléter un CAPTCHA qui demande de déchiffrer un texte déformé, répondre à une question de sécurité sur son histoire personnelle (par exemple, « Quel était le nom de votre premier animal de compagnie ? »), ou transcrire une suite de caractères. Toutes ces tâches représentent des exercices de mémoire ou de transcription que de nombreux utilisateurs ne peuvent pas réaliser de manière fiable.

Ce qui est considéré comme conforme : Une étape d’authentification satisfait 3.3.9 si elle ne requiert aucun test de fonction cognitive, ou si elle remplit l’une des conditions suivantes : (1) un parcours d’authentification complètement distinct, sans exigence cognitive, est proposé (par exemple, un lien magique envoyé par e-mail, WebAuthn/passkey, connexion biométrique) ; (2) un mécanisme aide à la réalisation du test (par exemple, le gestionnaire de mots de passe du navigateur n’est pas bloqué, ou le copier-coller est autorisé) ; ou (3) le seul test cognitif en jeu consiste à reconnaître un objet courant du monde réel parmi un ensemble d’images.

Ce qui est considéré comme non conforme : Tout parcours qui oblige l’utilisateur — sans possibilité de contournement ni alternative — à se rappeler un mot de passe de mémoire, à transcrire un code qui ne peut pas être collé, à résoudre un CAPTCHA visuel ou audio sans alternative, à répondre à des questions de sécurité basées sur la connaissance, ou à identifier des images précédemment sélectionnées de contenus non-objets (par exemple, des formes abstraites ou des photos personnelles) sans parcours d’authentification alternatif.

Exceptions officielles : La spécification WCAG précise que la reconnaissance d’objets (photographies d’éléments du monde réel) est la seule tâche de reconnaissance d’images autorisée à ce niveau AAA. Le critère AA (3.3.8) autorisait également la reconnaissance d’images « non-objets » choisies personnellement, mais 3.3.9 supprime entièrement cette exception. Il n’existe aucune exception pour les schémas d’authentification « largement utilisés » — si un schéma exige un test cognitif sans alternative, il ne satisfait pas 3.3.9.

Pourquoi c’est important

L’authentification est souvent la première interaction significative qu’un utilisateur a avec un service numérique. Si cette interaction est elle-même inaccessible, le reste de l’accessibilité du site devient sans objet — l’utilisateur ne peut tout simplement pas entrer. WCAG 3.3.9 s’attaque directement à cette barrière, et son impact concerne un large éventail de groupes de personnes handicapées.

Les personnes ayant des handicaps cognitifs — y compris celles ayant une dyslexie, un TDAH, un traumatisme crânien, une démence ou des troubles d’apprentissage — peuvent trouver extrêmement difficile, voire impossible, de mémoriser des mots de passe complexes, de transcrire manuellement des codes à usage unique limités dans le temps, ou de déchiffrer un texte déformé dans un CAPTCHA. 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 handicaps cognitifs représentent l’une des catégories les plus importantes et les plus mal desservies en matière d’accessibilité web.

Les personnes ayant des déficiences motrices — comme celles atteintes de la maladie de Parkinson, de tremblements essentiels, de lésions de la moelle épinière, ou utilisant un accès par contacteurs ou une technologie de suivi oculaire — peuvent avoir des difficultés à saisir correctement des mots de passe ou à transcrire des codes caractère par caractère. Le blocage du collage depuis le presse-papiers (une mesure anti-fraude courante mais activement nuisible) oblige ces utilisateurs à saisir laborieusement chaque caractère via leur dispositif d’assistance, ce qui augmente fortement les taux d’erreur et la fatigue.

Les personnes aveugles ou malvoyantes peuvent dépendre entièrement des lecteurs d’écran ou des outils de grossissement. Les CAPTCHAs visuels sont totalement inaccessibles sans alternative audio, et même les CAPTCHAs audio sont notoirement difficiles pour les personnes ayant des déficiences auditives ou des troubles du traitement auditif. Les défis de type « sélectionnez tous les feux de circulation » basés sur des images peuvent également poser problème lorsque les descriptions d’images sont absentes ou trompeuses.

Les personnes sourdes ou malentendantes peuvent se heurter à des obstacles avec des méthodes d’authentification reposant uniquement sur des appels téléphoniques pour délivrer des codes à usage unique, en particulier lorsque ces appels sont uniquement vocaux, sans alternative SMS.

Un scénario concret : Imaginez une personne de 72 ans présentant un léger déclin cognitif qui tente d’accéder à son portail de banque en ligne. La banque exige un nom d’utilisateur (qui doit être mémorisé, et non l’adresse e-mail), un mot de passe complexe (le collage depuis le presse-papiers est bloqué), et un CAPTCHA avec du texte déformé. L’utilisateur échoue deux fois au CAPTCHA, est bloqué et doit appeler l’assistance de la banque — un processus de 40 minutes. Si la banque avait mis en place des passkeys ou un lien magique, cette personne se serait authentifiée en quelques secondes. Ce scénario se répète des millions de fois chaque jour sur le web, et il est entièrement évitable.

Au-delà du handicap, une authentification accessible profite à tous les utilisateurs. Les gestionnaires de mots de passe, utilisés par des centaines de millions de personnes, dépendent de la possibilité de coller les identifiants. Bloquer le collage, exiger une transcription manuelle ou intégrer des CAPTCHAs inaccessibles frustre également les utilisateurs grand public. Il existe aussi des arguments de sécurité : forcer la saisie manuelle de mots de passe complexes augmente la probabilité que les utilisateurs choisissent des mots de passe plus simples, plus faibles, ou les réutilisent sur plusieurs sites. Les passkeys et les liens magiques, alternatives recommandées, sont à la fois plus accessibles et plus sûrs que les parcours traditionnels mot de passe + CAPTCHA.

Règles Axe-core associées

WCAG 3.3.9 est classé comme nécessitant uniquement des tests manuels. À partir de axe-core 4.10, il n’existe aucune règle automatisée qui évalue pleinement ce critère. Comprendre pourquoi les outils automatisés ne peuvent pas détecter ces violations suppose de comprendre ce que le critère mesure réellement.

• Tests manuels requis — détection des fonctions cognitives : Les analyseurs automatisés peuvent détecter la présence de certains éléments HTML (comme un <input type='password'> ou une iframe intégrant un widget CAPTCHA tiers), mais ils ne peuvent pas déterminer si un parcours d’authentification complet exige un test de fonction cognitive sans alternative accessible. Le critère concerne l’ensemble du parcours utilisateur, potentiellement sur plusieurs étapes et pages, et non les propriétés d’un seul élément. Un analyseur ne peut pas évaluer si le collage est bloqué par programmation via JavaScript, si une limite de temps sur un champ de saisie de code est raisonnable, ou si un parcours d’authentification alternatif évite réellement les tests cognitifs. Ce sont des questions comportementales et architecturales qui nécessitent qu’un évaluateur humain parcoure le processus d’authentification réel.
• Tests manuels requis — vérification des parcours alternatifs : Même si un analyseur détecte un widget CAPTCHA, il ne peut pas vérifier si une méthode d’authentification alternative accessible existe sur la même page ou dans le même parcours. Il ne peut pas évaluer si une option « utiliser une passkey à la place » est réellement équivalente ou si elle est enfouie dans une page de paramètres secondaire qui exige elle-même de réussir d’abord le CAPTCHA inaccessible. L’évaluation de l’équivalence des parcours alternatifs nécessite un jugement humain sur l’exhaustivité et la visibilité de ces alternatives.
• Tests manuels requis — comportement du collage depuis le presse-papiers : Le JavaScript qui intercepte les événements paste et les annule (event.preventDefault() sur un écouteur de collage) est invisible pour une analyse HTML statique. Un analyseur voit un élément <input> valide ; il ne peut pas savoir que le collage y est désactivé. Seuls des tests manuels — tenter physiquement de coller un mot de passe ou un code — peuvent révéler cette défaillance.
• Tests manuels requis — compatibilité des widgets d’authentification avec les technologies d’assistance : Les SDK d’authentification tiers (boutons de connexion sociale, fournisseurs de CAPTCHA, invites biométriques) peuvent être rendus dans des iframes ou du Shadow DOM que les analyseurs automatisés ne peuvent pas entièrement explorer. Des tests manuels avec des lecteurs d’écran tels que NVDA, JAWS et VoiceOver sont essentiels pour confirmer que tous les éléments interactifs du parcours d’authentification sont utilisables et compréhensibles.

Comment tester

1. Identifier tous les points d’entrée d’authentification : Avant de tester, cartographiez tous les endroits de l’application où un utilisateur doit s’authentifier ou vérifier son identité. Cela inclut la connexion initiale, la création de compte, la réinitialisation de mot de passe, les invites d’authentification à deux facteurs, la ré-authentification après expiration de session, les écrans de confirmation de paiement et les barrières de vérification d’âge. Chacun de ces parcours doit être évalué indépendamment.
2. Lancer une analyse automatisée de base : Utilisez axe DevTools (extension de navigateur) ou Lighthouse dans Chrome DevTools sur chaque page d’authentification. Bien que ces outils ne signalent pas directement les violations de 3.3.9, ils feront remonter des problèmes connexes — étiquettes manquantes sur les champs de formulaire, contenu d’iframe inaccessible, gestion du focus manquante — qui aggravent les obstacles à l’authentification. Notez les problèmes signalés comme contexte pour l’évaluation manuelle. Dans axe DevTools, consultez l’onglet « Needs Review » pour les éléments nécessitant un jugement humain.
3. Auditer les tests de fonction cognitive : Pour chaque étape d’authentification, demandez-vous : cette étape exige-t-elle de (a) se souvenir de quelque chose, (b) transcrire quelque chose, ou (c) résoudre un puzzle ? Si oui, vérifiez qu’au moins l’un des éléments suivants est présent et tout aussi visible : un parcours alternatif sans exigence cognitive ; un mécanisme (comme le collage autorisé ou un champ compatible avec l’auto-complétion) qui aide à la réalisation ; ou que la seule tâche cognitive consiste à reconnaître un objet courant du monde réel.
4. Tester le comportement du collage depuis le presse-papiers : Dans chaque champ de mot de passe et de saisie de code, copiez une chaîne de texte dans votre presse-papiers et tentez de la coller avec Ctrl+V (Windows/Linux) ou Cmd+V (macOS). Si le collage est bloqué, c’est un échec. Testez également si l’auto-complétion du gestionnaire de mots de passe du navigateur est supprimée (recherchez autocomplete='off' ou du JavaScript qui efface les valeurs d’auto-complétion au focus).
5. Tester avec NVDA + Firefox : Parcourez l’ensemble du processus d’authentification en utilisant uniquement le clavier et le lecteur d’écran NVDA. Vérifiez que tous les champs de formulaire sont annoncés avec des étiquettes significatives, que tous les contrôles interactifs (boutons, liens, défis CAPTCHA) sont atteignables et utilisables, et que tout message d’erreur est programmatique­ment associé au champ concerné et annoncé immédiatement sans navigation supplémentaire.
6. Tester avec VoiceOver + Safari (macOS/iOS) : Répétez l’ensemble du parcours d’authentification. Sur iOS, vérifiez également que l’authentification biométrique (Face ID / Touch ID) est proposée comme alternative lorsque l’authentification native est utilisée, et que le parcours web est entièrement utilisable avec le Contrôle de sélection (Switch Control) si la biométrie n’est pas disponible.
7. Tester avec JAWS + Chrome : Répétez le parcours, en accordant une attention particulière à la façon dont les widgets tiers (connexion sociale OAuth, iframes de CAPTCHA) sont annoncés. JAWS gère certains schémas ARIA différemment de NVDA ; les deux doivent être testés.
8. Évaluer la véritable équivalence des parcours alternatifs : Si une méthode d’authentification alternative existe (par exemple, « Se connecter avec un lien magique »), complétez l’ensemble du parcours en utilisant uniquement cette alternative. Confirmez qu’elle aboutit au même état authentifié sans exiger de test cognitif. Si le parcours alternatif contient lui-même un CAPTCHA ou un test de mémoire, il ne constitue pas une alternative valide au sens de 3.3.9.
9. Documenter les constats avec des preuves : Pour chaque échec, capturez un enregistrement d’écran ou une capture annotée montrant précisément quelle étape échoue et pourquoi. Cette documentation est essentielle pour la transmission des correctifs aux équipes de développement et pour la traçabilité des audits.

Comment corriger

CAPTCHA sans alternative — Incorrect

<!-- Fails 3.3.9: The only authentication path requires solving a visual CAPTCHA.
     No alternative is provided, and there is no object-recognition option. -->
<form method='post' action='/login'>
  <label for='username'>Username</label>
  <input type='text' id='username' name='username' autocomplete='username'>

  <label for='password'>Password</label>
  <input type='password' id='password' name='password' autocomplete='off'>

  <!-- Third-party CAPTCHA widget with no accessible alternative path -->
  <div class='g-recaptcha' data-sitekey='YOUR_SITE_KEY'></div>

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

CAPTCHA remplacé par passkey et lien magique — Correct

<!-- Passes 3.3.9: CAPTCHA removed entirely. Primary path uses a passkey
     (WebAuthn — no cognitive test). A magic link fallback is offered
     for devices without passkey support. Password entry allows paste
     and browser autofill. -->
<form method='post' action='/login'>
  <label for='email'>Email address</label>
  <input type='email' id='email' name='email' autocomplete='email'>

  <!-- Passkey login: no password to remember, no CAPTCHA -->
  <button type='button' id='passkey-btn'>Sign in with Passkey</button>

  <!-- Password fallback: paste and autofill explicitly enabled -->
  <label for='password'>Password (optional)</label>
  <input type='password' id='password' name='password'
         autocomplete='current-password'>
  <!-- NOTE: Do NOT add autocomplete='off' or paste-blocking JS here -->

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

<!-- Non-cognitive alternative: magic link -->
<p><a href='/send-magic-link'>Send me a sign-in link instead</a></p>

<script>
  // WebAuthn passkey authentication — no cognitive function test
  document.getElementById('passkey-btn').addEventListener('click', async () => {
    const credential = await navigator.credentials.get({ publicKey: publicKeyOptions });
    // submit credential to server
  });
</script>

Collage depuis le presse-papiers bloqué sur le champ OTP — Incorrect

<!-- Fails 3.3.9: The one-time code field blocks paste via JavaScript,
     forcing users to manually transcribe a time-limited code.
     This is a transcription cognitive function test with no bypass. -->
<label for='otp'>Enter the 6-digit code from your authenticator app</label>
<input type='text' id='otp' name='otp' maxlength='6'
       inputmode='numeric' autocomplete='off'>

<script>
  document.getElementById('otp').addEventListener('paste', function(e) {
    e.preventDefault(); // Blocks paste — FAILS 3.3.9
  });
</script>

Champ OTP avec collage autorisé et indice d’auto-complétion — Correct

<!-- Passes 3.3.9: Paste is allowed. The autocomplete='one-time-code' attribute
     enables browsers and password managers to automatically fill the OTP,
     eliminating the transcription requirement entirely. -->
<label for='otp'>Enter the 6-digit code from your authenticator app</label>
<input type='text' id='otp' name='otp' maxlength='6'
       inputmode='numeric' autocomplete='one-time-code'>

<!-- No paste-blocking JavaScript. autocomplete='one-time-code' allows
     the OS (iOS, Android, desktop browsers) to suggest the OTP
     automatically from SMS or authenticator apps. -->

Questions de sécurité basées sur la connaissance — Incorrect

<!-- Fails 3.3.9: Requiring answers to knowledge-based security questions
     is a memory-recall cognitive function test. No alternative is offered. -->
<form method='post' action='/verify-identity'>
  <p>To verify your identity, please answer your security question:</p>
  <label for='sq-answer'>What was the name of your childhood pet?</label>
  <input type='text' id='sq-answer' name='sq-answer' autocomplete='off'>
  <button type='submit'>Verify</button>
</form>

Vérification d’identité avec alternatives non cognitives — Correct

<!-- Passes 3.3.9: Security questions replaced with email magic link
     and government ID upload options — neither requires memory recall.
     If security questions are retained for some users, a clearly labeled
     alternative path is provided upfront. -->
<form method='post' action='/verify-identity'>
  <p>We need to verify your identity. Choose one of the following methods:</p>

  <fieldset>
    <legend>Verification method</legend>

    <label>
      <input type='radio' name='verify-method' value='magic-link' checked>
      Send a verification link to my registered email
    </label>

    <label>
      <input type='radio' name='verify-method' value='id-upload'>
      Upload a photo of a government-issued ID
    </label>
  </fieldset>

  <button type='submit'>Continue</button>
</form>

Erreurs courantes

• Ajouter autocomplete='off' aux champs de mot de passe pour empêcher l’auto-complétion du navigateur. Cela désactive le principal mécanisme permettant aux utilisateurs d’éviter de mémoriser des mots de passe et enfreint directement 3.3.9. Supprimez autocomplete='off' et utilisez plutôt autocomplete='current-password' ou autocomplete='new-password'.
• Attacher un écouteur d’événement JavaScript paste qui appelle event.preventDefault() sur les champs de saisie d’authentification, en pensant améliorer la sécurité. En réalité, cela bloque les gestionnaires de mots de passe et les technologies d’assistance et constitue une exigence de transcription au sens de 3.3.9.
• Considérer l’alternative CAPTCHA audio comme un contournement suffisant des CAPTCHAs visuels. Les CAPTCHAs audio restent un test de fonction cognitive (transcription de caractères audio déformés) et ne satisfont pas 3.3.9. Un véritable parcours alternatif non cognitif est requis.
• Proposer une passkey ou une option de connexion sociale mais la placer derrière un CAPTCHA en premier. Si l’utilisateur doit réussir un test cognitif pour accéder à l’alternative accessible, cette alternative n’est pas réellement équivalente et le parcours ne satisfait pas 3.3.9.
• Utiliser six champs <input> distincts d’un seul caractère pour la saisie d’OTP (un schéma d’interface courant) sans prendre en charge le collage pour remplir l’ensemble des champs. De nombreuses implémentations ne collent que dans le premier champ et exigent une saisie manuelle caractère par caractère pour les cinq autres, ce qui constitue une barrière de transcription.
• Se reposer sur « Se souvenir de moi » ou sur des cookies de session persistants comme seule mesure d’adaptation pour les utilisateurs qui ne peuvent pas s’authentifier de manière répétée. Réduire la fréquence d’authentification aide, mais ne corrige pas un processus d’authentification inaccessible — les utilisateurs doivent tout de même réussir au moins une fois le test cognitif, et les sessions expirent ou sont effacées.
• Mettre en place des champs OTP limités dans le temps qui se vident à l’expiration sans avertissement, obligeant les utilisateurs à demander un nouveau code et à tenter à nouveau la transcription. Cela accroît la charge cognitive pour les personnes ayant une motricité lente ou des vitesses de traitement cognitif réduites.
• Utiliser des défis CAPTCHA basés sur des images qui exigent la reconnaissance de contenus non-objets — comme des motifs abstraits, des couleurs ou des séquences de photos personnelles sélectionnées — en pensant satisfaire 3.3.9. Le critère AAA n’autorise que la reconnaissance d’objets (objets du monde réel comme des voitures, des vélos, des feux de circulation) ; la reconnaissance d’images non-objets n’est pas exemptée à ce niveau.
• Bloquer l’accès au gestionnaire d’identifiants du navigateur via autocomplete='new-password' sur les champs de connexion (par opposition aux champs d’inscription). La valeur new-password indique aux navigateurs qu’il s’agit d’un champ de création d’un nouveau mot de passe, ce qui empêche l’auto-complétion des identifiants enregistrés lors de la connexion.
• Ne pas tester les parcours d’authentification avec de véritables technologies d’assistance et se fier uniquement aux résultats d’analyses automatisées. Comme 3.3.9 ne peut être testé que manuellement, les équipes qui omettent les tests manuels avec lecteurs d’écran et clavier manqueront systématiquement des défaillances de ce critère à chaque cycle de publication.

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

La Circulaire présidentielle n° 2025/10 de la Turquie, publiée au Journal officiel n° 32933 le 21 juin 2025, établit des obligations complètes en matière d’accessibilité web et mobile pour un large éventail d’entités publiques et privées opérant en Turquie. La circulaire impose la conformité à WCAG 2.2, ce qui en fait le premier instrument juridique turc à faire explicitement référence à la version 2.2 de la norme.

Les entités couvertes par la circulaire incluent : les institutions et agences publiques à tous les niveaux de gouvernement ; les plateformes de commerce électronique et les places de marché en ligne ; les banques et institutions financières ; les hôpitaux et prestataires de soins de santé ; les opérateurs de télécommunications comptant 200,000 abonnés ou plus ; les agences de voyage ; les entreprises de transport privé ; et les écoles privées autorisées par le ministère de l’Éducation nationale (MoNE). Pour ces organisations, les services numériques — y compris les portails de connexion, les portails patients, les tableaux de bord bancaires, les systèmes de billetterie et les systèmes d’information des étudiants — doivent respecter les exigences d’accessibilité définies par la circulaire.

WCAG 3.3.9, en tant que critère de niveau AAA, n’est pas une obligation légale minimale au titre de la circulaire. Le socle légal obligatoire correspond à la conformité aux niveaux A et AA de WCAG 2.2. Cependant, l’esprit et la portée de la circulaire rendent 3.3.9 très pertinent en pratique pour plusieurs raisons.

Premièrement, WCAG 3.3.8 (Authentification accessible — Minimum) est une exigence de niveau AA et est donc juridiquement contraignante pour toutes les entités couvertes. Les organisations qui travaillent à se conformer à 3.3.8 constateront que le passage à la conformité 3.3.9 est souvent une étape supplémentaire modeste — principalement la suppression de l’exception de reconnaissance d’images autorisée par 3.3.8 et la garantie que tous les tests cognitifs disposent d’alternatives non cognitives, et pas seulement de mécanismes d’assistance.

Deuxièmement, pour les entités fournissant des services à des populations présentant des taux plus élevés de handicaps cognitifs ou moteurs — en particulier les hôpitaux, les portails de santé publique et les portails de services gouvernementaux — atteindre la conformité AAA sur les critères d’authentification représente un engagement significatif en faveur de l’égalité d’accès, qui s’aligne sur les principes constitutionnels plus larges d’égalité en Turquie et sur les obligations du pays au titre de la Convention des Nations Unies relative aux droits des personnes handicapées (CDPH), que la Turquie a ratifiée.

Troisièmement, les banques turques et les fournisseurs de services fintech sont particulièrement scrutés en matière d’authentification. L’Agence de régulation et de supervision bancaires (BDDK) et le Conseil d’enquête sur les crimes financiers (MASAK) imposent des exigences strictes de vérification d’identité, et les organisations mettent souvent en œuvre des parcours d’authentification complexes et multi-étapes pour satisfaire ces exigences. Mettre en œuvre une authentification conforme à 3.3.9 — en utilisant des passkeys, WebAuthn ou des parcours de lien magique — est à la fois plus accessible et conforme aux meilleures pratiques modernes d’authentification sécurisée approuvées par les régulateurs financiers internationaux, ce qui en fait un objectif de conception qui sert la conformité sur plusieurs fronts simultanément.

Les organisations qui cherchent à se différencier par leur posture en matière d’accessibilité, à se préparer à un éventuel durcissement réglementaire futur, ou à servir les utilisateurs de manière accessible et inclusive sont fortement encouragées à considérer WCAG 3.3.9 comme une norme de conception, et non comme un simple perfectionnement optionnel. La mise en œuvre de parcours d’authentification entièrement non cognitifs est de plus en plus réalisable grâce aux API modernes des navigateurs (WebAuthn/passkeys) et aux SDK d’authentification, ce qui rend le coût de conformité plus faible que jamais tandis que le bénéfice — éliminer l’un des obstacles d’accessibilité les plus lourds de conséquences dans tout produit numérique — est considérable.