WCAG 2.2.1 : Minuterie réglable

Ce que signifie cette règle

WCAG 2.2.1 Ajustement du délai est un critère de succès de niveau A relevant du Principe 2 : Utilisable. Il stipule que pour chaque limite de temps définie par le contenu, au moins une des conditions suivantes doit être vraie : l’utilisateur peut désactiver la limite de temps avant d’y être confronté ; l’utilisateur peut ajuster la limite de temps sur une large plage (au moins dix fois la valeur par défaut) ; ou l’utilisateur peut prolonger la limite de temps par une action simple — comme appuyer sur une touche ou cliquer sur un bouton — avant l’expiration du délai, et est averti au moins 20 secondes à l’avance, avec la possibilité de prolonger au moins dix fois.

En pratique, ce critère s’applique à toute interface web qui impose une expiration de session, un carrousel qui avance automatiquement avec des diapositives temporisées, un formulaire qui se vide ou se soumet automatiquement, un compte à rebours sur une page de paiement, un lecteur multimédia avec des sous-titres temporisés qui ne peuvent pas être mis en pause, ou tout autre mécanisme qui limite le temps dont dispose un utilisateur pour accomplir une tâche. Si votre page ou application définit un minuteur qui, une fois expiré, supprime du contenu, déconnecte l’utilisateur ou le fait passer à un nouvel état sans son consentement, vous devez offrir un moyen d’ajuster ou de prolonger cette limite.

Le critère définit également trois exceptions importantes qui peuvent permettre de conserver une limite de temps sans les mécanismes d’ajustement décrits ci-dessus. Premièrement, l’exception en temps réel : si la limite de temps fait partie intégrante d’un événement en temps réel (comme une vente aux enchères en direct ou un examen en ligne synchrone), ajuster le temps invaliderait l’activité elle-même, et aucune alternative n’est réalisable. Deuxièmement, l’exception essentielle : si la limite de temps est essentielle et que la prolonger invaliderait l’activité — par exemple, un test de compétences chronométré où la mesure de la vitesse de réponse est l’objectif. Troisièmement, l’exception des 20 heures : si la limite de temps est supérieure à 20 heures, la charge pour les utilisateurs est considérée comme minimale et des contrôles d’ajustement ne sont pas requis.

Un succès se produit lorsqu’une interaction limitée dans le temps fournit un mécanisme clair — idéalement présenté avant que la limite ne soit atteinte — qui permet à l’utilisateur de désactiver, prolonger ou ajuster la contrainte de temps. Un échec se produit lorsque le contenu expire automatiquement, redirige, déconnecte l’utilisateur ou avance sans offrir l’une des trois options d’ajustement ci-dessus, et qu’aucune des trois exceptions ne s’applique.

Pourquoi c’est important

Les limites de temps affectent de manière disproportionnée les personnes handicapées. Les utilisateurs qui s’appuient sur des lecteurs d’écran naviguent souvent plus lentement que les utilisateurs voyants, car ils écoutent le contenu de manière linéaire et doivent explorer les interfaces inconnues de façon séquentielle. Les utilisateurs ayant des déficiences motrices — y compris ceux qui utilisent des dispositifs d’accès par contacteur, des logiciels de suivi oculaire, des baguettes buccales ou des logiciels de commande vocale — peuvent mettre beaucoup plus de temps à remplir un champ de formulaire, confirmer un achat ou passer à l’étape suivante. Les utilisateurs ayant des déficiences cognitives ou d’apprentissage, y compris la dyslexie, des troubles de l’attention ou des troubles de la mémoire, peuvent avoir besoin de temps supplémentaire pour lire, comprendre et répondre aux instructions. Les personnes âgées ont également souvent besoin de plus de temps pour les mêmes tâches, et elles représentent un segment en forte croissance de la population mondiale d’internautes.

Considérez un scénario concret du monde réel : une personne atteinte de paralysie cérébrale effectue une réservation de vol sur le site web d’une compagnie aérienne turque. La session de paiement expire automatiquement après cinq minutes d’inactivité. L’utilisateur, qui tape lentement avec un dispositif à pointeur de tête, a saisi son nom, son numéro de passeport et ses informations de paiement — puis la page se recharge, effaçant toutes les données et le renvoyant à la page d’accueil. Non seulement ses efforts ont été perdus, mais sa confiance dans le site est ébranlée, et il peut être incapable de finaliser l’achat. Il s’agit d’un obstacle direct à une participation égale au commerce numérique.

