Vous l'avez déjà vécu, même sans y voir un problème d'accessibilité. Vous commencez à remplir un formulaire, vous vous éloignez pour un appel, vous revenez, vous cliquez sur envoyer - et la page vous a discrètement déconnecté ou effacé ce que vous aviez saisi. « Votre session a expiré. » Pour la plupart des gens, c'est un petit désagrément, deux minutes perdues. Pour une personne qui lit l'écran une ligne à la fois, qui tape avec un contacteur ou un pointeur à la tête, ou qui doit détourner le regard pour gérer un tremblement ou une tâche cognitive, ce même compte à rebours peut rendre un formulaire, un passage à la caisse ou une page de compte réellement impossibles à terminer. Elles ne sont pas lentes. Votre horloge est simplement plus rapide que la façon dont elles doivent travailler. WCAG a une règle pour exactement cela, c'est l'une des plus anciennes de la norme, et elle se trouve à l'intérieur de la version que l'Ontario applique réellement.
Faits essentiels
- Le critère de succès 2.2.1 Délai modifiable de WCAG (Web Content Accessibility Guidelines) est de niveau A - le palier de conformité le plus fondamental - et fait partie de la norme depuis WCAG 2.0 (W3C).
- Si votre contenu impose un délai, le 2.2.1 exige qu'au moins une de ces conditions soit vraie : l'utilisateur peut le désactiver, l'ajuster sur une plage d'au moins dix fois la valeur par défaut, ou recevoir un avertissement avec au moins 20 secondes pour le prolonger par une action simple, et le prolonger au moins dix fois (W3C).
- La règle comporte trois exceptions étroites : un événement en temps réel (comme une enchère), un délai essentiel à l'activité, ou tout délai supérieur à 20 heures (W3C).
- Le RNAI de l'Ontario (Règlement sur les normes d'accessibilité intégrées, Règl. de l'Ont. 191/11), art. 14, exige des organisations de 50 employés ou plus qu'elles respectent WCAG 2.0 niveau AA sur les sites Web publics, et le niveau AA intègre tous les critères de niveau A (ontario.ca).
- Le prochain RCL (Rapport de conformité en matière d'accessibilité) pour les organisations de 20 employés ou plus est dû le 31 décembre 2026 (ontario.ca).
Qu'exige réellement « Délai modifiable » ?
Moins que ce que les propriétaires craignent, et il s'agit avant tout de redonner le contrôle à l'utilisateur. La règle n'interdit pas les délais. Les sessions peuvent toujours expirer, les déconnexions de sécurité ont toujours du sens, une réservation de siège pour un événement peut toujours s'écouler. Ce que dit le 2.2.1, c'est que lorsque votre contenu impose une horloge à l'utilisateur, vous devez lui offrir l'une de trois issues.
La plus nette est de désactiver le délai avant qu'il ne se manifeste - laisser l'utilisateur le désactiver à l'avance. La deuxième est de lui permettre de l'ajuster dès le départ, à une valeur au moins dix fois plus longue que votre valeur par défaut. La troisième, et celle que la plupart des sites peuvent ajouter le plus vite, est le schéma avertir-et-prolonger : avant que la session ne meure, affichez une invite claire - « Vous serez déconnecté dans une minute. Rester connecté ? » - donnez à la personne au moins 20 secondes pour répondre par une action simple, et laissez-la le faire au moins dix fois. N'importe laquelle des trois satisfait à la règle.
Où les délais cachés nuisent-ils aux vrais utilisateurs ?
Le piège, c'est que ces délais sont habituellement invisibles pour la personne qui a construit le site, parce qu'elle ne les atteint jamais. Vous testez le passage à la caisse en le remplissant en trente secondes. L'utilisateur qui a besoin de la règle le remplit en dix minutes, et votre minuterie d'inactivité s'est déclenchée à la cinquième.
Le schéma apparaît aux endroits les plus importants sur le plan commercial. Un passage à la caisse en plusieurs étapes qui abandonne le panier après quelques minutes d'inactivité. Un long formulaire de demande qui s'efface à l'expiration sans avertissement ni récupération, ce qui est exactement là où cette règle recoupe le fait de rendre le formulaire lui-même accessible. Une session de compte ou bancaire qui se termine en pleine tâche. Même l'écran de connexion peut porter une horloge cachée - un code ou un défi qui expire avant qu'une personne utilisant une technologie d'assistance puisse l'atteindre, ce qui rejoint directement l'authentification accessible. Remarquez que ce sont les mêmes pages à forte valeur, cruciales pour la conversion, que vous voulez le moins voir abandonnées - accessibilité et ventes conclues tirent ici dans le même sens.
Le 2.2.1 relève du principe directeur 2.2 de WCAG, « Délai suffisant », le même que la règle mettre en pause, arrêter, masquer pour la lecture automatique et le contenu en mouvement. Le fil conducteur est simple : c'est l'utilisateur, et non la page, qui devrait décider du temps dont il a besoin.
Quels délais sont exemptés - et lesquels ne le sont pas ?
C'est ici que la règle est plus juste qu'il n'y paraît. Trois exceptions signifient que vous n'êtes pas tenu de rendre chaque horloge modifiable. Un événement en temps réel où le minutage est le sujet même - une enchère en direct, une vente à inventaire limité - est exempté, parce qu'il n'y a aucun moyen honnête de donner plus de temps à un seul enchérisseur. Un délai essentiel, dont la prolongation briserait l'activité, est exempté. Et tout délai supérieur à 20 heures est exempté, selon la logique sensée qu'une fenêtre d'une journée n'est pas l'obstacle qui nous préoccupe.
Ce qui n'est pas exempté, c'est l'expiration ordinaire de session par inactivité - la déconnexion après quinze minutes, la déconnexion automatique « pour votre sécurité » sur un formulaire. La sécurité est une raison légitime d'avoir le délai ; ce n'est pas une raison de sauter l'avertissement et la possibilité de prolonger. Vous pouvez conserver la posture de sécurité et respecter tout de même la règle en avertissant l'utilisateur et en lui permettant de rester connecté d'un clic. Les deux ne sont pas en conflit.
Comment le vérifier, et quel est le risque si on ne le fait pas ?
Vous pouvez faire un contrôle rapide de votre propre site en quelques minutes :
- Repérez chaque page qui peut vous déconnecter ou effacer votre saisie - passage à la caisse, compte, longs formulaires, tout ce qui se trouve derrière une connexion.
- Commencez une tâche, puis attendez. Laissez la page inactive au-delà de la durée de votre session. Avez-vous été averti avant l'expiration ? Pouviez-vous prolonger ou rester connecté par une seule action ? Si elle vous a déconnecté en silence ou effacé le formulaire, c'est le manquement.
- Chronométrez l'avertissement, s'il y en a un. L'invite doit accorder au moins 20 secondes et un moyen simple d'agir - pas un éclair de deux secondes qu'on peut manquer en lisant avec un lecteur d'écran.
Un vérificateur automatisé ne détectera presque jamais cela. Un délai réside dans la logique de serveur et de session, pas dans le balisage statique que lit un robot d'exploration ; il passe donc à travers l'analyse automatisée en paraissant impeccable. C'est un cas d'école de la raison pour laquelle une analyse n'est pas un audit - et pour laquelle une surcouche greffée n'aide pas non plus, puisqu'une surcouche ne peut pas réécrire la logique de session derrière votre passage à la caisse.
Sur les enjeux, le portrait honnête est celui qui s'applique à tout obstacle. En Ontario, la LAPHO (Loi sur l'accessibilité pour les personnes handicapées de l'Ontario) ne prévoit aucun droit d'action privé, donc personne ne vous poursuit directement en vertu de celle-ci ; la voie réelle pour un particulier est une plainte au TDPO (Tribunal des droits de la personne de l'Ontario) en vertu du Code des droits de la personne de l'Ontario, et voici comment une seule plainte se déroule vraiment. Si vous vendez aux États-Unis, un passage à la caisse qui déconnecte les gens est le genre d'obstacle qui apparaît dans les plaintes Web au titre de l'ADA (Americans with Disabilities Act). La réponse durable n'est pas un avis de non-responsabilité - c'est une remédiation documentée : un registre daté de ce que vous avez trouvé et corrigé, ce qu'un RCL honnête devrait refléter d'ici le 31 décembre 2026.
Le côté rassurant : pour la plupart des sites, c'est un petit changement au rendement démesuré. Ajouter une invite « vous êtes sur le point d'être déconnecté - rester connecté ? » est un travail front-end modeste, et il récupère précisément les sessions abandonnées qui vous coûtaient discrètement des formulaires remplis et des ventes.
Vérifiez si vos formulaires et votre passage à la caisse déconnectent les gens, et cherchez d'autres problèmes d'accessibilité - rapport Vayle gratuit, environ 30 secondes : vayle.art. Il détecte les surcouches, révèle les vrais manquements WCAG et vous indique exactement ce qui s'applique légalement à votre organisation en Ontario. Sans engagement.
Vayle est un studio d'ingénierie de l'accessibilité, à distance, au service de l'Ontario. Renseignements généraux, pas un avis juridique.