RGAA Lab

RGAA 4.1.2 · Consultation · Critère 13.1

Pour chaque page web, l’utilisateur a-t-il le contrôle de chaque limite de temps modifiant le contenu (hors cas particuliers) ?

Une page qui se recharge, redirige ou expire toute seule interrompt la lecture au milieu d'une phrase — et fait perdre la saisie en cours à qui écrit lentement.

Ce que dit le référentiel

Transcription du RGAA 4.1.2, sans interprétation. C’est ce texte qui fait foi, et celui que vous citez dans un rapport.

  1. 13.1.1
    Pour chaque page web, chaque procédé de rafraîchissement (balise <object>, balise <embed>, balise <svg>, balise <canvas>, balise <meta>) vérifie-t-il une de ces conditions (hors cas particuliers) ?
    • L’utilisateur peut arrêter ou relancer le rafraîchissement ;
    • L’utilisateur peut augmenter la limite de temps entre deux rafraîchissements de dix fois, au moins ;
    • L’utilisateur est averti de l’imminence du rafraîchissement et dispose de vingt secondes, au moins, pour augmenter la limite de temps avant le prochain rafraîchissement ;
    • La limite de temps entre deux rafraîchissements est de vingt heures, au moins.
  2. 13.1.2
    Pour chaque page web, chaque procédé de redirection effectué via une balise <meta> est-il immédiat (hors cas particuliers) ?
  3. 13.1.3
    Pour chaque page web, chaque procédé de redirection effectué via un script vérifie-t-il une de ces conditions (hors cas particuliers) ?
    • L’utilisateur peut arrêter ou relancer la redirection ;
    • L’utilisateur peut augmenter la limite de temps avant la redirection de dix fois, au moins ;
    • L’utilisateur est averti de l’imminence de la redirection et dispose de vingt secondes, au moins, pour augmenter la limite de temps avant la prochaine redirection ;
    • La limite de temps avant la redirection est de vingt heures, au moins.
  4. 13.1.4
    Pour chaque page web, chaque procédé limitant le temps d’une session vérifie-t-il une de ces conditions (hors cas particuliers) ?
    • L’utilisateur peut supprimer la limite de temps ;
    • L’utilisateur peut augmenter la limite de temps ;
    • La limite de temps avant la fin de la session est de vingt heures au moins.

Comment le vérifier

  1. Repérer les procédés de rafraîchissement automatique : <meta http-equiv="refresh">, contenus animés en <object>, <embed>, <svg>, <canvas> qui se remettent à jour seuls.
  2. Repérer les redirections : celles d'un <meta> doivent être immédiates, celles d'un script doivent être contrôlables.
  3. Repérer les limites de session : rester inactif et observer ce qui se passe, ou lire la documentation du service.
  4. Pour un rafraîchissement ou une redirection, vérifier qu'une des issues est offerte : arrêter ou relancer, multiplier la limite par dix, être averti vingt secondes avant, ou une limite d'au moins vingt heures.
  5. Pour une limite de session, les issues ne sont pas les mêmes : pouvoir supprimer la limite, pouvoir l'augmenter, ou une limite d'au moins vingt heures. L'avertissement vingt secondes avant ne suffit pas ici.

Ce que notre outil fait

Assisté

Le moteur repère les éléments concernés et vous pose la question. Il ne conclut pas à votre place.

La règle ne couvre qu'un cas, mais sans ambiguïté : le <meta refresh> à délai intermédiaire — ni immédiat, ni supérieur à vingt heures. Les rafraîchissements scriptés et les limites de session lui échappent complètement : ils demandent d'attendre et d'observer.

Règles ACT du W3C mises en œuvre : bc659a

Comment nous mesurons ce que l'outil sait faire · ce critère s'audite dans l'extension RGAA Lab.

Les pièges

Les erreurs qu’on rencontre vraiment, relevées au fil des audits.

  • Une déconnexion pour inactivité est une limite de temps : elle relève du critère, même si elle est justifiée par la sécurité.
  • Un carrousel qui défile seul relève du 13.8, pas du 13.1 — sauf s'il recharge réellement la page.
  • « Vous allez être redirigé dans 5 secondes » sans possibilité d'arrêter ne satisfait aucune des quatre conditions.

À lire avec