WCAG 2.2.3: Sem temporização

O Que Esta Regra Significa

WCAG 2.2.3 — No Timing (Sem Temporização) situa-se no nível de conformidade AAA sob a Diretriz 2.2: Tempo Suficiente. Sua exigência é direta: a temporização não deve ser parte essencial de qualquer evento ou atividade apresentada ao usuário. Em outras palavras, se o seu conteúdo ou funcionalidade envolve um limite de tempo, prazo ou interação sensível ao tempo de qualquer tipo, essa dependência de tempo deve ser removível ou completamente irrelevante para a tarefa em questão — a menos que se aplique uma das exceções restritas.

Este critério vai além do critério de Nível A 2.2.1 (Tempo Ajustável) e do critério de Nível AA 2.2.2 (Pausar, Parar, Ocultar). Enquanto esses critérios anteriores permitem limites de tempo ajustáveis ou que possam ser pausados, 2.2.3 exige que a temporização simplesmente não exista como uma restrição significativa. Um usuário que leva dez segundos ou dez minutos para preencher um formulário, navegar em um menu ou completar um fluxo de trabalho deve chegar ao mesmo resultado que um usuário que termina instantaneamente.

O que conta como aprovação: Conteúdo em que não existe limite de tempo, ou em que qualquer limite de tempo presente é puramente cosmético e não tem impacto no resultado (por exemplo, uma animação que se repete em loop, mas não impede a interação). Conteúdo que é totalmente funcional independentemente de quanto tempo o usuário leva atende a este critério.

O que conta como reprovação: Expiração de sessão que desconecta usuários após inatividade; testes ou avaliações cronometrados em que a pontuação ou conclusão dependem de terminar dentro de um intervalo; temporizadores de expiração de carrinho de compras que excluem itens; interfaces de lance em leilão com contagens regressivas que encerram os lances; campos de senha de uso único (OTP) que expiram; desafios CAPTCHA com limites de tempo; e qualquer elemento interativo que se torne indisponível ou seja enviado automaticamente com base no tempo decorrido.

Exceções oficiais definidas pelo WCAG: O critério isenta explicitamente duas categorias. Primeiro, exceções em tempo real — eventos em que a temporização é absolutamente inerente à atividade, como um leilão ao vivo, uma transmissão ao vivo ou um jogo multijogador em tempo real. Segundo, exceções essenciais — situações em que remover o limite de tempo alteraria fundamentalmente a atividade. Por exemplo, um teste de proficiência em digitação rápida mede inerentemente velocidade, portanto a temporização é essencial. No entanto, desenvolvedores e responsáveis pelo produto devem ser rigorosos: conveniência, legado técnico ou preferência de negócio não se qualificam como “essenciais”. O critério é se a atividade perderia seu significado ou propósito central sem a restrição de tempo.

É importante observar que mídia sincronizada — como um vídeo pré-gravado com legendas — também é excluída, porque a temporização na reprodução de mídia é controlada pelo próprio reprodutor do usuário e não impõe uma restrição à capacidade do usuário de interagir com o restante da página.

Por Que Isso Importa

Limites de tempo na web prejudicam desproporcionalmente usuários em uma ampla gama de deficiências. O impacto não é abstrato — para muitos usuários, uma interface cronometrada é, na prática, inacessível.

Usuários com deficiências motoras — incluindo aqueles que usam dispositivos de acesso por varredura, ponteiras bucais, softwares de rastreamento ocular ou outros métodos de entrada alternativos — operam em um ritmo fundamentalmente diferente de usuários de mouse e teclado. Concluir um formulário de múltiplas etapas ou navegar em um menu suspenso pode levar várias vezes mais tempo. Uma expiração de sessão ou um carrinho que expira automaticamente pode apagar, em um instante, minutos de trabalho cuidadoso e esforçado.

Usuários com deficiências cognitivas, incluindo dislexia, TDAH, transtornos de processamento e lesões cerebrais adquiridas, podem precisar de significativamente mais tempo para ler instruções, entender opções ou compor respostas. Pesquisas compiladas pela Web Accessibility Initiative estimam que deficiências cognitivas e de aprendizagem afetam aproximadamente 15–20% da população global de alguma forma. Para esses usuários, um cronômetro regressivo não é apenas estressante — ele prejudica ativamente o processamento cognitivo necessário para completar a tarefa.

Usuários de leitores de tela que são cegos ou têm baixa visão navegam pelo conteúdo de forma linear e precisam ouvir ou ler os elementos da interface sequencialmente. Entender a estrutura e as opções em uma página complexa leva mais tempo do que para um usuário vidente que faz uma leitura visual rápida. Um fluxo de checkout cronometrado que expira enquanto uma pessoa cega revisa cuidadosamente o resumo do pedido é uma barreira direta ao comércio.

