WCAG 2.2.3 : Absence de contrainte temporelle

Ce que signifie cette règle

WCAG 2.2.3 — No Timing se situe au niveau de conformité AAA dans le cadre de la Règle 2.2 : Temps suffisant. Son exigence est directe : le temps ne doit pas être une partie essentielle d’un événement ou d’une activité présentée à l’utilisateur. En d’autres termes, si votre contenu ou vos fonctionnalités impliquent une limite de temps, une échéance ou une interaction sensible au temps, cette dépendance au temps doit soit pouvoir être supprimée, soit être complètement sans importance pour la tâche en cours — sauf si l’une des exceptions limitées s’applique.

Ce critère va plus loin que le critère de niveau A 2.2.1 (Timing Adjustable) et le critère de niveau AA 2.2.2 (Pause, Stop, Hide). Alors que ces critères précédents autorisent des limites de temps ajustables ou pouvant être mises en pause, 2.2.3 exige que le temps n’existe tout simplement pas comme contrainte significative. Un utilisateur qui met dix secondes ou dix minutes à remplir un formulaire, à naviguer dans un menu ou à terminer un flux de travail doit arriver au même résultat qu’un utilisateur qui termine instantanément.

Ce qui est considéré comme conforme : Contenu où aucune limite de temps n’existe, ou où toute limite de temps présente est purement cosmétique et n’a aucune incidence sur le résultat (par exemple, une animation en boucle qui n’empêche pas l’interaction). Le contenu qui reste entièrement fonctionnel quel que soit le temps que l’utilisateur met à l’utiliser satisfait à ce critère.

Ce qui est considéré comme non conforme : Des expirations de session qui déconnectent les utilisateurs après une période d’inactivité ; des quiz ou évaluations chronométrés où le score ou la validation dépend du fait de terminer dans une fenêtre donnée ; des minuteries d’expiration de panier qui suppriment les articles ; des interfaces d’enchères avec compte à rebours qui clôturent les offres ; des champs de mot de passe à usage unique (OTP) qui expirent ; des CAPTCHA avec limite de temps ; et tout élément interactif qui devient indisponible ou se soumet automatiquement en fonction du temps écoulé.

Exceptions officielles définies par les WCAG : Le critère exempte explicitement deux catégories. Premièrement, les exceptions en temps réel — événements où le temps est absolument inhérent à l’activité, comme une enchère en direct, une diffusion en direct ou un jeu multijoueur en temps réel. Deuxièmement, les exceptions essentielles — situations où supprimer la limite de temps modifierait fondamentalement l’activité. Par exemple, un test de dactylographie de vitesse mesure intrinsèquement la rapidité, donc le temps est essentiel. Cependant, les développeurs et les responsables produit doivent être rigoureux : la commodité, l’héritage technique ou les préférences métier ne qualifient pas comme « essentiel ». Le critère est de savoir si l’activité perdrait son sens ou son objectif fondamental sans la contrainte de temps.

Il est important de noter que les médias synchronisés — comme une vidéo préenregistrée avec sous-titres — sont également exclus, car le temps dans la lecture de médias est contrôlé par le lecteur multimédia de l’utilisateur et n’impose pas de contrainte sur la capacité de l’utilisateur à interagir avec le reste de la page.

Pourquoi c’est important

Les limites de temps sur le web nuisent de manière disproportionnée aux utilisateurs présentant un large éventail de handicaps. L’impact n’est pas abstrait — pour de nombreux utilisateurs, une interface chronométrée est de fait inaccessible.

Les utilisateurs avec des troubles moteurs — y compris ceux qui utilisent des dispositifs d’accès par contacteurs, des baguettes buccales, des logiciels de suivi oculaire ou d’autres méthodes d’entrée alternatives — fonctionnent à un rythme fondamentalement différent de celui des utilisateurs souris-clavier. Remplir un formulaire en plusieurs étapes ou naviguer dans un menu déroulant peut prendre plusieurs fois plus de temps. Une expiration de session ou un panier qui expire automatiquement peut effacer en un instant des minutes de travail attentif et laborieux.

