WCAG 2.2.6 : Expirations de session

Ce que signifie cette règle

WCAG 2.2.6 Timeouts (Niveau AAA) exige que les utilisateurs soient avertis de la durée de toute inactivité pouvant entraîner une perte de données, sauf si les données sont conservées pendant plus de 20 heures d’inactivité de l’utilisateur. En pratique, cela signifie que si votre application ou service web peut perdre les données d’un utilisateur — comme des saisies de formulaire, un panier d’achat ou une transaction en cours — parce que l’utilisateur est resté inactif pendant un certain temps, vous devez informer les utilisateurs de la durée exacte dont ils disposent avant que ces données ne soient perdues.

Ce critère s’applique à toute situation où un timeout entraîne une perte de données. Les exemples courants incluent l’expiration de session sur des portails bancaires ou gouvernementaux qui efface les données de formulaire, des paniers d’achat qui se vident après une période d’inactivité, des assistants ou formulaires multi-étapes qui se réinitialisent lorsque le cookie de session expire, et des systèmes de test ou de réservation en ligne qui suppriment les réponses partielles. Le déclencheur clé est la combinaison de l’inactivité (et non une limite de temps stricte pour terminer une tâche, qui est couverte par 2.2.1) et la conséquence de la perte de données.

Ce qui est considéré comme conforme : Une page satisfait au critère 2.2.6 si elle informe clairement les utilisateurs au début d’une session — ou avant qu’ils ne commencent à saisir des données — de la durée spécifique d’inactivité qui entraînera une perte de données. Alternativement, une page est conforme si aucune perte de données ne peut se produire, quelle que soit la durée d’inactivité de l’utilisateur (par exemple, parce que le serveur conserve toutes les données de formulaire pendant plus de 20 heures, ou indéfiniment). Afficher un avertissement uniquement après l’expiration de la session ne satisfait pas au critère.

Ce qui est considéré comme non conforme : Une page échoue si elle perd silencieusement les données de l’utilisateur après une période d’inactivité sans jamais informer l’utilisateur de ce risque. Elle échoue également si un avertissement existe mais n’est présenté qu’au moment de la perte de données (trop tard pour agir), ou si l’avertissement est vague — par exemple, en indiquant « votre session peut expirer » sans préciser la durée réelle d’inactivité qui déclenche le timeout.

Exceptions officielles : Le critère exempte explicitement les situations où les données sont conservées pendant plus de 20 heures d’inactivité. Le seuil de 20 heures a été choisi pour tenir compte des utilisateurs qui commencent une tâche un jour et la reprennent le lendemain. Si votre système stocke de manière fiable toutes les données saisies côté serveur pendant au moins 20 heures sans action requise de la part de l’utilisateur, vous n’êtes pas tenu d’afficher un avertissement. De plus, ce critère ne s’applique pas aux timeouts qui sont essentiels à la sécurité — par exemple, une exigence stricte imposée par la loi ou la réglementation selon laquelle une session doit se terminer après une période fixe, quelle que soit l’action de l’utilisateur. Dans de tels cas, le critère encourage toujours la divulgation mais reconnaît la contrainte légale.

Pourquoi c’est important

Les timeouts sans avertissement adéquat affectent de manière disproportionnée les personnes ayant des handicaps cognitifs, des déficiences motrices, ainsi que les personnes aveugles ou malvoyantes. Les utilisateurs ayant des handicaps cognitifs tels que la dyslexie, le TDAH ou un traumatisme crânien peuvent avoir besoin de beaucoup plus de temps pour lire les instructions, rédiger du texte ou revoir des informations avant de soumettre un formulaire. Si une session expire silencieusement alors qu’ils sont encore en train de travailler, ils perdent tous leurs efforts et doivent recommencer — une expérience profondément décourageante qui peut les amener à abandonner complètement la tâche.