Usuários com transtornos de ansiedade podem achar que a mera presença de um cronômetro regressivo cria carga cognitiva e emocional suficiente para impedir a conclusão da tarefa, mesmo que tecnicamente tenham tempo suficiente. Remover a temporização como fator elimina completamente essa barreira.

Um cenário concreto do mundo real: Considere um portal de banco online que usa um tempo limite de inatividade de cinco minutos combinado com um OTP que expira em sessenta segundos. Um usuário com doença de Parkinson que precisa de tecnologia assistiva de entrada para digitar, ou um usuário idoso que não está acostumado a alternar rapidamente entre aplicativos, pode achar fisicamente impossível receber o SMS, alternar de aplicativo, ler o código, voltar e digitá-lo dentro do prazo. Eles ficam bloqueados em sua própria conta — não por necessidade de segurança, mas por uma restrição de tempo arbitrária. Projetar o OTP para permanecer válido por um período mais longo (ou eliminar a expiração rígida em favor de um mecanismo de reenvio) resolve o problema sem comprometer a segurança.

Além da acessibilidade, remover restrições de tempo desnecessárias melhora a usabilidade geral e reduz taxas de abandono. Um checkout de e-commerce que não expira no meio do fluxo retém mais clientes, aumenta a conversão e reduz a carga de suporte — tornando essa mudança positiva para o negócio, além de um imperativo ético.

Regras Relacionadas do Axe-core

WCAG 2.2.3 exige testes manuais. Nenhuma regra automatizada do axe-core mapeia diretamente para este critério, e esta é uma realidade arquitetural importante a ser entendida.

• Teste manual necessário — Temporização de sessão e interação: Ferramentas automatizadas não conseguem detectar se um aplicativo web impõe um limite de tempo porque a lógica de temporização é implementada no gerenciamento de sessão do lado do servidor, em temporizadores JavaScript ou em respostas de API de back-end — nada disso é visível em uma análise estática do DOM. Uma ferramenta como o axe-core inspeciona o HTML renderizado e a árvore de acessibilidade; ela não consegue observar que uma requisição fetch retornará um 401 após cinco minutos de inatividade, ou que um setTimeout em JavaScript redirecionará o usuário para uma página de logout. Somente um testador humano que interage com o aplicativo lentamente e observa o que acontece pode determinar se existem restrições de tempo e se elas afetam a conclusão da tarefa.
• Teste manual necessário — Expiração de OTP e CAPTCHA: Senhas de uso único e desafios de verificação com limite de tempo aparecem no DOM como campos de entrada comuns. O cronômetro regressivo, se visível, pode ser apenas um nó de texto simples ou um elemento animado por CSS. O axe não consegue inferir que inserir um valor nesse campo após noventa segundos resultará em um estado de erro. Um testador deve deliberadamente esperar além da janela de expiração e tentar enviar para confirmar se a temporização é aplicada.
• Teste manual necessário — Formulários com envio e avanço automáticos: Algumas interfaces avançam automaticamente para a próxima etapa ou enviam um formulário após um período de inatividade ou após uma duração definida (por exemplo, uma pesquisa que passa para a próxima pergunta após trinta segundos). O axe-core não sinalizará isso porque a estrutura do DOM parece válida; o comportamento problemático só se manifesta durante a interação real ao longo do tempo.
• Teste manual necessário — Expiração em comércio e reservas: Temporizadores de reserva de carrinho de compras, bloqueios de reserva de ingressos e travas de horário de agendamento são implementados via lógica de servidor e refletidos na interface apenas como uma contagem regressiva. Ferramentas automatizadas veem um número sendo atualizado na tela, mas não conseguem determinar se isso causa perda de dados ou negação de acesso quando chega a zero.

Como Testar

