Expiration de session : la barrière d'accessibilité oubliée

Vous remplissez un long formulaire administratif, vous cherchez une pièce justificative, et au retour : session expirée, tout est à refaire. Pour beaucoup, c'est agaçant. Pour une personne qui saisit lentement, qui utilise un lecteur d'écran ou qui a un trouble de l'attention, c'est un mur. Cet article explique pourquoi les délais d'expiration sont une barrière d'accessibilité, ce qu'exigent le RGAA et les WCAG, et comment concevoir des limites de temps qui n'excluent personne.

Pourquoi un délai d'expiration exclut une partie des utilisateurs

Une limite de temps part d'une hypothèse : tout le monde avance au même rythme. C'est faux. Plusieurs profils ont besoin de plus de temps pour la même tâche.

• Handicaps moteurs : tremblements, coordination difficile, technologies d'adaptation qui demandent plusieurs tentatives pour enregistrer une saisie. Un formulaire chronométré peut effacer des heures de travail.
• Handicaps cognitifs : avec un TDAH ou un trouble de l'attention, la perception du temps est altérée (on parle de « cécité temporelle »). Un site qui suppose que l'utilisateur estime le temps restant exclut silencieusement ces personnes.
• Utilisateurs de lecteurs d'écran : la lecture séquentielle prend plus de temps, et un minuteur qui annonce le compte à rebours chaque seconde devient un flux de messages ininterrompu, décrit comme « horrible » par les personnes concernées.

Ce constat est documenté en détail par Smashing Magazine, qui recense ces retours d'utilisateurs et de spécialistes.

Ce qu'exigent le RGAA 13.1 et les WCAG

Côté français, le critère RGAA 13.1 demande que, pour chaque page, l'utilisateur garde le contrôle de toute limite de temps qui modifie ou supprime du contenu (hors cas particuliers). La version en vigueur reste le RGAA 4.1.2 (avril 2023).

Ce critère s'aligne sur trois exigences WCAG. Voici comment elles s'articulent.

L'essentiel tient dans le 2.2.1 (niveau AA) : une limite de temps n'est acceptable que si l'utilisateur peut la maîtriser. Avertir, puis laisser au moins 20 secondes pour prolonger d'un geste simple, est le minimum.

Concevoir une expiration de session accessible

Le bon réflexe n'est pas de supprimer toute limite, mais de rendre la main à l'utilisateur. Cinq règles concrètes.

1. Avertir avant, pas après. Affichez un dialogue « Avez-vous besoin de plus de temps ? » avant l'expiration. Plusieurs services publics avertissent au moins 2 minutes à l'avance.
2. Permettre de prolonger en un clic. Un seul bouton « Rester connecté » qui réarme le compteur, sans reprendre tout le parcours.
3. Préserver les données saisies. Sauvegardez côté client (localStorage, sessionStorage) ou serveur, pour restaurer le formulaire après une éventuelle reconnexion.
4. Annoncer la limite dès le départ. Indiquez clairement, en début de parcours, qu'une limite de temps existe et laquelle.
5. Bannir les délais arbitraires. Ne chronométrez pas la lecture d'un article ou la navigation. Réservez les limites aux cas qui le justifient vraiment.

Les exceptions légitimes (et leurs limites)

Toutes les limites de temps ne sont pas à supprimer. WCAG prévoit des exceptions quand le délai est essentiel :

• Sécurité : une session bancaire ou un espace de santé qui se ferme après inactivité protège l'utilisateur sur un poste partagé.
• Temps réel : une billetterie en direct ou une enchère impose un délai par nature.
• Postes partagés : un ordinateur en bibliothèque a besoin de se déconnecter.

Ces cas sont recevables, mais ils ne dispensent pas de prévenir l'utilisateur, ni de préserver ce qui peut l'être. Une session bancaire peut expirer pour la sécurité tout en restaurant le formulaire en cours après reconnexion. L'exception porte sur la déconnexion, pas sur le droit de faire perdre le travail.

Pourquoi ce critère se teste à la main

C'est un point d'honnêteté important. Une limite de temps est un comportement temporel : un scanner automatique ne sait pas, seul, mesurer si vous avertissez à temps, si la prolongation fonctionne au clavier, ou si les données sont préservées. Le RGAA 13.1 relève d'une vérification largement manuelle.

Un audit automatique repère les blocages techniques évidents et priorise le travail, mais il ne remplace pas un test de parcours réel, idéalement avec des personnes qui prennent plus de temps. C'est la même logique que pour les CAPTCHA accessibles, autre point de friction des parcours authentifiés.

Conclusion

Une expiration de session mal pensée transforme une simple formalité en parcours du combattant pour ceux qui avancent à un autre rythme. La règle est simple : avertir, laisser prolonger, ne rien faire perdre. Intégrez-la dès la conception de vos formulaires accessibles, surtout sur les parcours critiques (compte, paiement, démarche administrative).

Pour situer ce point parmi vos autres critères, lancez un audit RGAA gratuit et repérez vos blocages prioritaires, avant de compléter par un test manuel des limites de temps.