Réglage du délai :
Comprendre le CS 2.2.1

Objectif de ce critère de succès

L'objectif de ce critère de succès est de garantir, partout où cela est possible, qu'une durée adéquate pour interagir avec le contenu web est accordée aux utilisateurs en situation de handicap. Les personnes ayant des limitations telles que la cécité, la malvoyance, la diminution de la dextérité, et des limitations cognitives, peuvent avoir besoin de plus de temps pour lire du contenu ou exécuter des fonctions comme le remplissage de formulaires en ligne. Si des fonctions Web sont soumises à une durée, il sera difficile pour certains utilisateurs d'exécuter l'action requise avant que la limite de temps n'expire. Ce qui peut leur rendre le service inaccessible. Le fait de concevoir des fonctions qui ne dépendent pas de la durée aidera les personnes en situation de handicap à réussir l'exécution de ces fonctions. Le fait de fournir des options qui permettent de désactiver les limites de temps, de personnaliser l'étendue des durées limites, ou de demander du temps supplémentaire avant l'expiration d'une durée, est une aide pour les utilisateurs qui ont besoin de plus de temps que celui imparti pour accomplir pleinement des tâches. Ces options sont énumérées dans l'ordre le plus pratique pour l'utilisateur. Désactiver les limites de temps est mieux que de personnaliser la durée limite, qui est à son tour mieux que de demander du temps supplémentaire avant que n'expire la durée limite.

Tout processus qui se déroule après une certaine durée, sans avoir été initié par l'utilisateur, ou de manière périodique, est considéré comme une limite de temps. Cela comprend les mises à jour partielles ou complètes du contenu (par exemple, le rafraîchissement d'une page), des modifications dans le contenu, ou l'expiration d'un délai offert à l'utilisateur pour réagir à une demande de saisie.

Cela inclut également du contenu qui avance ou se met à jour à un rythme supérieur à celui auquel l'utilisateur est capable de le lire et/ou le comprendre. En d'autres termes, du contenu animé, en mouvement ou défilant constitue une limite de temps par rapport à la capacité de l'utilisateur à lire du contenu.

Toutefois, dans certains cas, il n'est pas possible de modifier la limite de temps (par exemple pour une enchère ou autre évènement en temps réel), et des exceptions sont alors mentionnées pour ces cas.

Notes concernant les limites de temps côté serveur

• Les redirections serveur à durée limitée font partie des échecs fréquents, comme indiqué ci-après.

• Les redirections côté serveur sans limite de temps (ex. les codes de réponse de type 3xx) sont non applicables car il n'y a pas de limite de temps : elles agissent instantanément.

• Ce critère de succès s'applique uniquement aux limites de temps qui sont définies par le contenu lui-même. Par exemple, si une limite de temps est incluse pour régler des questions de sécurité elle serait considérée comme étant définie par le contenu car elle est conçue pour faire partie de l'expérience de présentation et interaction de ce contenu. Les limites de temps sur le contenu définies de manière externe tel que par l'agent utilisateur ou des facteurs propres à Internet, ne sont pas contrôlables par l'auteur et ne sont pas soumises aux exigences de conformité aux WCAG. Les limites de temps définies par les serveurs Web doivent être contrôlables par l'auteur ou l'organisme et sont traitées par ce critère de succès. (Les critères de succès 2.2.3, 2.2.4 et 2.2.5 peuvent également s'appliquer.

• La base de dix fois la durée par défaut a été choisie d'après une expérience clinique et d'autres recommandations. Par exemple, si un utilisateur a 15 secondes pour répondre et activer un bouton, 150 secondes seront suffisantes pour la plupart des utilisateurs ayant des difficultés pour activer le bouton.

• La base de 20 secondes a également été choisie d'après une expérience clinique et d'autres recommandations. 20 secondes suffisent à la plupart des utilisateurs pour activer n'importe quel bouton, y compris ceux ayant une paralysie spasmodique. Certains n'y arriveront pas, mais certains n'y arriveront pas quelle que soit la durée. Il est nécessaire d'établir une durée raisonnable concernant les demandes de temps supplémentaires dans la mesure où une durée arbitrairement trop longue expose tout utilisateur, y compris ceux en situation de handicap, à des risques de sécurité sur certaines applications. Par exemple, il est fréquent que sur les kiosques ou les terminaux utilisés pour des transactions financières, les utilisateurs quittent sans se déconnecter. Cela les rend vulnérables vis-à-vis de ceux qui se connectent juste après eux. Le fait d'accorder aux personnes une longue période d'inactivité avant de les interroger, puis une longue période avant qu'elles indiquent si elles sont présentes, peut laisser les terminaux ouverts à des abus. S'il n'y a plus d'activité, le système doit demander si l'utilisateur est encore là. Il doit ensuite attendre un signal indiquant que la personne est là « appuyez sur n'importe quelle touche », puis attendre suffisamment pour permettre à presque quiconque de répondre. Pour un signal du type « Appuyez sur n'importe quelle touche », 20 secondes satisferont à ce critère. Si la personne indique qu'elle est toujours là, l'appareil doit replacer l'utilisateur exactement dans les mêmes conditions existant avant la question.

• La base de 20 heures a été choisie comme limite supérieure car elle est plus longue qu'une pleine journée de veille.

Dans les cas où le délai n'est pas une exigence intrinsèque mais où le fait de donner à l'utilisateur le contrôle sur la durée invaliderait les résultats, un tiers peut gérer les limites de temps pour l'utilisateur (en accordant, par exemple, le double du temps pour un test).

Voir aussi Comprendre le Critère de succès 2.2.3 Pas de délai.