Les personnes ayant des handicaps moteurs qui s’appuient sur un accès par contacteur, des dispositifs de suivi oculaire ou d’autres méthodes d’entrée alternatives interagissent avec les interfaces à un rythme bien plus lent qu’un utilisateur de souris. Remplir un long formulaire de déclaration d’assurance ou une demande gouvernementale sur plusieurs pages peut leur prendre beaucoup plus de temps que ce que suppose le timeout de session par défaut. Sans connaître le compte à rebours, elles n’ont aucune possibilité d’agir — par exemple, en enregistrant leur progression ou en demandant une prolongation — avant que leurs données ne disparaissent.

Les utilisateurs de lecteurs d’écran sont également confrontés à un défi supplémentaire : la navigation dans des formulaires complexes prend plus de temps lorsque chaque champ doit être lu à voix haute et confirmé au clavier. Une session qui expire alors qu’un utilisateur travaille encore méthodiquement sur un long formulaire n’est pas simplement gênante — elle peut représenter des heures d’efforts perdus et un obstacle significatif à l’accès à des services essentiels.

Considérez ce scénario réel : une personne atteinte de sclérose en plaques fait une demande de prestation d’invalidité via un portail gouvernemental. Le formulaire comporte 12 sections et nécessite le téléversement de documents justificatifs. La session expire après 15 minutes d’inactivité, mais l’utilisateur s’est interrompu au milieu de la section 7 pour aller chercher un document dans une autre pièce. À son retour, toutes les données ont été effacées et il doit recommencer — sans aucun avertissement préalable que cela se produirait. En vertu de 2.2.6, le portail serait tenu d’informer l’utilisateur dès le départ qu’une inactivité de plus de 15 minutes entraînera une perte de données, lui permettant ainsi de planifier en conséquence.

Au-delà de l’accessibilité, la divulgation proactive du comportement de timeout améliore l’expérience utilisateur pour tout le monde et réduit les taux d’abandon sur les parcours de conversion à forte valeur ajoutée tels que le paiement, l’inscription et les formulaires de demande. Elle renforce également la confiance, car les utilisateurs ne se demandent plus pourquoi leurs données ont disparu.

Règles Axe-core associées

WCAG 2.2.6 nécessite des tests manuels. Il n’existe aucune règle axe-core automatisée capable de détecter cette violation, et comprendre pourquoi est important pour les testeurs et les développeurs.

• Test manuel requis — Divulgation du timeout de session : Les outils automatisés comme axe-core peuvent analyser le DOM pour détecter la présence ou l’absence d’éléments, d’attributs et de modèles de texte spécifiques, mais ils ne peuvent pas déterminer si une application web perdra les données d’un utilisateur après une période d’inactivité. Le comportement de timeout est généralement régi par la configuration de session côté serveur (par exemple, un TTL de session PHP ou Node.js), et la divulgation — si elle existe — peut apparaître dans un texte d’onboarding, une boîte de dialogue modale, une page d’aide ou même une section des conditions d’utilisation. Aucune analyse statique du DOM ne peut corréler de manière fiable un texte informatif avec le comportement réel de timeout côté serveur. Un outil ne peut pas savoir si une phrase comme « Pour votre sécurité, les sessions expirent après 15 minutes » est exacte, s’applique aux données de la page actuelle ou est positionnée suffisamment tôt dans le parcours utilisateur pour être exploitable. Seul un testeur humain, capable d’interagir avec l’application, d’observer son comportement dans le temps et d’évaluer l’exhaustivité et le moment de toute divulgation, peut déterminer la conformité.
• Test manuel requis — Vérification de la conservation des données : Axe-core ne peut pas non plus vérifier l’exception des 20 heures. Le fait que les données soient réellement stockées côté serveur pendant plus de 20 heures — et donc qu’une divulgation soit requise ou non — dépend entièrement de la logique backend, qui est invisible pour un outil d’analyse basé sur le navigateur. Les testeurs doivent soit examiner la configuration du serveur, soit parler avec les développeurs, soit tester empiriquement en laissant un formulaire partiellement rempli pendant une longue période et en observant si les données persistent.

Comment tester