1. Varredura automatizada de base: Execute o axe DevTools ou o Lighthouse na página para identificar quaisquer violações de temporização de nível inferior relacionadas (como as cobertas por 2.2.1 ou 2.2.2) que possam apontar áreas que exigem inspeção manual mais profunda. Embora nenhuma regra do axe teste diretamente 2.2.3, achados relacionados a avisos de limite de tempo ou atualização automática podem orientar o escopo da sua auditoria manual. No Lighthouse, revise a seção “Acessibilidade” em busca de quaisquer sinalizações relacionadas a tempo.
2. Faça um inventário de todos os recursos dependentes de tempo: Antes de testar, catalogue sistematicamente todos os recursos do aplicativo que possam envolver temporização. Isso inclui: gerenciamento de sessão e tempos limite de inatividade; campos de OTP e códigos de verificação; reservas de carrinho de compras ou de agendamentos; testes, avaliações ou pesquisas cronometrados; interfaces de leilão ou de lances; desafios CAPTCHA; mecanismos de salvamento automático com janelas de envio; e qualquer contagem regressiva ou temporizador de progresso visível.
3. Teste o comportamento de tempo limite de sessão: Abra o aplicativo e inicie uma tarefa que envolva múltiplas etapas (por exemplo, preencher um formulário de várias páginas ou concluir um checkout). Não interaja por um período que exceda a janela de tempo limite suspeita. Em seguida, tente continuar. Observe se o seu progresso é preservado, se você é avisado e recebe a possibilidade de estender a sessão, ou se é desconectado ou perde dados. Uma aprovação exige que não exista tempo limite, que o tempo limite seja puramente precaucionário e os dados sejam preservados na reautenticação, ou que o usuário receba aviso e controle adequados.
4. Teste a expiração de OTP e códigos: Dispare um fluxo de OTP ou código de verificação. Aguarde até após o tempo de expiração declarado do código (ou mais, se nenhum tempo for exibido). Tente inserir o código. Se o sistema o rejeitar exclusivamente devido ao tempo, isso é uma falha em 2.2.3. Observação: um mecanismo de “reenviar” por si só não corrige 2.2.3 — a expiração do código original ainda impõe temporização.
5. Teste com leitor de tela (NVDA + Firefox): Usando NVDA com Firefox, navegue por qualquer interface cronometrada usando apenas o teclado e o leitor de tela. Observe quanto tempo cada etapa leva com a sobrecarga de navegação por tecnologia assistiva. Prossiga deliberadamente em um ritmo lento — pause para ouvir todas as instruções, explore todas as opções via cursor virtual — e então tente enviar ou prosseguir. Verifique se a navegação lenta não aciona tempo limite ou perda de estado.
6. Teste com leitor de tela (VoiceOver + Safari no macOS): Repita o mesmo teste de navegação lenta usando VoiceOver no macOS com Safari. Preste atenção especial a cronômetros regressivos dinâmicos: o VoiceOver anuncia o tempo restante de uma forma que cria urgência, e a interface falha quando o tempo acaba?
7. Teste com leitor de tela (JAWS + Chrome): Usando JAWS com Chrome, teste os mesmos fluxos. Usuários de JAWS representam uma parcela significativa de usuários profissionais de leitores de tela; problemas de temporização que afetam usuários de NVDA normalmente afetarão usuários de JAWS da mesma forma.
8. Verifique a legitimidade das exceções: Para qualquer temporização que a equipe de desenvolvimento alegue ser “essencial” ou “em tempo real”, documente a justificativa e avalie se a temporização é realmente inerente ao propósito da atividade, ou se poderia ser relaxada, estendida ou removida sem alterar a natureza fundamental da tarefa.

Como Corrigir

Tempo Limite de Sessão — Incorreto

<!-- 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>

Tempo Limite de Sessão — Correto

<!-- 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. -->

Campo de OTP com Expiração — Incorreto

<!-- 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>

Campo de OTP com Expiração — Correto

<!-- 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 Cronometrado — Incorreto

<!-- 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 Cronometrado — Correto

<!-- 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> -->

Erros Comuns

