WCAG 2.2.5 : Ré-authentification

Ce que signifie cette règle

WCAG 2.2.5 Ré-authentification appartient à la Règle 2.2 (Temps suffisant) et est une exigence de niveau AAA. Le critère stipule : « Lorsqu’une session authentifiée expire, l’utilisateur peut poursuivre l’activité sans perte de données après s’être ré-authentifié. » En termes pratiques, cela signifie que si un utilisateur est en train de remplir un formulaire, de finaliser un achat, de rédiger un message ou d’effectuer une tâche en plusieurs étapes sur une plateforme nécessitant une authentification et que sa session expire, il doit pouvoir se reconnecter et reprendre exactement là où il s’était arrêté — avec toutes les données précédemment saisies préservées.

Ce critère est étroitement lié à WCAG 2.2.1 (Contrôle de la durée, niveau A) et 2.2.4 (Interruptions, niveau AAA), mais il traite d’un scénario spécifique : le moment où une limite de session est franchie. Alors que 2.2.1 vous demande de donner suffisamment de temps aux utilisateurs ou de leur permettre de prolonger leur session, 2.2.5 gère le cas d’échec — ce qui se passe après l’expiration du délai. Les deux fonctionnent ensemble : idéalement, vous prolongez la session et vous préservez les données si elle expire malgré tout.

Un succès au regard de ce critère exige que la plateforme préserve toutes les données saisies par l’utilisateur — champs de texte, options sélectionnées, pièces jointes, cases à cocher, boutons radio et tout autre état de formulaire — lors d’un événement de ré-authentification. Après que l’utilisateur s’est reconnecté, il doit être renvoyé au même point de l’activité qu’il effectuait, avec ses données intactes et la tâche pouvant être complétée sans répétition.

Un échec se produit lorsqu’un délai d’expiration de session entraîne l’un des cas suivants : l’utilisateur est redirigé vers une page de connexion et, après une connexion réussie, est envoyé vers la page d’accueil au lieu de la page sur laquelle il se trouvait ; les données du formulaire saisies avant l’expiration sont perdues et l’utilisateur doit tout ressaisir ; l’état partiellement complété d’un assistant en plusieurs étapes est réinitialisé ; ou l’utilisateur est simplement déconnecté sans mécanisme pour se ré-authentifier et reprendre.

La spécification officielle WCAG ne définit pas de durée minimale de session pour ce critère — il s’applique quelle que soit la durée, longue ou courte, de la période d’inactivité. Cependant, notez qu’aucune exception n’est prévue pour la perte de données pour des raisons de sécurité ; l’attente est que les implémentations trouvent des moyens sécurisés de préserver l’état, tels que le stockage de session côté serveur indexé sur l’identité de l’utilisateur, ou des jetons chiffrés côté client qui survivent au flux de ré-authentification.

Pourquoi c’est important

Les délais d’expiration de session qui effacent les données créent une charge disproportionnée pour les personnes handicapées. De nombreux utilisateurs handicapés ont besoin de beaucoup plus de temps pour accomplir des tâches numériques que leurs pairs non handicapés, et ils ne peuvent souvent pas simplement « taper plus vite » ou « contourner » un délai arbitraire.

Les utilisateurs qui sont aveugles ou malvoyants naviguent dans les formulaires à l’aide de lecteurs d’écran, ce qui est intrinsèquement plus lent que le balayage visuel. Une personne aveugle remplissant un long formulaire de déclaration d’assurance peut passer 20 ou 30 minutes à naviguer soigneusement champ par champ, pour voir son travail effacé lorsqu’un délai de session de 15 minutes se déclenche. Elle doit alors recommencer — sans garantie que la même chose ne se reproduira pas une seconde fois.

Les personnes ayant des déficiences motrices — comme celles qui utilisent des dispositifs d’accès par contacteurs, des technologies de suivi oculaire ou des baguettes buccales — peuvent mettre plusieurs fois plus de temps que la moyenne pour saisir du texte et naviguer dans les formulaires. Une personne atteinte de SLA ou d’atrophie musculaire spinale peut être en train de rédiger un formulaire de recommandation médicale critique et ne taper que quelques caractères par minute. Les délais de session qui détruisent son travail ne sont pas un simple désagrément ; ils peuvent constituer un obstacle complet à l’accomplissement de tâches essentielles.

Les utilisateurs ayant des déficiences cognitives, y compris ceux atteints de dyslexie, de TDAH, de lésions cérébrales traumatiques ou de démence, peuvent avoir besoin de relire les instructions plusieurs fois, de faire des pauses pour traiter l’information ou simplement d’avancer plus lentement dans les processus en plusieurs étapes. La recherche montre de manière constante que cette population est disproportionnellement affectée par la pression temporelle et la perte de données — qui s’ajoutent toutes deux à la charge cognitive de devoir recommencer à zéro.