Les utilisateurs avec des handicaps cognitifs, y compris la dyslexie, le TDAH, les troubles du traitement de l’information et les lésions cérébrales acquises, peuvent avoir besoin de beaucoup plus de temps pour lire les instructions, comprendre les options ou rédiger des réponses. Des recherches compilées par la Web Accessibility Initiative estiment que les handicaps cognitifs et d’apprentissage affectent sous une forme ou une autre environ 15–20 % de la population mondiale. Pour ces utilisateurs, un compte à rebours n’est pas seulement stressant — il nuit activement au traitement cognitif nécessaire pour accomplir la tâche.

Les utilisateurs de lecteurs d’écran qui sont aveugles ou malvoyants naviguent dans le contenu de manière linéaire et doivent écouter ou parcourir les éléments d’interface séquentiellement. Comprendre la structure et les options d’une page complexe prend plus de temps qu’un utilisateur voyant qui survole visuellement. Un flux de paiement chronométré qui expire alors qu’un utilisateur aveugle examine soigneusement le récapitulatif de sa commande constitue un obstacle direct au commerce.

Les utilisateurs souffrant de troubles anxieux peuvent constater que la simple présence d’un compte à rebours crée une charge cognitive et émotionnelle suffisante pour empêcher l’achèvement de la tâche, même s’ils disposent techniquement de suffisamment de temps. Supprimer le temps comme facteur supprime entièrement cette barrière.

Un scénario concret du monde réel : Considérons un portail bancaire en ligne qui utilise une expiration d’inactivité de cinq minutes combinée à un OTP qui expire en soixante secondes. Un utilisateur atteint de la maladie de Parkinson qui a besoin de technologies d’assistance pour saisir du texte, ou une personne âgée peu habituée à changer rapidement d’application, peut trouver physiquement impossible de recevoir le SMS, de changer d’application, de lire le code, de revenir et de le saisir dans le délai imparti. Ils sont verrouillés hors de leur propre compte — non pas par nécessité de sécurité, mais par une contrainte de temps arbitraire. Concevoir l’OTP pour qu’il reste valide plus longtemps (ou supprimer l’expiration stricte au profit d’un mécanisme de renvoi) résout le problème sans compromettre la sécurité.

Au-delà de l’accessibilité, supprimer les contraintes de temps inutiles améliore l’ergonomie générale et réduit les taux d’abandon. Un processus de paiement e-commerce qui n’expire pas en cours de route conserve davantage de clients, augmente la conversion et réduit la charge du support — ce qui en fait un changement positif pour l’entreprise autant qu’un impératif éthique.

Règles Axe-core associées

WCAG 2.2.3 nécessite des tests manuels. Aucune règle axe-core automatisée ne correspond directement à ce critère, et il est important de comprendre cette réalité architecturale.

