Pour chaque page web, l’utilisateur a-t-il le contrôle de chaque limite de temps modifiant le contenu (hors cas particuliers) ?
Un utilisateur de lecteur d’écran remplit un formulaire administratif complexe. Sa session expire après dix minutes d’inactivité : sans avertissement, sans bouton « Prolonger », il se retrouve sur la page de connexion. Tout son travail est perdu. Ce scénario, courant dans les applications authentifiées, les intranets ou les espaces membres, est exactement ce que le critère 13.1 cherche à prévenir.
Ce critère couvre trois catégories de limites de temps : les rafraîchissements automatiques de contenu (via <meta http-equiv="refresh">, <object>, <embed>, <svg> ou <canvas>), les redirections automatiques déclenchées par <meta> ou par script JavaScript, et les expirations de session après authentification. Pour chaque occurrence, l’utilisateur doit disposer d’au moins un moyen de contrôle : stopper et relancer, multiplier le délai par dix, recevoir une alerte avec 20 secondes pour agir, ou bénéficier d’un délai initial supérieur à 20 heures.
Une seule condition suffit. La plus simple à déployer dans une application authentifiée : afficher une boîte de dialogue avant l’expiration avec un bouton « Prolonger la session » accessible au clavier et annoncé par les lecteurs d’écran via role="alertdialog".
Cas particulier à retenir : une redirection <meta http-equiv="refresh" content="0;URL='...'" /> avec délai zéro est toujours conforme. Délai zéro signifie redirection transparente — aucun contenu intermédiaire ne disparaît à la vue de l’utilisateur.
4 tests pour vérifier que chaque limite de temps est contrôlable
Mécanisme de contrôle des rafraîchissements automatiques
- Repérez dans le
<head>tout<meta http-equiv="refresh" content="N">avec N > 0. Repérez aussi les éléments<object>,<embed>,<svg>et<canvas>qui déclenchent un rafraîchissement périodique du contenu. - Pour chaque rafraîchissement trouvé, vérifiez qu’au moins une des conditions suivantes est remplie :
- Un bouton ou mécanisme permet d’arrêter et de relancer le rafraîchissement.
- Un mécanisme permet d’augmenter l’intervalle d’au moins dix fois sa valeur initiale.
- Une alerte avertit l’utilisateur avant le rafraîchissement et lui laisse au moins 20 secondes pour repousser l’échéance.
- L’intervalle entre deux rafraîchissements est supérieur ou égal à 20 heures.
- Si aucune condition n’est remplie pour un rafraîchissement : test échoué. Si toutes les occurrences satisfont au moins une condition : test validé.
Redirection immédiate via <meta http-equiv=refresh>
- Recherchez dans le
<head>un<meta http-equiv="refresh">dont l’attributcontentcommence par0;URL=(délai de zéro seconde avec une URL cible). - Vérifiez que la valeur du délai est exactement
0, pas1ou plus. - Si le délai est 0 : redirection immédiate, test validé. Si le délai est supérieur à 0 sans mécanisme de contrôle utilisateur, référez-vous au test 13.1.1.
Mécanisme de contrôle des redirections automatiques par script
- Repérez les redirections automatiques déclenchées par JavaScript :
setTimeout(() => { window.location.href = '...'; }, N), des décomptes affichés à l’écran, ou tout autre mécanisme de redirection différée par script. - Pour chaque redirection trouvée, vérifiez qu’au moins une condition est satisfaite :
- Un mécanisme permet d’annuler et de relancer la redirection.
- Un mécanisme permet de multiplier le délai par dix au moins.
- Une alerte s’affiche avant la redirection et laisse 20 secondes à l’utilisateur pour repousser l’échéance.
- Le délai avant redirection est supérieur ou égal à 20 heures.
- Si aucune condition n’est remplie pour une redirection : test échoué. Si toutes les occurrences sont conformes : test validé.
Mécanisme de contrôle ou durée minimale du timeout de session
- Identifiez les mécanismes d’expiration de session sur les pages authentifiées (timeout serveur, déconnexion automatique après inactivité, expiration de jeton).
- Pour chaque expiration de session, vérifiez qu’au moins une des conditions suivantes est remplie :
- L’utilisateur peut désactiver complètement la limite de temps.
- L’utilisateur peut prolonger la session (via une alerte et un bouton « Rester connecté »).
- La session dure 20 heures ou plus.
- Exception : si la limite est constitutive de l’activité (enchère en direct, examen chronométré) ou supérieure à 20 heures, le critère est non applicable.
- Si au moins une condition est remplie pour chaque procédé identifié : test validé.
Exemples
❌ Non conforme : Rafraîchissement automatique toutes les 30 secondes sans contrôle
<!DOCTYPE html>
<html lang="fr">
<head>
<meta charset="UTF-8">
<meta http-equiv="refresh" content="30">
<title>Tableau de bord</title>
</head>
<body>
<main>
<h1>Activité en cours</h1>
<p>Dernière mise à jour : 14h32</p>
<!-- Aucun bouton Pause, aucune alerte avant rechargement -->
</main>
</body>
</html>La page se recharge toutes les 30 secondes. Un utilisateur de lecteur d’écran perd sa position de lecture à chaque cycle : son curseur virtuel revient en haut du document. Un utilisateur avec des troubles cognitifs est désorienté par la disparition soudaine du contenu. Aucun mécanisme ne lui permet de stopper ce comportement.
✅ Conforme : Expiration de session avec alerte et bouton de prolongation
<!-- Modale affichée 2 minutes avant l'expiration de session -->
<div
role="alertdialog"
aria-modal="true"
aria-labelledby="session-title"
aria-describedby="session-desc"
>
<h2 id="session-title">Votre session expire bientôt</h2>
<p id="session-desc">
Votre session expirera dans
<span id="countdown" aria-live="off">2:00</span>.
Souhaitez-vous la prolonger ?
</p>
<button type="button" onclick="extendSession()">Prolonger la session</button>
<button type="button" onclick="logout()">Se déconnecter</button>
</div>L’alerte s’affiche 2 minutes avant l’expiration — bien au-delà des 20 secondes réglementaires. Le bouton « Prolonger la session » répond à la condition « mécanisme permettant d’augmenter la limite de temps » du test 13.1.4. Le role="alertdialog" garantit que le lecteur d’écran annonce immédiatement la boîte de dialogue à l’utilisateur.
✅ Conforme : Redirection immédiate conforme via meta refresh à zéro
<!DOCTYPE html>
<html lang="fr">
<head>
<meta charset="UTF-8">
<!-- Ancienne URL redirige vers la nouvelle, sans délai -->
<meta http-equiv="refresh" content="0;URL='https://example.com/nouvelle-page'" />
<title>Redirection en cours...</title>
</head>
<body>
<p>
Cette page a été déplacée.
<a href="https://example.com/nouvelle-page">Accéder à la nouvelle page</a>
</p>
</body>
</html>Le délai de zéro seconde correspond à une redirection transparente : l’utilisateur ne lit aucun contenu intermédiaire qui disparaîtrait. Ce cas est explicitement validé par le test 13.1.2. Le lien de secours dans le <body> est une bonne pratique supplémentaire pour les navigateurs qui bloquent les meta refresh.
Astuces et pièges
⚠️ Le timeout de session côté serveur est invisible dans le HTML
La limite de temps existe souvent uniquement côté serveur (configuration PHP, Node.js, reverse proxy). Aucune balise dans le source HTML ne la trahit. En audit, testez directement : connectez-vous, laissez la session inactive pendant la durée configurée, puis interagissez. Si la page redirige vers la connexion sans avertissement préalable, le test 13.1.4 est non conforme — même si le code source ne contient rien de visible.
⚠️ Confondre meta refresh zéro et meta refresh avec délai
<meta http-equiv="refresh" content="0;URL='...'" /> est conforme (test 13.1.2 validé). <meta http-equiv="refresh" content="5;URL='...'" /> sans mécanisme de contrôle ne l’est pas (test 13.1.1 non conforme). La distinction : zéro seconde, pas de contenu intermédiaire perceptible ; cinq secondes, l’utilisateur voit un contenu qui disparaît sans pouvoir l’en empêcher.
⚠️ Enchères en direct et examens chronométrés : critère non applicable
Quand la limite de temps est constitutive de l’activité — une enchère qui se clôt à heure fixe, un examen dont la durée est la contrainte même — supprimer ou prolonger le délai changerait fondamentalement la fonctionnalité. Le critère est non applicable. En revanche, un CAPTCHA qui se régénère automatiquement après 10 minutes ne tombe pas dans cette exemption : ce n’est pas essentiel qu’il expire, et un utilisateur avec une technologie d’assistance peut légitimement mettre plus de 10 minutes à le résoudre.
💡 Le seuil de 20 heures rend la plupart des cases « Rester connecté » conformes de facto
Une option « Se souvenir de moi » qui maintient la session pendant 7 jours est automatiquement conforme au test 13.1.4 : le délai dépasse largement 20 heures. Concentrez l’effort de remédiation sur les sessions courtes (10, 15, 30 minutes) sans mécanisme de prolongation.
⚠️ Le rafraîchissement d’un flux RSS dans la page est applicable
Une page qui actualise automatiquement un flux d’actualités ou un tableau de bord en temps réel entre dans le champ du test 13.1.1. Ce n’est pas une limite « essentielle » : le contenu peut être consulté sans rafraîchissement automatique. Ajoutez un bouton « Pause » ou proposez un rechargement manuel.
Questions fréquentes
Pourquoi un carrousel à défilement automatique est-il soumis au critère RGAA 13.1 ?
Non. Les carrousels et animations en boucle relèvent du critère 13.8 (mettre en pause, arrêter, masquer), pas du 13.1. Le critère 13.1 porte spécifiquement sur les limites de temps qui rechargent la page, redirigent l’utilisateur ou expirent une session. Ce sont deux problèmes distincts avec deux critères distincts.
Comment rendre conforme une déconnexion automatique après 30 minutes d'inactivité selon RGAA 13.1 ?
Implémentez un role="alertdialog" qui s’affiche au moins 20 secondes avant la déconnexion, avec un bouton de prolongation de session. Ce bouton doit fonctionner sans rechargement complet de la page et sans obliger l’utilisateur à se réauthentifier. Cette approche valide le test 13.1.4 et satisfait le WCAG 2.2.1 (niveau A). La durée de prolongation n’est pas imposée par le RGAA : 20 minutes est une valeur courante et raisonnable.
Comment auditer un timeout de session qui n'est pas visible dans le code source ?
Trois approches complémentaires : attendez naturellement que la session expire (15 à 30 minutes d’inactivité), surveillez les requêtes réseau pour détecter les appels de vérification de session et leur fréquence, ou demandez directement la configuration à l’équipe technique. En audit RGAA, si le timeout est confirmé et qu’aucun avertissement ne s’affiche, le critère est non conforme.
Quand une redirection automatique vers une URL obsolète est-elle conforme au critère RGAA 13.1 ?
Oui, c’est l’exemple exact cité par le RGAA pour l’exception « limite essentielle » : le critère est non applicable. La redirection depuis une URL obsolète est une correction d’infrastructure, pas un choix de design. En revanche, si c’est une page d’attente après connexion qui redirige vers un tableau de bord, ce n’est pas essentiel : utilisez une redirection immédiate (content="0") ou un mécanisme de contrôle.
Quelle durée minimale de session rend le critère RGAA 13.1 conforme sans mécanisme supplémentaire ?
Oui : 20 heures. Si la session dure au moins 20 heures par défaut, aucun mécanisme de prolongation n’est requis (test 13.1.4, condition c). La même règle s’applique aux rafraîchissements automatiques : un intervalle de 20 heures ou plus satisfait les tests 13.1.1 et 13.1.3 sans aucune interface de contrôle. En pratique, peu d’applications atteignent ce seuil, donc la solution du dialogue d’avertissement reste la voie la plus réaliste.