Considérez un scénario concret du monde réel : une personne atteinte de sclérose en plaques fait une demande de prestation d’invalidité auprès d’une institution publique via le portail web de celle-ci. La demande comporte 8 étapes et nécessite le téléchargement de documents médicaux, la saisie de l’historique professionnel et la rédaction d’une déclaration personnelle. Elle arrive à la 6e étape en 45 minutes, sa session expire et toutes les données saisies sont perdues. Elle doit maintenant rassembler à nouveau les mêmes documents et répéter tout le processus, pouvant aller jusqu’à abandonner complètement la demande. Ce n’est pas une hypothèse — c’est un schéma documenté à maintes reprises dans la recherche et les tests utilisateurs en accessibilité.

Au-delà du handicap, la perte de données lors de l’expiration de session affecte tous les utilisateurs et a des impacts mesurables sur l’activité : paniers d’achat abandonnés, inscriptions incomplètes et prospects perdus. Préserver l’état de la session est à la fois un impératif d’accessibilité et une bonne pratique d’UX et d’optimisation de la conversion. Selon le Baymard Institute, l’abandon de formulaires est un facteur majeur des taux d’abandon de panier en e-commerce, et la perte de données inattendue est l’une des principales raisons citées pour lesquelles les utilisateurs ne finalisent pas leurs achats en ligne.

Règles Axe-core associées

WCAG 2.2.5 nécessite uniquement des tests manuels. Il n’existe aucune règle axe-core automatisée capable de détecter de manière fiable les violations de ce critère. Ce qui suit explique pourquoi les outils automatisés sont insuffisants et ce que les testeurs humains doivent faire à la place :

• Aucune règle automatisée n’existe pour la préservation de l’état de session : Axe-core et des moteurs d’accessibilité automatisés similaires fonctionnent en inspectant le DOM actuel et en évaluant des conditions statiques ou quasi statiques telles que les rapports de contraste de couleur, la validité des attributs ARIA et l’absence de texte alternatif. Ils ne peuvent pas simuler le passage du temps, déclencher un événement d’expiration de session, soumettre des identifiants de ré-authentification, puis vérifier si les données précédemment saisies ont été restaurées. Toute cette séquence est un comportement avec état, dépendant du temps, qui nécessite l’observation par un humain (ou un test de bout en bout scripté).
• La détection des délais de session est hors de portée de l’analyse statique : Même si un outil automatisé pouvait détecter qu’une page implémente un délai de session (par exemple en lisant une balise meta refresh ou un appel JavaScript setTimeout), il ne peut pas évaluer ce qui arrive aux données de l’utilisateur après le déclenchement du délai. Le comportement de préservation des données réside dans la logique de gestion de session côté serveur, et non dans la structure du DOM que les outils automatisés analysent.
• Complexité du flux de ré-authentification : L’expérience de ré-authentification peut impliquer plusieurs pages (formulaire de connexion, étape MFA, redirection), et la restauration de l’état peut dépendre de la logique côté serveur, des cookies, du stockage local ou des paramètres d’URL. Aucun outil d’inspection de DOM d’une seule page ne peut suivre ce flux multi-page et multi-système.
• Pourquoi les tests manuels sont essentiels : Un testeur qualifié doit initier manuellement un flux authentifié, attendre délibérément l’expiration de la session ou la déclencher, compléter le processus de ré-authentification, puis vérifier l’intégrité des données. C’est la seule méthode fiable pour tester la conformité. Les analyses automatisées peuvent servir de point de départ pour signaler des problèmes connexes (comme l’absence de mécanismes d’avertissement de session couverts par 2.2.1), mais elles ne peuvent pas remplacer les tests manuels pour 2.2.5.

Comment tester