• Tests manuels requis — Durée des sessions et des interactions : Les outils automatisés ne peuvent pas détecter si une application web impose une limite de temps, car la logique de temporisation est implémentée dans la gestion de session côté serveur, les minuteries JavaScript ou les réponses d’API back-end — aucun de ces éléments n’étant visible dans une analyse statique du DOM. Un outil comme axe-core inspecte le HTML rendu et l’arbre d’accessibilité ; il ne peut pas observer qu’une requête fetch renverra un 401 après cinq minutes d’inactivité, ou qu’un setTimeout JavaScript redirigera l’utilisateur vers une page de déconnexion. Seul un testeur humain qui interagit lentement avec l’application et observe ce qui se passe peut déterminer si des contraintes de temps existent et si elles affectent l’achèvement des tâches.
• Tests manuels requis — Expiration des OTP et CAPTCHA : Les mots de passe à usage unique et les défis de vérification limités dans le temps apparaissent dans le DOM comme des champs de saisie ordinaires. Le compte à rebours, s’il est visible, peut être un simple nœud de texte ou un élément animé en CSS. Axe ne peut pas déduire que saisir une valeur dans ce champ après quatre-vingt-dix secondes entraînera un état d’erreur. Un testeur doit délibérément attendre au-delà de la fenêtre d’expiration et tenter de soumettre pour confirmer si une contrainte de temps est appliquée.
• Tests manuels requis — Formulaires à soumission ou progression automatiques : Certaines interfaces passent automatiquement à l’étape suivante ou soumettent un formulaire après une période d’inactivité ou après une durée définie (par exemple, une enquête qui passe à la question suivante après trente secondes). Axe-core ne signalera pas cela car la structure du DOM semble valide ; le comportement problématique ne se manifeste que lors d’une interaction réelle dans le temps.
• Tests manuels requis — Expiration dans le commerce et les réservations : Les minuteries de réservation de panier, les blocages de billets et les verrous de créneaux de rendez-vous sont implémentés via la logique serveur et reflétés dans l’interface uniquement sous forme de compte à rebours. Les outils automatisés voient un nombre qui se met à jour à l’écran mais ne peuvent pas déterminer s’il provoque une perte de données ou un refus d’accès lorsqu’il atteint zéro.

Comment tester

1. Analyse automatisée de base : Exécutez axe DevTools ou Lighthouse sur la page pour identifier toute violation de temporisation de niveau inférieur (comme celles couvertes par 2.2.1 ou 2.2.2) susceptible de vous orienter vers des zones nécessitant une inspection manuelle plus approfondie. Bien qu’aucune règle axe ne teste directement 2.2.3, les résultats concernant les avertissements de limite de temps ou l’actualisation automatique peuvent guider le périmètre de votre audit manuel. Dans Lighthouse, consultez la section « Accessibility » pour repérer d’éventuels indicateurs liés au temps.
2. Recenser toutes les fonctionnalités dépendantes du temps : Avant de tester, dressez systématiquement l’inventaire de toutes les fonctionnalités de l’application susceptibles d’impliquer une temporisation. Cela inclut : la gestion de session et les expirations d’inactivité ; les champs d’OTP et de codes de vérification ; les réservations de panier ou de places ; les quiz, évaluations ou enquêtes chronométrés ; les interfaces d’enchères ou d’offres ; les CAPTCHA ; les mécanismes de sauvegarde automatique avec fenêtres de soumission ; et tout compte à rebours ou indicateur de progression visible.
3. Tester le comportement d’expiration de session : Ouvrez l’application et commencez une tâche en plusieurs étapes (par exemple, remplir un formulaire multi-pages ou finaliser un paiement). N’interagissez plus pendant une période dépassant la fenêtre d’expiration supposée. Essayez ensuite de continuer. Observez si votre progression est préservée, si vous êtes averti et avez la possibilité de prolonger votre session, ou si vous êtes déconnecté ou perdez des données. Pour être conforme, il faut soit qu’aucune expiration n’existe, soit que l’expiration soit purement préventive et que les données soient préservées lors de la ré-authentification, soit que l’utilisateur reçoive un avertissement adéquat et un contrôle suffisant.
4. Tester l’expiration des OTP et des codes : Déclenchez un flux d’OTP ou de code de vérification. Attendez au-delà du temps d’expiration indiqué du code (ou plus longtemps si aucun temps n’est affiché). Essayez de saisir le code. Si le système le rejette uniquement en raison du temps, c’est un échec de 2.2.3. Remarque : un mécanisme de « renvoi » à lui seul ne corrige pas 2.2.3 — l’expiration du code d’origine impose toujours une contrainte de temps.
5. Tests avec lecteur d’écran (NVDA + Firefox) : En utilisant NVDA avec Firefox, naviguez dans toute interface chronométrée uniquement au clavier et au lecteur d’écran. Notez le temps que chaque étape prend avec la surcharge de navigation liée aux technologies d’assistance. Avancez délibérément à un rythme lent — faites une pause pour écouter toutes les instructions, explorez toutes les options via le curseur virtuel — puis essayez de soumettre ou de continuer. Vérifiez qu’une navigation lente ne déclenche pas d’expiration ou de perte d’état.
6. Tests avec lecteur d’écran (VoiceOver + Safari sur macOS) : Répétez le même test de navigation lente en utilisant VoiceOver sur macOS avec Safari. Portez une attention particulière aux comptes à rebours dynamiques : VoiceOver annonce-t-il le temps restant d’une manière qui crée un sentiment d’urgence, et l’interface échoue-t-elle lorsque le temps est écoulé ?
7. Tests avec lecteur d’écran (JAWS + Chrome) : En utilisant JAWS avec Chrome, testez les mêmes flux. Les utilisateurs de JAWS représentent une part significative des utilisateurs professionnels de lecteurs d’écran ; les problèmes de temporisation qui affectent les utilisateurs de NVDA affecteront généralement tout autant les utilisateurs de JAWS.
8. Vérifier la légitimité des exceptions : Pour toute temporisation que l’équipe de développement considère comme « essentielle » ou « en temps réel », documentez la justification et évaluez si la contrainte de temps est réellement inhérente à l’objectif de l’activité, ou si elle pourrait être assouplie, prolongée ou supprimée sans changer la nature fondamentale de la tâche.