L’impact dépasse les utilisateurs individuels. Selon l’Organisation mondiale de la Santé, environ 1,3 milliard de personnes dans le monde vivent avec une forme de handicap significatif. Rien qu’en Turquie, les statistiques officielles de TÜİK indiquent que plus de 8,5 millions de personnes ont un handicap qui affecte les activités quotidiennes. Les interfaces limitées dans le temps excluent une part mesurable de la base d’utilisateurs potentiels de toute application web.

Au-delà de l’accessibilité, supprimer les limites de temps arbitraires ou les rendre ajustables profite également aux utilisateurs dans des environnements à faible bande passante, aux utilisateurs ayant une déficience motrice temporaire (comme un bras cassé), et aux utilisateurs qui sont simplement interrompus pendant une tâche. Les améliorations d’ergonomie sont larges et peuvent réduire les taux d’abandon de formulaires, augmenter les taux de conversion sur les sites de commerce électronique et réduire le volume des demandes au support client.

Règles axe-core associées

WCAG 2.2.1 nécessite des tests manuels. Les outils automatisés — y compris axe-core, Lighthouse et des moteurs similaires — ne peuvent pas détecter de manière fiable les violations liées au temps, car les limites de temps sont souvent implémentées dans la logique de session côté serveur, dans du JavaScript qui s’exécute de manière asynchrone ou dans des intégrations tierces. L’outil n’a aucun moyen d’observer qu’une page expirera dans cinq minutes, ou qu’un carrousel avancera sans intervention de l’utilisateur, simplement en inspectant le DOM ou en exécutant une analyse statique. Les considérations suivantes expliquent ce que les testeurs doivent évaluer manuellement.

• Expirations de session (manuel) : Les testeurs doivent attendre ou simuler une expiration de session pour déterminer si la page présente un avertissement préalable, offre une option de prolongation et fournit au moins 20 secondes à l’utilisateur pour répondre. Aucune règle automatisée ne peut déterminer la durée de la session ou si une boîte de dialogue d’avertissement apparaît à temps sans attendre réellement la fin du délai.
• Carrousels et curseurs à avance automatique (manuel) : Les testeurs doivent observer si les carrousels avancent automatiquement et, le cas échéant, si un contrôle de pause ou d’arrêt est présent et accessible au clavier. Axe-core peut détecter certains attributs ARIA manquants sur les composants de carrousel, mais il ne peut pas déterminer si l’avance temporisée elle-même est ajustable.
• Formulaires qui se soumettent ou se vident automatiquement (manuel) : Si un formulaire se soumet ou efface son contenu après une période d’inactivité, un testeur doit identifier ce comportement par l’observation ou la revue de code. Le DOM seul ne révèle pas ce comportement à un analyseur automatisé.
• Compte à rebours dans les parcours transactionnels (manuel) : Les pages de paiement, les parcours de réservation de billets et les environnements d’examen incluent fréquemment des compteurs à rebours. Le fait que ces minuteurs soient essentiels (et donc exemptés) ou qu’ils nécessitent un mécanisme de prolongation est une question de jugement qui exige un examen humain à la fois de l’implémentation et du contexte métier.

Comment tester