1. Identifier les flux authentifiés avec formulaires ou processus en plusieurs étapes. Commencez par cartographier toutes les zones du site qui nécessitent une authentification et impliquent une saisie de données par l’utilisateur — flux de paiement, éditeurs de profil, formulaires de demande, systèmes de réservation, interfaces de messagerie et tableaux de bord administratifs. Ce sont les zones présentant le plus de risques d’échecs au regard de 2.2.5.
2. Déterminer la durée du délai de session. Vérifiez la configuration du serveur, les paramètres de l’application ou consultez l’équipe de développement pour savoir quand les sessions expirent. À défaut, démarrez une session et attendez d’être automatiquement déconnecté. Notez la durée. Les délais courants vont de 15 minutes à 2 heures.
3. Commencer une tâche et saisir une quantité significative de données. Connectez-vous et commencez à remplir un formulaire représentatif — par exemple, un flux d’inscription ou d’achat comportant plusieurs champs. Saisissez du texte dans les champs, faites des sélections et progressez dans les étapes de l’assistant. Ne soumettez pas le formulaire.
4. Déclencher l’expiration de la session. Attendez soit l’expiration naturelle du délai, soit — si vous avez un accès développeur — forcez l’expiration de la session en invalidant le cookie de session dans les outils de développement du navigateur (onglet Application > Cookies > supprimer le cookie de session), ou en expirant directement la session côté serveur.
5. Observer l’invite de ré-authentification. Vérifiez si le site vous invite à vous ré-authentifier (succès) ou vous redirige simplement vers une page de connexion sans avertissement (un problème de convivialité connexe, bien que 2.2.5 se concentre sur la préservation des données, pas sur l’avertissement lui-même). Essayez de vous reconnecter.
6. Vérifier la préservation des données après la connexion. Après une ré-authentification réussie, observez où vous êtes redirigé et si vos données précédemment saisies sont intactes. Si vous êtes envoyé vers la page d’accueil et/ou si les données de votre formulaire ont disparu, il s’agit d’un échec de 2.2.5.
7. Tester avec des technologies d’assistance. Répétez la séquence de test ci-dessus en utilisant NVDA avec Firefox, JAWS avec Chrome et VoiceOver avec Safari pour vous assurer que l’invite de ré-authentification est accessible aux utilisateurs de lecteurs d’écran et que l’état restauré de la page est correctement annoncé. Un utilisateur voyant peut reconnaître visuellement les données restaurées ; un utilisateur de lecteur d’écran a besoin que le focus soit correctement placé et que le contenu restauré soit dans l’ordre de lecture.
8. Tester la navigation au clavier uniquement. Assurez-vous que l’ensemble du processus de ré-authentification — de l’avis d’expiration de session à la reconnexion, puis au retour à la tâche préservée — peut être réalisé uniquement au clavier, sans nécessiter de souris.
9. Tester avec des simulations de délai prolongé. Si possible, réduisez le délai de session à 1–2 minutes dans un environnement de développement et exécutez des tests de parcours utilisateur complets pour rendre le cycle de test plus rapide et plus répétable.

Comment corriger

Formulaire de connexion simple avec délai de session — Incorrect

<!-- BAD: Session expires silently. On re-login, user is sent to homepage.
     All entered data in the checkout form is lost. -->
<form action='/checkout' method='POST' id='checkout-form'>
  <input type='text' name='full_name' placeholder='Full Name' />
  <input type='text' name='address' placeholder='Address' />
  <button type='submit'>Place Order</button>
</form>

<!-- Server-side: session expires after 10 minutes of inactivity.
     No state saved. POST redirect on login goes to /dashboard. -->

Formulaire de connexion simple avec délai de session — Correct

<!-- GOOD: Before session expires, form state is saved server-side
     (or to sessionStorage as a fallback). After re-auth, the user
     is redirected back to the checkout page with data restored. -->

<!-- 1. JavaScript saves form state periodically to the server -->
<script>
  function saveFormState() {
    const formData = new FormData(document.getElementById('checkout-form'));
    const data = Object.fromEntries(formData.entries());
    // Save to server-side session keyed to authenticated user identity
    fetch('/api/save-draft', {
      method: 'POST',
      headers: { 'Content-Type': 'application/json' },
      body: JSON.stringify({ formId: 'checkout', data })
    });
  }
  // Auto-save every 60 seconds and on input change
  setInterval(saveFormState, 60000);
  document.getElementById('checkout-form')
    .addEventListener('input', saveFormState);
</script>

<!-- 2. On the server: when user re-authenticates,
     redirect to /checkout?restore=true
     which reloads saved draft data into the form -->
<form action='/checkout' method='POST' id='checkout-form'>
  <!-- Form fields are pre-populated from saved draft -->
  <input type='text' name='full_name' value='[restored value]'
         aria-label='Full Name' />
  <input type='text' name='address' value='[restored value]'
         aria-label='Address' />
  <button type='submit'>Place Order</button>
</form>

Assistant en plusieurs étapes perdant la progression — Incorrect

<!-- BAD: Multi-step form uses only client-side state.
     Session expiry wipes wizard progress completely.
     Re-login sends user to step 1 with no data. -->

<div id='wizard'>
  <div class='step active' id='step-3'>
    <h2>Step 3 of 5: Employment History</h2>
    <textarea name='employment_history'>Typed content here...</textarea>
  </div>