Comment corriger

Expiration de session — Incorrect

<!-- Session expires after 5 minutes of inactivity with no warning.
     User data is lost and they are redirected to login. -->
<script>
  setTimeout(function() {
    window.location.href = '/logout?reason=timeout';
  }, 300000);
</script>

Expiration de session — Correct

<!-- No automatic session expiry on inactivity.
     Server session is maintained as long as the browser tab is open.
     If a timeout is legally required (e.g. banking regulation),
     warn the user well in advance and offer to extend the session
     without time pressure on the extension dialog itself. -->
<div role='dialog' aria-modal='true' aria-labelledby='session-dialog-title' aria-describedby='session-dialog-desc' id='session-warning' hidden>
  <h2 id='session-dialog-title'>Your session is about to expire</h2>
  <p id='session-dialog-desc'>For your security, your session will expire due to inactivity. Would you like to stay signed in?</p>
  <button type='button' id='extend-session'>Stay signed in</button>
  <button type='button' id='end-session'>Sign out now</button>
</div>
<!-- The "Stay signed in" button itself has no expiry —
     the user can take as long as they need to find and activate it. -->

Champ OTP expirant — Incorrect

<!-- OTP expires in 60 seconds. After expiry, form submission
     returns an error and the user must restart the entire flow. -->
<label for='otp'>Enter the code sent to your phone</label>
<input type='text' id='otp' name='otp' autocomplete='one-time-code' inputmode='numeric' maxlength='6'>
<p aria-live='assertive'>Code expires in: <span id='countdown'>60</span> seconds</p>
<button type='submit'>Verify</button>

Champ OTP expirant — Correct

<!-- OTP does not expire within a short user-facing window.
     A longer server-side validity period (e.g. 15-30 minutes) is used.
     A resend option is available but the original code remains valid.
     No countdown timer is shown, removing false urgency. -->
<label for='otp'>Enter the 6-digit code sent to your phone</label>
<input type='text' id='otp' name='otp' autocomplete='one-time-code' inputmode='numeric' maxlength='6'>
<p>The code is valid for 30 minutes. <button type='button' id='resend-otp'>Send a new code</button></p>
<button type='submit'>Verify</button>
<!-- Server invalidates the code after first successful use,
     not after a short time window. -->

Quiz chronométré — Incorrect