1. Base de référence par analyse automatisée : Exécutez axe DevTools ou Lighthouse sur la page pour identifier toute violation connue liée aux éléments ARIA ou interactifs qui pourrait aggraver les problèmes de temps. Notez que ces outils ne signaleront pas la limite de temps elle-même, mais ils aident à établir une base de référence des autres problèmes d’accessibilité. Dans Chrome DevTools, ouvrez le panneau Lighthouse, sélectionnez Accessibility et lancez l’audit. Dans axe DevTools, activez l’extension de navigateur, cliquez sur Analyze et examinez les résultats — aucune règle spécifique au temps n’apparaîtra, ce qui confirme que des tests manuels sont nécessaires.
2. Identifier toutes les limites de temps : Examinez le code source JavaScript de la page, les requêtes réseau et la configuration de session côté serveur pour identifier chaque limite de temps. Les emplacements courants incluent les appels setTimeout et setInterval en JavaScript, les paramètres d’expiration de session dans les frameworks backend, les valeurs d’expiration des cookies et les configurations de widgets tiers tels que les processeurs de paiement ou les widgets de chat.
3. Tester l’avertissement d’expiration de session avec NVDA + Firefox : Ouvrez le site dans Firefox avec NVDA en cours d’exécution. Naviguez dans un formulaire multi-étapes ou une section authentifiée. Attendez la boîte de dialogue d’avertissement de session (ou l’expiration elle-même si aucun avertissement n’apparaît). Vérifiez que NVDA annonce automatiquement l’avertissement — idéalement via une région dynamique (live region) — et que l’utilisateur peut prolonger la session en appuyant sur Entrée ou Espace sur un bouton focalisé sans perdre les données du formulaire.
4. Tester l’avertissement d’expiration de session avec VoiceOver + Safari (macOS/iOS) : Répétez le test ci-dessus sur Safari avec VoiceOver activé. Utilisez le rotor pour naviguer entre les éléments interactifs et confirmez que l’avertissement d’expiration est annoncé et que le contrôle de prolongation est accessible dans la fenêtre de 20 secondes.
5. Tester l’avertissement d’expiration de session avec JAWS + Chrome : Répétez avec JAWS sur Chrome. Confirmez que le focus est déplacé vers la boîte de dialogue d’avertissement, que JAWS lit le temps restant et l’option de prolongation, et que l’activation du bouton de prolongation maintient la session active sans nécessiter un rechargement de page.
6. Tester uniquement au clavier (sans lecteur d’écran) : Désactivez votre souris et naviguez uniquement avec Tab, Maj+Tab, Entrée et Espace. Confirmez que toute boîte de dialogue d’avertissement est accessible au clavier, que le bouton de prolongation est focalisable et que le focus est renvoyé au bon endroit dans le formulaire après la prolongation de la session.
7. Tester le minutage des carrousels et des médias : Identifiez tout carrousel à avance automatique. Naviguez jusqu’au carrousel avec Tab. Vérifiez qu’un bouton de pause ou d’arrêt est présent et accessible sans souris. Activez-le et confirmez que l’avance s’arrête. Si le carrousel reprend après une interaction de l’utilisateur, confirmez qu’il ne reprend pas automatiquement.
8. Vérifier l’applicabilité des exceptions : Pour chaque limite de temps trouvée, déterminez si l’exception en temps réel, l’exception essentielle ou l’exception des 20 heures s’applique. Documentez votre raisonnement. Si aucune des exceptions ne s’applique et qu’aucun mécanisme d’ajustement n’existe, consignez cela comme un échec de WCAG 2.2.1.

Comment corriger

Expiration de session sans avertissement — Incorrect

<!-- Session expires silently after 5 minutes; page reloads with no warning -->
<script>
  setTimeout(function() {
    window.location.href = '/session-expired';
  }, 300000);
</script>

Expiration de session avec avertissement et prolongation — Correct

<!-- Warn user 60 seconds before expiry; offer extension; announce via live region -->
<div
  id='session-warning'
  role='alertdialog'
  aria-modal='true'
  aria-labelledby='warning-title'
  aria-describedby='warning-desc'
  hidden
>
  <h2 id='warning-title'>Your session is about to expire</h2>
  <p id='warning-desc'>
    Your session will expire in <span id='countdown'>60</span> seconds.
    Select "Stay logged in" to continue your session.
  </p>
  <button id='extend-btn' type='button'>Stay logged in</button>
  <button id='logout-btn' type='button'>Log out now</button>
</div>

<script>
  var SESSION_DURATION = 300000; // 5 minutes
  var WARNING_BEFORE   = 60000;  // warn 60 seconds before
  var sessionTimer, warningTimer, countdownInterval;

  function startSessionTimer() {
    warningTimer = setTimeout(showWarning, SESSION_DURATION - WARNING_BEFORE);
    sessionTimer = setTimeout(expireSession, SESSION_DURATION);
  }

  function showWarning() {
    var dialog = document.getElementById('session-warning');
    dialog.hidden = false;
    document.getElementById('extend-btn').focus(); // move focus to dialog
    var seconds = 60;
    countdownInterval = setInterval(function() {
      seconds--;
      document.getElementById('countdown').textContent = seconds;
      if (seconds <= 0) clearInterval(countdownInterval);
    }, 1000);
  }

  function extendSession() {
    clearTimeout(sessionTimer);
    clearTimeout(warningTimer);
    clearInterval(countdownInterval);
    document.getElementById('session-warning').hidden = true;
    startSessionTimer();
    // Return focus to last active element
  }

  function expireSession() {
    window.location.href = '/session-expired';
  }

  document.getElementById('extend-btn').addEventListener('click', extendSession);
  document.getElementById('logout-btn').addEventListener('click', expireSession);
  startSessionTimer();
