RGAA 13.1 — Pour chaque page web, l'utilisateur a-t-il le contrôle de chaque limite de temps modifiant le contenu ?

Délai de session sans avertissement

Le problème

Un délai de session sans avertissement se produit lorsqu'une application web impose une limite de temps (session qui expire, formulaire qui se réinitialise, panier qui se vide, page qui redirige automatiquement) sans en informer l'utilisateur au préalable et sans lui offrir la possibilité de prolonger ou de désactiver cette limite. Le critère RGAA 13.1 (correspondant au WCAG 2.2.1, niveau A) exige que pour chaque limite de temps, l'utilisateur puisse soit la désactiver, soit la prolonger, soit être averti avant son expiration et disposer d'au moins 20 secondes pour la prolonger.

Les exemples courants incluent : les sessions bancaires ou de e-commerce qui expirent après 15 minutes d'inactivité sans avertissement, les formulaires multi-étapes qui perdent les données si l'utilisateur met trop de temps, les questionnaires ou examens en ligne avec un chronomètre strict, et les pages de résultats de recherche qui expirent après un certain temps.

Les exceptions à ce critère sont les limites de temps en temps réel (enchères, événements en direct), les limites de plus de 20 heures, et les limites essentielles à la sécurité (à condition qu'aucune alternative n'existe).

Impact sur les utilisateurs

Pour les utilisateurs ayant des handicaps moteurs qui saisissent du texte lentement (commutateurs, pointeurs oculaires, claviers virtuels), les délais de session standard sont souvent insuffisants. Remplir un formulaire qui prend 5 minutes à un utilisateur valide peut en prendre 30 à une personne utilisant un dispositif de saisie alternatif. Si la session expire sans avertissement, tout le travail est perdu.

Les personnes ayant des troubles cognitifs ou des difficultés de lecture ont besoin de plus de temps pour comprendre le contenu et remplir les formulaires. Les personnes âgées sont aussi affectées car elles naviguent souvent plus lentement.

Les utilisateurs de lecteurs d'écran prennent généralement plus de temps pour naviguer et comprendre la structure d'une page. Une session qui expire pendant qu'ils explorent le formulaire les oblige à recommencer depuis le début, ce qui est extrêmement frustrant.

Votre site a-t-il ce problème ?

106 critères RGAA analysés en 5 minutes par notre IA.

Testez votre site gratuitement

Exemple de code

Avant (non conforme)
<!-- Session qui expire silencieusement -->
<script>
  // Déconnexion après 15 minutes sans avertissement
  setTimeout(() => {
    window.location.href = '/connexion?expired=true';
  }, 15 * 60 * 1000);
</script>

<!-- Formulaire qui se réinitialise -->
<script>
  // Vide le formulaire après 10 minutes
  setTimeout(() => {
    document.querySelector('form').reset();
  }, 10 * 60 * 1000);
</script>
Après (conforme)
<!-- Session avec avertissement et prolongation -->
<script>
  const SESSION_TIMEOUT = 15 * 60 * 1000;
  const WARNING_BEFORE = 2 * 60 * 1000;

  setTimeout(() => {
    // Afficher une modale d'avertissement
    showWarningDialog({
      message: 'Votre session expire dans 2 minutes.',
      actions: [
        { label: 'Prolonger la session', action: extendSession },
        { label: 'Se déconnecter', action: logout }
      ],
      // L'utilisateur a au moins 20 secondes pour réagir
      autoLogoutDelay: 120000
    });
  }, SESSION_TIMEOUT - WARNING_BEFORE);

  function extendSession() {
    fetch('/api/extend-session', { method: 'POST' });
    // Redémarrer le timer
  }
</script>

<!-- Modale d'avertissement accessible -->
<div role="alertdialog" aria-modal="true"
  aria-label="Avertissement de session">
  <p>Votre session expire dans 2 minutes.</p>
  <button onclick="extendSession()">
    Prolonger ma session
  </button>
  <button onclick="logout()">
    Se déconnecter
  </button>
</div>

Comment Scrutia détecte ce problème

Scrutia détecte les scripts de gestion de session (setTimeout, setInterval avec redirection ou réinitialisation) et vérifie la présence d'un mécanisme d'avertissement avant expiration. Il recherche les modales de type alertdialog avec des boutons de prolongation. Le rapport signale les délais de session sans mécanisme d'avertissement et propose une implémentation accessible.

Questions fréquentes

Quel délai minimum accorder avant l'avertissement ?
Le WCAG exige que l'utilisateur soit averti au moins 20 secondes avant l'expiration et puisse prolonger la session d'un simple geste (clic, touche). Idéalement, l'avertissement apparaît 1 à 2 minutes avant l'expiration pour laisser le temps de réagir.
Les sessions bancaires sont-elles exemptées ?
Les limites de temps essentielles à la sécurité sont exemptées uniquement si aucune alternative n'existe. Cependant, la plupart des banques ajoutent un avertissement avant expiration avec un bouton de prolongation, ce qui est à la fois sécurisé et accessible.
La modale d'avertissement doit-elle être accessible ?
Oui. La modale d'avertissement doit utiliser role='alertdialog', être focusable, recevoir le focus automatiquement quand elle apparaît, et ses boutons doivent être accessibles au clavier. Un rôle 'alert' seul ne suffit pas car l'utilisateur doit pouvoir interagir.
Combien de fois l'utilisateur peut-il prolonger la session ?
Le WCAG recommande que l'utilisateur puisse prolonger la session au moins 10 fois. En pratique, il est préférable de permettre un nombre illimité de prolongations tant que l'utilisateur est actif sur la page.

Votre site a-t-il ce problème ?

Scrutia audite votre site sur 106 critères RGAA en 5 minutes. Navigation clavier, composants ARIA, focus visible, contrastes, et bien plus.

Lancer un audit gratuit