<!-- Quiz auto-submits when the 10-minute timer reaches zero,
     regardless of whether the user has finished answering. -->
<div id='quiz-timer' aria-live='polite'>Time remaining: <span id='time-left'>10:00</span></div>
<form id='quiz-form'>
  <!-- quiz questions -->
  <button type='submit'>Submit Quiz</button>
</form>

Quiz chronométré — Correct

<!-- Quiz has no time limit unless timing is the explicit
     subject being assessed (e.g. a certified speed test).
     If an optional time indicator is shown for user reference,
     it does not trigger auto-submission or penalise slow completion. -->
<form id='quiz-form'>
  <!-- quiz questions -->
  <button type='submit'>Submit Quiz</button>
</form>
<!-- If a time reference is genuinely needed, it is informational only:
<p>Most users complete this in about 10 minutes. Take as long as you need.</p> -->

Erreurs courantes

• Supposer que la sécurité de session exige une expiration stricte : De nombreuses équipes mettent en place de courtes expirations d’inactivité en invoquant des exigences de sécurité, mais la plupart des normes de sécurité (y compris PCI-DSS et OWASP) autorisent une extension de session contrôlée par l’utilisateur. Une déconnexion forcée sans avertissement ni possibilité de prolongation est un échec d’accessibilité, pas une nécessité de sécurité.
• Afficher un compte à rebours sans offrir de moyen de l’arrêter ou de le prolonger : Ajouter une région aria-live à un compte à rebours l’aggrave pour les utilisateurs de lecteurs d’écran — elle annonce chaque seconde — sans corriger le problème de temporisation sous-jacent. La solution consiste à supprimer la contrainte, pas à l’annoncer de manière plus accessible.
• Considérer que « renvoyer le code » corrige l’expiration des OTP : Fournir un bouton de renvoi permet aux utilisateurs d’obtenir un nouveau code mais ne résout pas le fait que le code d’origine a expiré en raison du temps. La limite de temps est toujours présente. La correction appropriée consiste à prolonger la fenêtre de validité pour éliminer la pression temporelle.
• Faire avancer automatiquement un carrousel ou les étapes d’un assistant après inactivité : Les formulaires ou assistants en plusieurs étapes qui passent automatiquement à l’étape suivante après un temps défini imposent une contrainte de temps. Les utilisateurs qui lisent les instructions ou réfléchissent à leur réponse sont pénalisés. Les étapes ne doivent avancer que sur action explicite de l’utilisateur.
• Utiliser des minuteries de panier qui suppriment les articles sans les préserver : Les minuteries de réservation en e-commerce (« Votre panier expire dans 15 minutes ») ne respectent pas 2.2.3 lorsque les articles sont définitivement perdus à l’expiration plutôt que simplement libérés de la réservation. Au minimum, les articles devraient être enregistrés dans une liste de souhaits ou la session devrait être restaurable.
• Appliquer l’« exception en temps réel » de manière trop large : Qualifier une interface de « temps réel » pour justifier des contraintes de temps alors qu’elle n’est pas réellement en direct. Une rediffusion d’enchère préenregistrée, une interface d’enchères statique ou un quiz qui ressemble simplement à un jeu télévisé ne relève pas de l’exception en temps réel.
• Ignorer la temporisation dans les réponses d’API back-end : Les équipes corrigent les minuteries front-end mais omettent que l’API elle-même rejette les requêtes effectuées après une certaine fenêtre. L’utilisateur ne voit aucun compte à rebours mais sa soumission échoue silencieusement. La gestion de session côté serveur doit être alignée sur l’expérience front-end.
• Utiliser setTimeout pour la déconnexion automatique sans conserver l’état du formulaire : Lorsqu’une déconnexion automatique est inévitable (par exemple, en raison d’exigences réglementaires), ne pas sauvegarder les données du formulaire de l’utilisateur avant la redirection signifie que tout le travail est perdu. Au minimum, l’état du brouillon doit être enregistré et restauré après ré-authentification.
• Confondre conformité à 2.2.1 et conformité à 2.2.3 : Fournir un contrôle permettant de « désactiver, ajuster ou prolonger » (comme l’exige 2.2.1 niveau A) ne satisfait pas 2.2.3. Le niveau AAA exige que le temps ne soit pas essentiel — pas seulement gérable. Une limite de temps avec une extension généreuse reste une limite de temps.
• Passer sous silence la temporisation dans les composants embarqués tiers : Les widgets de chat intégrés, les prestataires de paiement, les SDK de vérification d’identité et les services de cartographie peuvent introduire leurs propres contraintes de temps. L’origine tierce ne les exempte pas de l’applicabilité des WCAG lorsqu’ils sont intégrés à votre interface.

