Meta http-equiv refresh : pourquoi le rechargement minuté peut faire échouer les WCAG

Meta http-equiv refresh : ce que fait la balise et pourquoi elle pose problème

La valeur numérique placée dans l'attribut content indique le délai, en secondes, avant le rechargement. Avec content="60", la page se recharge toutes les soixante secondes, sans aucune action de la personne qui la consulte. Le W3C présente ce code comme un exemple déconseillé et demande aux développeurs de ne pas s'en servir pour simuler une technologie « push ».

Le problème tient au temps de lecture. Selon la description de l'échec F41, si l'intervalle est trop court et qu'il n'existe aucun moyen de couper le rafraîchissement automatique, les personnes aveugles n'ont pas le temps de faire lire la page par leur lecteur d'écran : la page se recharge de façon inattendue et le lecteur d'écran recommence sa lecture en haut de la page. Les utilisateurs voyants peuvent eux aussi être désorientés par ce rechargement inattendu.

Le W3C rappelle qu'un développeur ne peut pas prévoir le temps dont un utilisateur aura besoin pour lire une page, et qu'un rechargement prématuré peut désorienter les utilisateurs. Sa recommandation est nette : éviter le rafraîchissement périodique et permettre aux utilisateurs de choisir le moment où ils veulent obtenir les informations les plus récentes.

<!-- Exemple d'échec F41 : la page se recharge toutes les 60 secondes -->
<head>
  <title>Tableau de bord</title>
  <meta http-equiv="refresh" content="60" />
</head>

Pourquoi un rechargement automatique est un délai au sens du critère 2.2.1

Le critère 2.2.1 Réglage du délai, de niveau A, vise à ce que les utilisateurs disposent d'un temps suffisant pour accomplir leurs tâches. Sa documentation précise que tout processus qui se produit sans initiative de l'utilisateur après un temps défini, ou de façon périodique, constitue une limite de temps. Les mises à jour partielles ou complètes du contenu, comme le rafraîchissement d'une page, en font explicitement partie.

Pour chaque limite de temps fixée par le contenu, au moins une des conditions suivantes doit être remplie :

• Désactiver : l'utilisateur peut désactiver la limite de temps avant d'y être confronté.
• Ajuster : l'utilisateur peut ajuster la limite avant d'y être confronté, sur une large plage atteignant au moins dix fois la durée par défaut.
• Prolonger : l'utilisateur est averti avant l'expiration, dispose d'au moins 20 secondes pour prolonger le délai par une action simple (par exemple appuyer sur la barre d'espace) et peut prolonger au moins dix fois.
• Exception temps réel : la limite fait partie intégrante d'un événement en temps réel, comme une enchère, et aucune alternative n'est possible.
• Exception de l'essentiel : la limite est essentielle et la prolonger invaliderait l'activité.
• Exception des 20 heures : la limite dépasse 20 heures.

Comment tester une page qui utilise meta http-equiv refresh

L'échec F41 s'accompagne d'une procédure de test applicable à toute page HTML qui contient meta http-equiv="refresh". Elle comporte cinq vérifications :

• 1. La valeur numérique des secondes avant rafraîchissement est-elle présente dans l'attribut content ?
• 2. Cette valeur est-elle inférieure à 1 ou supérieure à 72 000 ?
• 3. La page relève-t-elle de l'exception temps réel ou de l'exception de l'essentiel du critère 2.2.1 ?
• 4. L'utilisateur a-t-il la possibilité de désactiver, de prolonger ou d'ajuster le délai du rafraîchissement ?
• 5. La page ne se rafraîchit-elle pas, en pratique, après la durée indiquée dans l'attribut content ?

Lire les résultats du test critère par critère

Les résultats attendus ne combinent pas les mêmes vérifications pour les trois critères. Pour le critère 2.2.1, les vérifications 1 à 5 entrent en jeu. Pour le critère 2.2.4, ce sont les vérifications 1, 2, 4 et 5. Pour le critère 3.2.5, seules les vérifications 1 et 4 comptent. Conséquence pratique : les exceptions temps réel et de l'essentiel (vérification 3) ne sont prises en compte que pour le critère 2.2.1, et la valeur du délai (vérification 2) n'intervient pas pour le critère 3.2.5. Une page couverte par une exception du 2.2.1 n'est donc pas, de ce seul fait, à l'abri pour les critères 2.2.4 et 3.2.5.

Gardez aussi en tête une précision générale du W3C sur les techniques d'échec : elles montrent comment un contenu peut échouer à un critère, mais ce contenu peut malgré tout satisfaire le critère s'il propose un contenu ou une fonctionnalité équivalente qui, elle, respecte les exigences normatives.