</script>

Carrousel à avance automatique sans contrôles — Incorrect

<!-- Slides advance every 4 seconds; no pause control; no keyboard access -->
<div class='carousel'>
  <div class='slide active'>Slide 1 content</div>
  <div class='slide'>Slide 2 content</div>
  <div class='slide'>Slide 3 content</div>
</div>

Carrousel à avance automatique avec contrôle de pause — Correct

<!-- Pause button stops auto-advance; button label updates to reflect state -->
<section aria-roledescription='carousel' aria-label='Featured announcements'>
  <div aria-live='off' aria-atomic='true'>
    <div class='slide active' role='group' aria-roledescription='slide' aria-label='Slide 1 of 3'>
      Slide 1 content
    </div>
    <div class='slide' role='group' aria-roledescription='slide' aria-label='Slide 2 of 3'>
      Slide 2 content
    </div>
    <div class='slide' role='group' aria-roledescription='slide' aria-label='Slide 3 of 3'>
      Slide 3 content
    </div>
  </div>
  <button id='carousel-pause' type='button' aria-pressed='false'>
    Pause slideshow
  </button>
</section>

<script>
  var paused = false;
  var btn = document.getElementById('carousel-pause');
  btn.addEventListener('click', function() {
    paused = !paused;
    btn.setAttribute('aria-pressed', paused.toString());
    btn.textContent = paused ? 'Play slideshow' : 'Pause slideshow';
    // toggle the carousel's auto-advance logic accordingly
  });
</script>

Compte à rebours de paiement sans prolongation — Incorrect

<!-- 10-minute checkout lock; no extension offered; not an essential exception -->
<p>Your items are reserved for: <span id='timer'>10:00</span></p>
<!-- Timer expires, cart is cleared silently -->

Compte à rebours de paiement avec option de prolongation — Correct

<!-- Warn before expiry and offer a one-click extension -->
<p>
  Your items are reserved for:
  <span id='timer' aria-live='polite' aria-atomic='true'>10:00</span>
</p>
<div id='extend-notice' hidden role='alert'>
  <p>Your reservation expires in 2 minutes.</p>
  <button type='button' id='extend-checkout'>Give me more time</button>
</div>
<!--
  When timer reaches 2:00, reveal #extend-notice.
  Clicking the button resets the reservation timer via an API call.
  aria-live='alert' ensures screen readers announce the warning immediately.
-->

Erreurs courantes

• Afficher un avertissement d’expiration sans gestion du focus clavier : La boîte de dialogue d’avertissement apparaît visuellement mais le focus n’est jamais déplacé vers elle, de sorte que les utilisateurs au clavier uniquement et les utilisateurs de lecteurs d’écran ne découvrent jamais qu’ils peuvent prolonger la session avant son expiration.
• Fournir moins de 20 secondes pour répondre à un avertissement d’expiration : Afficher une alerte « Session en cours d’expiration » seulement 10 secondes avant la déconnexion ne satisfait pas le critère, qui exige qu’au moins 20 secondes soient disponibles pour l’action de prolongation.
• Utiliser role='alert' sur une boîte de dialogue d’expiration qui nécessite une interaction : Le rôle alert est destiné aux annonces en lecture seule ; une boîte de dialogue nécessitant une action de l’utilisateur doit utiliser role='alertdialog' avec aria-modal='true' et aria-labelledby afin que les lecteurs d’écran la traitent comme une fenêtre modale nécessitant une réponse.
• Invoquer l’exception essentielle pour un minuteur standard de panier e-commerce : Réserver des articles dans un panier pendant 10 minutes est une commodité commerciale, pas une activité véritablement essentielle où la mesure de la vitesse est l’objectif. Appliquer ici l’exception essentielle est incorrect ; un mécanisme de prolongation est requis.
• Faire avancer automatiquement un carrousel sans bouton de pause visible et accessible au clavier : Ajouter un bouton de pause qui n’est visible qu’au survol, ou qui est absent de l’ordre de tabulation, ne satisfait pas le critère. Le contrôle doit être accessible sans dispositif de pointage.
• Réinitialiser le compteur d’inactivité sur tout mouvement de souris mais pas sur les événements clavier : Un JavaScript qui prolonge le délai d’inactivité sur les événements mousemove mais ignore les événements keydown ou focus fera expirer silencieusement les sessions des utilisateurs au clavier uniquement qui travaillent activement sur la page.
• Prolonger la session via un rechargement complet de la page : Lorsqu’un utilisateur clique sur « Stay logged in », recharger la page efface toutes les données qu’il avait saisies dans les formulaires. La prolongation doit se faire via un appel d’API ou un rafraîchissement de cookie en arrière-plan, en préservant l’état du DOM.
• Utiliser des valeurs setTimeout qui ne sont pas configurables ou exposées à l’utilisateur : Coder en dur une durée de session de cinq minutes sans contrôle d’interface permettant à l’utilisateur de choisir une durée plus longue viole le critère, à moins qu’un des trois mécanismes d’ajustement (désactiver, ajuster ou prolonger) ne soit disponible.
• Ne pas tester le flux d’expiration avec de véritables technologies d’assistance avant le lancement : Les développeurs qui testent uniquement avec une souris peuvent ne pas remarquer que la boîte de dialogue d’avertissement est inaccessible aux utilisateurs de lecteurs d’écran, car les tests en vision directe ne révèlent pas les problèmes de gestion du focus.
• Supposer que les widgets tiers intégrés sont automatiquement conformes : Les processeurs de paiement, les widgets de chat en direct et les moteurs de réservation intégrés via des iframes ou des scripts imposent souvent leurs propres limites de temps. La responsabilité de la conformité WCAG de la page entière — y compris le contenu intégré que vous contrôlez — incombe au propriétaire de la page.