1. Pré-analyse automatisée : Exécutez axe DevTools ou Lighthouse sur la page contenant le formulaire, le flux de paiement ou toute autre interface de saisie de données. Bien qu’aucun de ces outils ne signale directement une violation de 2.2.6, utilisez cette étape pour identifier d’éventuelles régions ARIA live ou composants de dialogue liés au timeout qui pourraient faire partie du mécanisme d’avertissement, et vérifiez qu’ils sont eux-mêmes accessibles (rôles, libellés, gestion du focus corrects).
2. Identifier le comportement de timeout : Discutez avec l’équipe de développement ou examinez la configuration côté serveur pour déterminer la durée du timeout d’inactivité de la session. Les emplacements courants incluent les fichiers de configuration du serveur web, les paramètres du middleware de session de l’application et la documentation du fournisseur d’authentification. Notez la durée exacte en minutes.
3. Vérifier la divulgation en amont : Chargez la page à neuf et lisez tout le contenu présenté à l’utilisateur avant le début de toute saisie de données. Recherchez une déclaration claire — dans le corps de la page, un paragraphe d’introduction, une bannière ou une modale — qui précise la durée exacte du timeout d’inactivité et indique que les données seront perdues si l’utilisateur reste inactif pendant cette période. La divulgation doit mentionner explicitement la durée (par exemple, « 15 minutes »), et non de manière vague (par exemple, « un court laps de temps »).
4. Tester avec un lecteur d’écran : En utilisant NVDA avec Firefox, VoiceOver avec Safari ou JAWS avec Chrome, naviguez sur la page depuis le tout début. Confirmez que toute divulgation de timeout est atteignable et lue à voix haute par le lecteur d’écran sans que l’utilisateur ait à la rechercher activement. Si la divulgation se trouve dans une bannière visuellement proéminente, vérifiez qu’elle se trouve dans l’ordre de lecture avant le premier champ de formulaire.
5. Simuler l’inactivité : Commencez à remplir le formulaire. Puis cessez d’interagir avec la page pendant une durée légèrement inférieure à la période de timeout, et observez ce qui se passe. Répétez ensuite en attendant que la période de timeout soit dépassée. Notez si les données sont perdues, si un avertissement est affiché avant que la perte de données ne se produise, et si cet avertissement a été communiqué avant le début de la session.
6. Tester l’exception des 20 heures : Si l’équipe affirme que les données sont conservées pendant plus de 20 heures, vérifiez-le empiriquement en remplissant partiellement un formulaire, en attendant au moins 20 heures, puis en revenant sur la page pour confirmer que les données sont toujours présentes. Alternativement, examinez avec l’équipe de développement la configuration du stockage de session côté serveur.
7. Tests clavier et focus : Si une boîte de dialogue ou une notification d’avertissement de timeout apparaît, vérifiez, en utilisant uniquement la navigation au clavier, qu’elle reçoit automatiquement le focus, que son contenu est entièrement lisible et que l’utilisateur peut la fermer ou agir (par exemple, prolonger la session) sans utiliser la souris.

Comment corriger

Session avec perte de données silencieuse — Incorrect

<!-- A multi-step form with a 10-minute server session timeout.
     No warning is displayed anywhere on the page.
     After 10 minutes of inactivity, the session is destroyed
     and all entered data is lost. -->
<form action='/submit-application' method='post'>
  <h1>Benefit Application</h1>
  <label for='full-name'>Full Name</label>
  <input type='text' id='full-name' name='full-name'>
  <!-- ... many more fields ... -->
  <button type='submit'>Submit Application</button>
</form>

Session avec perte de données silencieuse — Correct

<!-- The timeout duration is disclosed clearly before any form fields.
     The disclosure is in the natural reading order so screen readers
     encounter it before the first input. -->
<main>
  <h1>Benefit Application</h1>
  <div role='note' aria-label='Session timeout notice'>
    <p>
      <strong>Important:</strong> This form will time out after
      <strong>10 minutes of inactivity</strong>, and any information
      you have entered will be lost. Please have all required documents
      ready before you begin, or save your progress regularly.
    </p>
  </div>
  <form action='/submit-application' method='post'>
    <label for='full-name'>Full Name</label>
    <input type='text' id='full-name' name='full-name'>
    <!-- ... many more fields ... -->
    <button type='submit'>Submit Application</button>
  </form>