• Presumir que a segurança da sessão exige um tempo limite rígido: Muitas equipes implementam tempos de inatividade curtos citando requisitos de segurança, mas a maioria dos padrões de segurança (incluindo PCI-DSS e OWASP) permite extensão de sessão controlada pelo usuário. Um logout rígido sem aviso ou oportunidade de extensão é uma falha de acessibilidade, não uma necessidade de segurança.
• Exibir um cronômetro regressivo sem oferecer uma forma de pará-lo ou estendê-lo: Adicionar uma região aria-live a uma contagem regressiva a torna pior para usuários de leitores de tela — ela anuncia a cada segundo — sem corrigir o problema de temporização subjacente. A correção é remover a restrição, não anunciá-la de forma mais acessível.
• Tratar “reenviar código” como solução para expiração de OTP: Fornecer um botão de reenvio permite que usuários obtenham um novo código, mas não resolve o fato de que o código original expirou devido à temporização. O limite de tempo ainda está presente. A correção adequada é estender a janela de validade para eliminar a pressão de tempo.
• Avançar automaticamente etapas de carrossel ou assistente após inatividade: Formulários de múltiplas etapas ou assistentes que avançam automaticamente para a próxima etapa após um tempo definido impõem uma restrição de tempo. Usuários que estão lendo instruções ou considerando sua resposta são prejudicados. As etapas devem avançar apenas mediante ação explícita do usuário.
• Temporizadores de carrinho de compras que excluem itens sem preservá-los: Temporizadores de reserva em e-commerce (“Seu carrinho expira em 15 minutos”) falham em 2.2.3 quando os itens são perdidos permanentemente na expiração, em vez de simplesmente liberados da reserva. No mínimo, os itens devem ser salvos em uma lista de desejos ou a sessão deve ser restaurável.
• Aplicar a “exceção em tempo real” de forma muito ampla: Rotular uma interface como “em tempo real” para justificar restrições de temporização quando ela não é genuinamente ao vivo. Uma reprodução de leilão pré-gravada, uma interface de lances estática ou um quiz que apenas se assemelha a um programa de auditório não se qualifica para a exceção em tempo real.
• Ignorar temporização em respostas de API de back-end: Equipes corrigem cronômetros no front-end, mas ignoram que a própria API rejeita requisições feitas após determinada janela. O usuário não vê contagem regressiva, mas sua submissão falha silenciosamente. O gerenciamento de sessão no back-end deve estar alinhado com a experiência no front-end.
• Usar setTimeout para logout automático sem persistir o estado do formulário: Quando um logout automático é inevitável (por exemplo, devido a exigências regulatórias), não salvar os dados do formulário do usuário antes do redirecionamento significa que todo o trabalho é perdido. No mínimo, o rascunho deve ser salvo e restaurado após a reautenticação.
• Confundir conformidade com 2.2.1 com conformidade com 2.2.3: Fornecer um controle para “desativar, ajustar ou estender” (como exigido por 2.2.1 Nível A) não satisfaz 2.2.3. O Nível AAA exige que a temporização não seja essencial — não apenas gerenciável. Um limite de tempo com uma extensão generosa ainda é um limite de tempo.
• Ignorar temporização em componentes incorporados de terceiros: Widgets de chat incorporados, processadores de pagamento, SDKs de verificação de identidade e serviços de mapa podem introduzir suas próprias restrições de tempo. A origem de terceiros não isenta esses componentes da aplicabilidade do WCAG quando são integrados à sua interface.

Relação com os Regulamentos de Acessibilidade da Turquia

A Circular Presidencial 2025/10 da Turquia, publicada no Diário Oficial nº 32933 em 21 de junho de 2025, estabelece um framework nacional de acessibilidade na web que referencia o WCAG 2.2 como base técnica. A Circular exige conformidade em uma ampla gama de entidades que operam serviços digitais na Turquia.

Os tipos de entidades cobertas incluem instituições públicas e órgãos governamentais, plataformas de e-commerce, bancos e serviços financeiros, hospitais e prestadores de serviços de saúde, empresas de telecomunicações com 200.000 ou mais assinantes, agências de viagem, empresas de transporte privado e escolas privadas autorizadas pelo Ministério da Educação Nacional (MoNE). Essas organizações são obrigadas a atender aos padrões de acessibilidade definidos ou referenciados na Circular ao fornecer serviços digitais ao público.

WCAG 2.2.3 — No Timing (Sem Temporização) é um critério de Nível AAA, e a Circular Presidencial 2025/10, assim como a norma europeia EN 301 549 com a qual se alinha, exige conformidade de Nível A e Nível AA como mínimo legal. A conformidade de Nível AAA não é uma obrigação legal direta sob esse framework. No entanto, alcançar o Nível AAA — e especificamente implementar 2.2.3 — é reconhecido como um indicador de maturidade de acessibilidade de classe mundial e demonstra um compromisso genuíno com design inclusivo além dos limites legais mínimos.

Para certos tipos de entidades cobertas, particularmente bancos e serviços financeiros sob supervisão do BDDK, e plataformas de e-commerce com alto volume de transações, restrições de tempo como expiração de OTP, gerenciamento de sessão e temporizadores em fluxos de checkout são recursos onipresentes. Mesmo quando 2.2.3 não é exigido por lei, deixar de abordar barreiras de temporização nesses fluxos cria risco real de discriminação — especialmente à medida que os mecanismos de fiscalização de acessibilidade na Turquia amadurecem e os procedimentos de reclamação se tornam mais consolidados.

Instituições públicas e prestadores de serviços de saúde que atendem usuários com deficiência, usuários idosos e usuários com baixa literacia digital têm um argumento ético particularmente forte para eliminar completamente as restrições de tempo. Remover limites de tempo de serviços digitais governamentais e portais de saúde está alinhado com os objetivos mais amplos de inclusão do governo eletrônico da Turquia e reduz o risco de exposição regulatória futura à medida que a adoção de AAA em compras públicas se torna mais comum.

Organizações que buscam posicionar seus produtos digitais como totalmente inclusivos — seja para liderança doméstica, acesso a mercados internacionais ou vantagens em processos de contratação pública em contextos da União Europeia (onde se aplicam a EN 301 549 e o Ato Europeu de Acessibilidade) — devem tratar a conformidade com WCAG 2.2.3 como um investimento estratégico, e não como um aprimoramento opcional.