</div>

<script>
  // State is only in JavaScript variables — lost on session expiry
  let wizardState = { step: 3, data: {} };
</script>

Assistant en plusieurs étapes perdant la progression — Correct

<!-- GOOD: Wizard state is persisted server-side at each step
     and linked to the user's account. On re-authentication,
     the server restores the user to their last saved step
     with all data intact. A visible confirmation is shown. -->

<div id='wizard'>
  <div class='step active' id='step-3'
       aria-live='polite' aria-label='Step 3 of 5: Employment History'>
    <p role='status'>
      Your progress has been restored from your last session.
    </p>
    <h2>Step 3 of 5: Employment History</h2>
    <!-- Data is pre-populated from server-side draft -->
    <textarea name='employment_history'
              aria-label='Describe your employment history'>
      Previously entered content restored here...
    </textarea>
    <!-- Wizard nav saves progress before moving to next step -->
    <button type='button' onclick='saveAndProceed()'>Next Step</button>
  </div>
</div>

<script>
  async function saveAndProceed() {
    await fetch('/api/wizard/save', {
      method: 'POST',
      body: JSON.stringify({ step: 3, data: collectStepData() }),
      headers: { 'Content-Type': 'application/json' }
    });
    goToStep(4);
  }
</script>

Avertissement d’expiration de session sans préservation des données — Incorrect

<!-- BAD: Site shows a countdown warning but does not save data.
     If the user misses the warning (e.g., screen reader user
     focused elsewhere), they lose all their work. -->
<div id='timeout-warning' style='display:none'>
  <p>Your session will expire in 2 minutes. <a href='/extend'>Extend</a></p>
</div>

Avertissement d’expiration de session sans préservation des données — Correct

<!-- GOOD: Warning uses aria-live so screen readers announce it.
     Data is saved server-side regardless of whether the user
     extends the session — so re-auth always restores state. -->
<div id='timeout-warning'
     role='alertdialog'
     aria-live='assertive'
     aria-labelledby='warning-title'
     aria-describedby='warning-desc'
     hidden>
  <h2 id='warning-title'>Session Expiring Soon</h2>
  <p id='warning-desc'>
    Your session will expire in 2 minutes. Your work has been
    saved automatically. You can extend your session or log in
    again to continue exactly where you left off.
  </p>
  <button onclick='extendSession()'>Extend Session</button>
  <button onclick='dismissWarning()'>Dismiss</button>
</div>

Erreurs courantes

• Rediriger vers la page d’accueil après ré-authentification au lieu de la page d’origine : Le schéma d’échec le plus courant. Après la connexion, l’application envoie l’utilisateur vers /dashboard ou / au lieu de l’URL sur laquelle il se trouvait lorsque sa session a expiré, l’obligeant à revenir manuellement à sa tâche — et ses données sont déjà perdues.
• Stocker l’état du formulaire uniquement en mémoire JavaScript ou dans l’état d’un composant React/Vue : L’état d’un framework côté client ne survit pas à un rechargement de page déclenché par une redirection vers la page de connexion à cause de l’expiration de session. L’état doit être conservé côté serveur ou dans un mécanisme de stockage (par exemple, localStorage) qui est restauré de manière fiable au retour.
• Enregistrer une « URL de retour » mais pas les données du formulaire : Certaines implémentations stockent l’URL vers laquelle rediriger après la connexion mais n’enregistrent pas les valeurs réelles des champs du formulaire. L’utilisateur arrive sur la bonne page mais avec des champs vides, ce qui viole toujours 2.2.5.
• Effectuer une sauvegarde automatique dans sessionStorage qui est effacé à la fermeture de l’onglet : Si l’expiration de session provoque la navigation de l’onglet du navigateur vers une autre page (par exemple, redirection vers la connexion), sessionStorage est effacé. Utilisez localStorage avec un espace de noms indexé sur l’utilisateur, ou de préférence un stockage de brouillon côté serveur.
• Ne pas tester avec des champs de téléversement de fichiers : Les champs de fichier ne peuvent pas être pré-remplis par HTML pour des raisons de sécurité. Si un formulaire comprend un téléversement de fichier qui a été effectué avant l’expiration de session, la référence au fichier est perdue. Les applications doivent gérer cela en stockant les références aux fichiers téléversés côté serveur et en montrant à l’utilisateur que son fichier est toujours joint.
• Effacer les données de brouillon sauvegardées immédiatement après la ré-authentification : Certaines implémentations suppriment le brouillon dès que l’utilisateur se connecte, avant de vérifier que l’utilisateur a effectivement vu et confirmé les données restaurées. Le brouillon doit être conservé jusqu’à ce que la tâche soit explicitement terminée ou annulée.
• Ne pas annoncer les données restaurées aux utilisateurs de lecteurs d’écran : Après la ré-authentification et la redirection, les utilisateurs de lecteurs d’écran ont besoin d’une région aria-live ou d’une annonce focalisée confirmant que leurs données ont été restaurées et qu’ils peuvent continuer là où ils s’étaient arrêtés. Sans cela, ils peuvent ne pas savoir que leur travail a été sauvegardé.
• Traiter différemment les sessions basées sur AJAX et les sessions basées sur des pages : Les applications monopage utilisant une authentification par jeton (par exemple, expiration de JWT) laissent souvent silencieusement échouer les appels API lorsque le jeton expire, sans donner à l’utilisateur la possibilité de se ré-authentifier et de reprendre. Le mécanisme de ré-authentification doit être tout aussi robuste pour les architectures SPA.
• Utiliser <meta http-equiv='refresh'> pour forcer la déconnexion sans sauvegarde préalable des données : Un meta refresh qui se déclenche à l’expiration redirige immédiatement l’utilisateur sans aucune préservation de l’état côté serveur, rendant la récupération des données impossible. La gestion de session doit être effectuée au niveau de l’application avec une conservation appropriée de l’état.
• Supposer que des sessions courtes éliminent le besoin de ce critère : Même un délai de session de 5 minutes peut surprendre un dactylographe lent, une personne ayant une déficience cognitive qui relit les instructions ou quelqu’un interrompu par un aidant. La durée du délai n’altère pas l’obligation de préserver les données lors de la ré-authentification.

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