</main>

Session de paiement avec avertissement vague — Incorrect

<!-- The warning exists but is vague — it does not state the actual
     timeout duration, making it impossible for users to plan. -->
<p class='notice'>Your session may expire due to inactivity.</p>
<form action='/checkout' method='post'>
  <label for='card-number'>Card Number</label>
  <input type='text' id='card-number' name='card-number'
         autocomplete='cc-number'>
  <button type='submit'>Place Order</button>
</form>

Session de paiement avec avertissement vague — Correct

<!-- The warning now states the exact duration so users can
     make an informed decision about when to begin the checkout. -->
<p class='notice'>
  For your security, your checkout session will expire after
  <strong>20 minutes of inactivity</strong>. Any payment information
  entered will need to be re-entered if the session expires.
</p>
<form action='/checkout' method='post'>
  <label for='card-number'>Card Number</label>
  <input type='text' id='card-number' name='card-number'
         autocomplete='cc-number'>
  <button type='submit'>Place Order</button>
</form>

Données conservées côté serveur pendant plus de 20 heures — Correct (exception applicable)

<!-- When all form data is saved to the server continuously
     and preserved for at least 20 hours, no timeout warning
     is required by 2.2.6. This is the ideal UX pattern:
     autosave is indicated to the user for transparency. -->
<main>
  <h1>Job Application</h1>
  <p>
    Your progress is automatically saved as you type.
    You can leave and return to this form at any time within
    <strong>30 days</strong> and your answers will be preserved.
  </p>
  <form action='/apply' method='post'>
    <label for='cover-letter'>Cover Letter</label>
    <textarea id='cover-letter' name='cover-letter'></textarea>
    <p aria-live='polite' id='autosave-status'>Draft saved.</p>
    <button type='submit'>Submit Application</button>
  </form>
</main>

Erreurs courantes

• Afficher l’avertissement de timeout uniquement dans la console du navigateur ou dans une entrée de journal serveur invisible pour les utilisateurs finaux — l’avertissement doit être présenté dans l’interface utilisateur, à un endroit où l’utilisateur le verra avant que la perte de données ne se produise.
• Placer la divulgation dans un pied de page, une politique de confidentialité ou une page de conditions d’utilisation que les utilisateurs sont peu susceptibles de lire avant de commencer la saisie de données, plutôt que directement sur le formulaire ou immédiatement avant celui-ci.
• Utiliser une boîte de dialogue modale pour avertir les utilisateurs d’une expiration de session imminente mais ne pas déplacer le focus clavier sur la boîte de dialogue — les utilisateurs de clavier et de lecteur d’écran peuvent ne jamais se rendre compte que l’avertissement est apparu.
• Indiquer une durée de session (par exemple, « votre session dure 30 minutes ») plutôt qu’un timeout d’inactivité (par exemple, « après 15 minutes d’inactivité, vos données seront perdues ») — ce sont des concepts différents, et seule la perte de données déclenchée par l’inactivité est régie par 2.2.6.
• Supposer que, parce qu’une modale d’avertissement de timeout existe pour les utilisateurs voyants, le critère est satisfait — si la modale n’est pas accessible au clavier, n’a pas de nom accessible ou n’est pas annoncée via des régions ARIA live ou la gestion du focus, les utilisateurs de lecteurs d’écran ne recevront pas l’avertissement.
• Régler le timeout de session côté serveur sur 25 heures et conclure qu’aucune divulgation n’est nécessaire, sans vérifier que l’état côté navigateur ou au niveau de l’application (par exemple, un store Redux ou localStorage) n’est pas effacé plus tôt — le timeout effectif est celui du mécanisme qui perd les données en premier.
• Divulguer la durée du timeout dans une info-bulle déclenchée uniquement au survol — les utilisateurs qui s’appuient sur la navigation au clavier ou sur des appareils tactiles peuvent ne jamais voir la divulgation.
• Se fier à un avertissement générique du CMS ou du framework indiquant « session expirée » affiché après que la perte de données s’est déjà produite, plutôt que d’informer proactivement les utilisateurs avant qu’ils ne commencent à saisir des données.
• Ne pas tenir compte des utilisateurs qui ouvrent le formulaire dans un onglet en arrière-plan : si le minuteur de session tourne alors que l’onglet est inactif, les données peuvent être perdues avant que l’utilisateur n’ait eu la moindre possibilité d’interagir avec le formulaire. C’est particulièrement problématique sur les navigateurs mobiles qui suspendent agressivement les onglets en arrière-plan.
• Omettre l’avertissement sur les versions mobiles ou dans les contextes d’application web progressive (PWA) tout en l’affichant sur la version de bureau, créant une expérience incohérente qui ne respecte pas 2.2.6 pour une part significative des utilisateurs.