Lien avec la réglementation turque en matière d’accessibilité

La Circulaire présidentielle 2025/10 de la Turquie, publiée au Journal officiel n° 32933 le 21 juin 2025, établit des exigences obligatoires en matière d’accessibilité web alignées sur WCAG 2.2 niveau AA pour un large éventail d’entités publiques et privées exploitant des services numériques en Turquie. WCAG 2.2.1 Ajustement du délai est un critère de niveau A, ce qui signifie qu’il se situe au niveau fondamental de la conformité — il fait partie des premières exigences que les entités concernées doivent satisfaire.

En vertu de la circulaire, les institutions et organismes publics — y compris les ministères, les municipalités, les universités et les entreprises publiques — sont tenus d’atteindre une conformité totale dans l’année suivant la date de publication de la circulaire. Les entités du secteur privé couvertes par la réglementation disposent d’un délai de deux ans pour se conformer. Le champ d’application du secteur privé est explicitement large : il couvre les plateformes de commerce électronique, les banques et institutions financières, les hôpitaux privés et prestataires de services de santé, les entreprises de télécommunications comptant 200,000 abonnés ou plus, les agences de voyage, les entreprises privées de transport de passagers et les écoles privées opérant sous une autorisation du Ministry of National Education (MoNE).

Pour les organisations de ces catégories, un manquement à WCAG 2.2.1 n’est pas simplement un défaut de bonne pratique — c’est une non-conformité juridique susceptible d’attirer l’attention des autorités de régulation, des plaintes via les canaux officiels et un préjudice réputationnel. Considérez les parcours métier spécifiques les plus susceptibles de déclencher cette violation : un paiement e-commerce avec une réservation de panier limitée dans le temps, une session de banque en ligne qui expire silencieusement pendant qu’un client remplit un formulaire de paiement, un système de prise de rendez-vous hospitaliers qui expire avant qu’un utilisateur ayant une déficience motrice puisse terminer son inscription, ou un portail en libre-service d’un opérateur télécom qui déconnecte automatiquement les utilisateurs d’un parcours de gestion de contrat. Chacun de ces cas est un scénario d’échec plausible au sein d’un type d’entité explicitement nommé dans la circulaire.

Les organisations devraient considérer la conformité à WCAG 2.2.1 non pas comme une simple case technique à cocher, mais comme une exigence de conception qui doit être traitée au niveau de l’architecture — dans les politiques de gestion de session, les exigences d’achat de widgets tiers et les standards de composants d’interface — plutôt que d’être ajoutée a posteriori. Les programmes d’audit devraient inclure des tests manuels de toutes les interactions temporisées, et pas seulement des analyses automatisées, précisément parce que les outils automatisés ne peuvent pas détecter cette catégorie de violations sans observation humaine.