La Circulaire présidentielle 2025/10 de la Turquie (publiée au Journal officiel n° 32933 le 21 juin 2025) établit le cadre national pour l’accessibilité numérique et fait référence à WCAG 2.2 comme base de son standard technique. La circulaire impose la conformité à un large éventail d’entités opérant en Turquie, y compris les institutions et agences publiques, les plateformes de e-commerce, les banques et prestataires de services financiers, les hôpitaux et prestataires de soins de santé privés, les entreprises de télécommunications comptant 200 000 abonnés ou plus, les agences de voyage, les entreprises de transport privé et les établissements d’enseignement privés autorisés par le ministère de l’Éducation nationale (MoNE).

WCAG 2.2.5 Ré-authentification est un critère de niveau AAA, ce qui signifie qu’il ne fait pas partie des exigences minimales légalement obligatoires au titre de la Circulaire (qui vise la conformité aux niveaux A et AA). Cependant, les organisations qui cherchent à démontrer leur leadership en matière d’accessibilité, à servir des populations d’utilisateurs diverses, y compris des personnes handicapées, ou à se positionner comme des prestataires de services numériques de premier plan devraient considérer les critères de niveau AAA — en particulier ceux qui ont un impact pratique aussi important que 2.2.5 — comme des objectifs ambitieux à poursuivre.

Certains types d’entités couvertes ont des raisons particulièrement fortes de mettre en œuvre 2.2.5. Les banques et plateformes financières exigent souvent des utilisateurs qu’ils remplissent de longs formulaires pour des demandes de prêt, des ouvertures de compte ou des produits d’investissement, et leurs délais de session courts motivés par la sécurité créent une tension directe avec les obligations de préservation des données. Les hôpitaux et portails de santé exposent les patients à une perte de données lors de tâches critiques comme la prise de rendez-vous ou le remplissage de questionnaires de santé, ce qui peut avoir de réelles conséquences sur la continuité des soins. Les institutions publiques qui exploitent des services d’e-gouvernement — tels que la déclaration d’impôts, les demandes de permis ou les demandes de prestations — servent des citoyens handicapés qui peuvent avoir besoin de plus de temps pour remplir des formulaires administratifs complexes.

Même lorsque la conformité au niveau AAA n’est pas légalement requise, les organisations turques doivent être conscientes que les régulateurs, les organisations de la société civile et les défenseurs des droits des personnes handicapées examinent de plus en plus la qualité et l’exhaustivité des mises en œuvre de l’accessibilité numérique. Documenter la conformité à des critères de niveau AAA tels que 2.2.5 renforce la déclaration d’accessibilité d’une organisation, réduit le risque de contentieux et démontre un engagement réel envers la conception inclusive au-delà d’une conformité minimale de façade. Pour les entités ayant une portée internationale, en particulier celles opérant sur les marchés de l’UE en plus de la Turquie, les critères de niveau AAA peuvent recouper les exigences de l’Acte européen sur l’accessibilité (EAA) et des mises en œuvre nationales associées.