Le W3C liste enfin, pour le critère 2.2.1, deux règles de test approuvées qui portent directement sur ce sujet : « Meta element has no refresh delay » et sa variante « Meta element has no refresh delay (no exception) ». Leur utilisation n'est pas obligatoire pour vérifier la conformité, mais ce sont des méthodes de test définies et approuvées.

Le cas du délai 0 dans meta http-equiv refresh

La deuxième vérification de la procédure F41 isole les valeurs inférieures à 1, donc le délai 0, et les valeurs supérieures à 72 000 secondes. Ces 72 000 secondes correspondent à 20 heures, la durée retenue par l'exception des 20 heures du critère 2.2.1. Cette vérification fait partie des conditions examinées pour les critères 2.2.1 et 2.2.4.

Attention toutefois : elle ne fait pas partie de la condition du critère 3.2.5, qui ne repose que sur les vérifications 1 et 4. La valeur du délai ne suffit donc pas, à elle seule, à trancher la question du changement à la demande. Si l'utilisateur dispose d'un moyen de désactiver, de prolonger ou d'ajuster le rafraîchissement, la réponse à la vérification 4 est alors positive.

Précision importante : F41 porte sur le rechargement de la page. Pour la redirection par meta avec une limite de temps, le W3C a documenté un échec distinct, F40, que cet article ne détaille pas. Si votre objectif est simplement d'envoyer l'utilisateur vers une nouvelle adresse, notre conseil est de passer par une redirection serveur non minutée, que la documentation du critère 2.2.1 déclare non concernée.

Que faire à la place : redirection serveur et rafraîchissement à la demande

Pour une redirection, la documentation du critère 2.2.1 est explicite : les redirections serveur non minutées, par exemple avec des codes de réponse 3xx, ne sont pas concernées, car elles fonctionnent instantanément et n'imposent aucune limite de temps. Une nuance importante : le côté serveur n'est pas une immunité. L'échec F58 vise justement les techniques serveur qui redirigent automatiquement une page après un délai, et l'échec F40 vise la redirection par meta avec une limite de temps.

Pour un contenu qui doit rester à jour, le W3C conseille de laisser l'utilisateur choisir quand obtenir les dernières informations. Notre conseil : remplacez le rechargement automatique par une action de l'utilisateur, comme un bouton. Si une limite de temps reste nécessaire, les techniques suffisantes du W3C pour le critère 2.2.1 sont classées par situation :

• Limite de temps gérée par un script (situation B) : G198, offrir un moyen de désactiver la limite ; G180, permettre de la régler à dix fois la valeur par défaut ; ou SCR16 combinée à SCR1, avertir que la limite va expirer et permettre de prolonger le délai par défaut.
• Limites de temps de session (situation A) : G133, une case à cocher sur la première page d'un formulaire en plusieurs étapes pour demander une session plus longue ou sans limite ; ou G198.
• Limites de temps de lecture (situation C) : G4, permettre de mettre en pause et de reprendre le contenu ; G198 ; SCR33, un défilement par script avec un mécanisme de pause ; SCR36, offrir un mécanisme qui permet aux utilisateurs d'afficher le texte mobile, défilant ou mis à jour automatiquement dans une fenêtre ou une zone statique.

<!-- À la place : pas de rechargement automatique, l'utilisateur décide -->
<head>
  <title>Tableau de bord</title>
</head>
<body>
  <!-- Le script qui charge les nouvelles données reste à brancher -->
  <button type="button" id="actualiser">Charger les dernières informations</button>
</body>

Qui est gêné par un rechargement non maîtrisé

La documentation du critère 2.2.1 détaille les publics qui peuvent avoir besoin de plus de temps. Ce sont les visiteurs à garder en tête avant d'imposer un rafraîchissement minuté :

• les personnes ayant un handicap physique, qui ont souvent besoin de plus de temps pour réagir, saisir du texte et terminer une action ;
• les personnes malvoyantes, qui ont besoin de plus de temps pour repérer les éléments à l'écran et lire ;
• les personnes aveugles utilisant un lecteur d'écran, qui peuvent avoir besoin de plus de temps pour comprendre la mise en page, trouver une information et utiliser les commandes ;
• les personnes ayant des limitations cognitives ou langagières, qui ont besoin de plus de temps pour lire et comprendre ;
• les personnes sourdes qui communiquent en langue des signes, qui peuvent avoir besoin de plus de temps pour lire un texte écrit, parfois leur seconde langue.

Questions fréquentes

À lire aussi sur Conformly

• Corriger un meta refresh en HTML
• Fiche du critère RGAA 13.1
• Tous nos guides de correction

Sources

Article appuyé sur les sources officielles citées en fin de page.

• W3C — Échec F41
• W3C — Comprendre 2.2.1 Réglage du délai