Lien avec la réglementation d’accessibilité de la Turquie

La Circulaire présidentielle 2025/10 de la Turquie, publiée au Journal officiel n° 32933 le 21 juin 2025, établit un cadre national d’accessibilité web qui se réfère aux WCAG 2.2 comme base technique. La Circulaire impose la conformité à un large éventail d’entités fournissant des services numériques en Turquie.

Les types d’entités concernés incluent les institutions publiques et organismes gouvernementaux, les plateformes d’e-commerce, les banques et services financiers, les hôpitaux et prestataires de soins de santé, les entreprises de télécommunications comptant 200,000 abonnés ou plus, les agences de voyage, les entreprises de transport privé et les écoles privées autorisées par le ministère de l’Éducation nationale (MoNE). Ces organisations doivent respecter les normes d’accessibilité définies dans la Circulaire ou auxquelles elle renvoie lorsqu’elles fournissent des services numériques au public.

WCAG 2.2.3 — No Timing est un critère de niveau AAA, et la Circulaire présidentielle 2025/10, comme la norme européenne EN 301 549 à laquelle elle s’aligne, impose la conformité aux niveaux A et AA comme minimum légal. La conformité au niveau AAA n’est pas une obligation légale directe dans ce cadre. Cependant, atteindre le niveau AAA — et en particulier mettre en œuvre 2.2.3 — est reconnu comme un marqueur de maturité exemplaire en matière d’accessibilité et démontre un engagement réel envers un design inclusif au-delà des seuils légaux minimaux.

Pour certains types d’entités couvertes, en particulier les banques et services financiers opérant sous la supervision de la BDDK, et les plateformes d’e-commerce à fort volume de transactions, les contraintes de temps telles que l’expiration des OTP, la gestion de session et les minuteries de flux de paiement sont des fonctionnalités omniprésentes. Même lorsque 2.2.3 n’est pas légalement requis, ne pas traiter les barrières liées au temps dans ces flux crée un risque réel de discrimination — en particulier à mesure que les mécanismes d’application de l’accessibilité en Turquie se renforcent et que les procédures de plainte se structurent.

Les institutions publiques et les prestataires de soins de santé qui servent des utilisateurs en situation de handicap, des personnes âgées et des utilisateurs ayant une faible littératie numérique ont un argument éthique particulièrement fort pour éliminer entièrement les contraintes de temps. Supprimer les limites de temps des services publics numériques et des portails de santé s’aligne sur les objectifs plus larges d’inclusion de l’e-gouvernement turc et réduit le risque d’exposition réglementaire future à mesure que l’adoption du niveau AAA dans les marchés publics devient plus courante.

Les organisations qui souhaitent positionner leurs produits numériques comme pleinement inclusifs — que ce soit pour un leadership national, un accès aux marchés internationaux ou des avantages en matière de marchés publics dans les contextes de l’Union européenne (où s’appliquent EN 301 549 et l’Acte européen sur l’accessibilité) — devraient considérer la conformité à WCAG 2.2.3 comme un investissement stratégique plutôt qu’une amélioration optionnelle.