Lien 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 des obligations contraignantes en matière d’accessibilité web pour un large éventail d’entités publiques et privées opérant en Turquie. La circulaire impose la conformité à WCAG 2.2 comme norme technique, exigeant des entités concernées qu’elles atteignent au minimum le niveau de conformité AA. WCAG 2.2.6 Timeouts est un critère de niveau AAA et n’est donc pas directement imposé par les exigences de base de la circulaire. Cependant, la portée et l’objectif de la circulaire créent de fortes raisons pratiques pour que les entités concernées visent la conformité AAA sur des critères tels que 2.2.6.

Les entités couvertes par la Circulaire présidentielle 2025/10 incluent les institutions et agences publiques, les plateformes de commerce électronique, les banques et institutions financières, les hôpitaux et prestataires de soins de santé, les opérateurs de télécommunications comptant plus de 200,000 abonnés, les agences de voyage, les entreprises de transport privé et les écoles privées autorisées par le Ministry of National Education (MoNE). Beaucoup de ces secteurs exploitent des portails en ligne qui impliquent précisément les types de flux de saisie de données que 2.2.6 est conçu pour protéger : demandes de prêt, formulaires d’admission de patients, systèmes de réservation de billets, formulaires d’inscription et demandes de prestations gouvernementales.

Pour les banques et les plateformes de commerce électronique en particulier, les timeouts de session sont une mesure de sécurité courante, et l’interaction entre les exigences de sécurité et les obligations d’accessibilité est directement pertinente. Bien qu’une banque puisse avoir l’obligation réglementaire de mettre fin aux sessions inactives après une période fixe, la mise en œuvre de WCAG 2.2.6 en divulguant la durée du timeout en amont n’entre pas en conflit avec cette exigence de sécurité — elle la complète. Les utilisateurs sont informés de la contrainte sans que la banque n’ait besoin d’affaiblir sa posture de sécurité des sessions.

Les prestataires de soins de santé et les hôpitaux couverts par la circulaire gèrent certaines des tâches de saisie de données les plus critiques qui soient — formulaires d’historique médical, demandes de pré-autorisation et systèmes de prise de rendez-vous. Les patients ayant des handicaps cognitifs ou des déficiences motrices qui perdent leurs données en cours de formulaire dans ces contextes font face non seulement à de la frustration, mais aussi à un risque de retard dans l’accès aux soins. La mise en œuvre de 2.2.6 dans ces environnements est une expression directe du mandat de service inclusif qui sous-tend la circulaire.

Bien que le niveau AAA ne soit pas légalement requis, l’atteindre sur des critères comme 2.2.6 — qui nécessitent un effort de mise en œuvre relativement faible (ajouter une simple déclaration de divulgation exacte à un formulaire) tout en apportant un bénéfice significatif aux groupes d’utilisateurs vulnérables — représente une pratique d’accessibilité exemplaire. Les organisations souhaitant démontrer leur engagement en faveur de l’inclusion numérique sur le marché turc, ou celles anticipant un renforcement futur de la réglementation, ont tout intérêt à traiter 2.2.6 comme un objectif de mise en œuvre pratique plutôt que comme une aspiration optionnelle.