Critérios de Sucesso WCAG · Level A

WCAG 2.2.1: Tempo Ajustável

A WCAG 2.2.1 exige que qualquer limite de tempo definido pelo conteúdo possa ser desativado, ajustado ou estendido pelo usuário — garantindo que pessoas que precisam de mais tempo para interagir com o conteúdo da web não sejam excluídas. Este critério de Nível A é essencial para usuários com deficiências motoras, cognitivas e visuais.

O que Esta Regra Significa

WCAG 2.2.1 Ajustável no Tempo é um critério de sucesso de Nível A sob o Princípio 2: Operável. Ele estabelece que, para cada limite de tempo definido pelo conteúdo, pelo menos uma das seguintes condições deve ser verdadeira: o usuário pode desativar o limite de tempo antes de encontrá-lo; o usuário pode ajustar o limite de tempo em uma ampla faixa (pelo menos dez vezes a configuração padrão); ou o usuário pode estender o limite de tempo com uma ação simples — como pressionar uma tecla ou clicar em um botão — antes que o tempo expire, sendo avisado com pelo menos 20 segundos de antecedência, com a opção de estender pelo menos dez vezes.

Na prática, esse critério se aplica a qualquer interface web que imponha um tempo de expiração de sessão, um carrossel que avança automaticamente com slides temporizados, um formulário que é limpo ou enviado automaticamente, um cronômetro regressivo em uma página de checkout, um reprodutor de mídia com legendas temporizadas que não podem ser pausadas ou qualquer outro mecanismo que restrinja o tempo que o usuário tem para concluir uma tarefa. Se sua página ou aplicação define um temporizador que, ao expirar, remove conteúdo, desconecta o usuário ou o leva a um novo estado sem o seu consentimento, você deve oferecer uma forma de ajustar ou estender esse limite.

O critério também define três exceções importantes que podem permitir que um limite de tempo permaneça sem os mecanismos de ajuste descritos acima. Primeiro, a exceção de tempo real: se o limite de tempo é uma parte necessária de um evento em tempo real (como um leilão ao vivo ou um exame online síncrono), ajustar o tempo invalidaria a própria atividade, e nenhuma alternativa é viável. Segundo, a exceção essencial: se o limite de tempo é essencial e estendê-lo invalidaria a atividade — por exemplo, um teste de habilidades cronometrado em que medir a velocidade de resposta é o objetivo. Terceiro, a exceção de 20 horas: se o limite de tempo for superior a 20 horas, o ônus sobre os usuários é considerado mínimo e controles de ajuste não são exigidos.

Uma conformidade ocorre quando uma interação com limite de tempo fornece um mecanismo claro — idealmente apresentado antes de o limite ser encontrado — que permite ao usuário desativar, estender ou ajustar a restrição de tempo. Uma falha ocorre quando o conteúdo expira automaticamente, redireciona, desconecta o usuário ou avança sem oferecer nenhuma das três opções de ajuste acima, e nenhuma das três exceções se aplica.

Por Que Isso Importa

Limites de tempo afetam desproporcionalmente pessoas com deficiência. Usuários que dependem de leitores de tela frequentemente navegam pelas páginas mais lentamente do que usuários videntes, porque ouvem o conteúdo de forma linear e precisam explorar interfaces desconhecidas de maneira sequencial. Usuários com deficiências motoras — incluindo aqueles que usam dispositivos de varredura, software de rastreamento ocular, ponteiras de cabeça ou boca, ou software de controle por voz — podem levar significativamente mais tempo para preencher um campo de formulário, confirmar uma compra ou navegar para a próxima etapa. Usuários com deficiências cognitivas ou de aprendizagem, incluindo dislexia, condições de déficit de atenção ou deficiências de memória, podem precisar de tempo adicional para ler, entender e responder às instruções. Pessoas idosas também costumam precisar de mais tempo para as mesmas tarefas, e representam um segmento em rápido crescimento da população global de usuários da internet.

Considere um cenário concreto do mundo real: uma pessoa com paralisia cerebral está concluindo a reserva de um voo em um site de uma companhia aérea turca. A sessão de checkout expira automaticamente após cinco minutos de inatividade. A pessoa, digitando lentamente com um dispositivo de ponteira de cabeça, inseriu seu nome, número de passaporte e dados de pagamento — e então a página recarrega, limpando todos os dados e retornando à página inicial. Não apenas o esforço foi perdido, como a confiança no site foi abalada, e essa pessoa pode não conseguir concluir a compra. Isso é uma barreira direta à participação igualitária no comércio digital.

O impacto é mais amplo do que usuários individuais. De acordo com a Organização Mundial da Saúde, aproximadamente 1,3 bilhão de pessoas no mundo vivem com algum tipo de deficiência significativa. Só na Turquia, estatísticas oficiais do TÜİK indicam que mais de 8,5 milhões de pessoas têm uma deficiência que afeta as atividades diárias. Interfaces com limite de tempo excluem uma parcela mensurável da base potencial de usuários de qualquer aplicação web.

Além da acessibilidade, remover limites de tempo arbitrários ou torná-los ajustáveis também beneficia usuários em ambientes de baixa largura de banda, usuários com função motora temporariamente comprometida (como um braço quebrado) e usuários que simplesmente são interrompidos durante uma tarefa. As melhorias de usabilidade são amplas e podem reduzir taxas de abandono de formulários, aumentar taxas de conversão em sites de e-commerce e diminuir o volume de chamadas ao suporte ao cliente.

Regras Relacionadas do Axe-core

WCAG 2.2.1 exige testes manuais. Ferramentas automatizadas — incluindo axe-core, Lighthouse e mecanismos semelhantes — não conseguem detectar de forma confiável violações de tempo porque limites de tempo são frequentemente implementados na lógica de sessão do lado do servidor, em JavaScript que roda de forma assíncrona ou em integrações de terceiros. A ferramenta não tem como observar que uma página vai expirar em cinco minutos, ou que um carrossel vai avançar sem entrada do usuário, apenas inspecionando o DOM ou executando análise estática. As considerações a seguir explicam o que os testadores devem avaliar manualmente.

  • Tempos de expiração de sessão (manual): Os testadores devem aguardar ou simular um tempo de expiração de sessão para determinar se a página apresenta um aviso antecipado, oferece uma opção de extensão e fornece pelo menos 20 segundos para o usuário responder. Nenhuma regra automatizada pode determinar a duração da sessão ou se uma caixa de diálogo de aviso aparece a tempo sem realmente aguardar o tempo de expiração.
  • Carrosséis e sliders com avanço automático (manual): Os testadores devem observar se os carrosséis avançam automaticamente e, em caso afirmativo, se um controle de pausa ou parada está presente e acessível pelo teclado. O axe-core pode detectar alguns atributos ARIA ausentes em componentes de carrossel, mas não pode determinar se o próprio avanço temporizado é ajustável.
  • Formulários que enviam ou limpam automaticamente (manual): Se um formulário envia ou limpa seu conteúdo após um período de inatividade, um testador deve identificar esse comportamento por observação ou revisão de código. O DOM por si só não revela esse comportamento a um scanner automatizado.
  • Cronômetros regressivos em fluxos transacionais (manual): Páginas de checkout, fluxos de reserva de bilhetes e ambientes de exame frequentemente incluem cronômetros regressivos. Determinar se esses cronômetros são essenciais (e, portanto, isentos) ou se exigem um mecanismo de extensão é uma decisão que requer revisão humana tanto da implementação quanto do contexto de negócio.

Como Testar

  1. Base de varredura automatizada: Execute axe DevTools ou Lighthouse na página para identificar quaisquer violações conhecidas de ARIA ou de elementos interativos que possam agravar problemas de tempo. Observe que essas ferramentas não sinalizarão o próprio limite de tempo, mas ajudam a estabelecer uma base de outros problemas de acessibilidade. No Chrome DevTools, abra o painel Lighthouse, selecione Accessibility e execute a auditoria. No axe DevTools, ative a extensão do navegador, clique em Analyze e revise os resultados — nenhuma regra específica de tempo aparecerá, confirmando que testes manuais são necessários.
  2. Identifique todos os limites de tempo: Revise o código-fonte JavaScript da página, as requisições de rede e a configuração de sessão do lado do servidor para identificar todos os limites de tempo. Locais comuns incluem chamadas setTimeout e setInterval em JavaScript, configurações de expiração de sessão em frameworks de backend, valores de expiração de cookies e configurações de widgets de terceiros, como processadores de pagamento ou widgets de chat.
  3. Teste o aviso de expiração de sessão com NVDA + Firefox: Abra o site no Firefox com o NVDA em execução. Navegue por um formulário de múltiplas etapas ou uma seção autenticada. Aguarde a caixa de diálogo de aviso de sessão (ou a própria expiração, se nenhum aviso aparecer). Verifique se o NVDA anuncia o aviso automaticamente — idealmente por meio de uma região ao vivo — e se o usuário pode estender a sessão pressionando Enter ou Espaço em um botão em foco sem perder os dados do formulário.
  4. Teste o aviso de expiração de sessão com VoiceOver + Safari (macOS/iOS): Repita o teste acima no Safari com o VoiceOver ativado. Use o rotor para navegar pelos elementos interativos e confirme se o aviso de expiração é anunciado e se o controle de extensão é alcançável dentro da janela de 20 segundos.
  5. Teste o aviso de expiração de sessão com JAWS + Chrome: Repita com JAWS no Chrome. Confirme se o foco é movido para a caixa de diálogo de aviso, se o JAWS lê o tempo restante e a opção de extensão, e se ativar o botão de extensão mantém a sessão ativa sem exigir recarregamento da página.
  6. Teste apenas com teclado (sem leitor de tela): Desative o mouse e navegue inteiramente com Tab, Shift+Tab, Enter e Espaço. Confirme se qualquer caixa de diálogo de aviso é alcançável pelo teclado, se o botão de extensão pode receber foco e se o foco é retornado ao local correto no formulário após a sessão ser estendida.
  7. Teste o tempo de carrosséis e mídia: Identifique quaisquer carrosséis com avanço automático. Navegue até o carrossel usando Tab. Verifique se um botão de pausa ou parada está presente e alcançável sem mouse. Ative-o e confirme se o avanço é interrompido. Se o carrossel for retomado após interação do usuário, confirme que ele não retoma automaticamente.
  8. Verifique a aplicabilidade das exceções: Para cada limite de tempo encontrado, determine se a exceção de tempo real, essencial ou de 20 horas se aplica. Documente seu raciocínio. Se nenhuma das exceções se aplicar e não existir mecanismo de ajuste, registre isso como uma falha de WCAG 2.2.1.

Como Corrigir

Tempo de Expiração de Sessão Sem Aviso — Incorreto

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

Tempo de Expiração de Sessão Com Aviso e Extensão — Correto

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

Carrossel com Avanço Automático Sem Controles — Incorreto

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

Carrossel com Avanço Automático e Controle de Pausa — Correto

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

Contagem Regressiva de Checkout Temporizado Sem Extensão — Incorreto

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

Contagem Regressiva de Checkout Temporizado Com Opção de Extensão — Correto

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

Erros Comuns

  • Exibir um aviso de expiração sem gerenciamento de foco de teclado: A caixa de diálogo de aviso aparece visualmente, mas o foco nunca é movido para ela, de modo que usuários que dependem apenas de teclado e leitores de tela nunca descobrem que podem estender a sessão antes que ela expire.
  • Fornecer menos de 20 segundos para responder a um aviso de expiração: Exibir um alerta de "Sessão expirando" apenas 10 segundos antes do logout não atende ao critério, que exige que pelo menos 20 segundos estejam disponíveis para a ação de extensão.
  • Usar role='alert' em uma caixa de diálogo de expiração que exige interação: Um papel de alerta é para anúncios somente leitura; uma caixa de diálogo que exige entrada do usuário deve usar role='alertdialog' com aria-modal='true' e aria-labelledby para que leitores de tela a tratem como um modal que exige resposta.
  • Alegar a exceção essencial para um temporizador padrão de carrinho de e-commerce: Reservar itens em um carrinho de compras por 10 minutos é uma conveniência de negócio, não uma atividade verdadeiramente essencial em que medir a velocidade é o objetivo. Aplicar a exceção essencial aqui é incorreto; um mecanismo de extensão é necessário.
  • Avançar automaticamente um carrossel sem um botão de pausa visível e acessível pelo teclado: Adicionar um botão de pausa que só é visível ao passar o mouse, ou que está ausente da ordem de Tab, não atende ao critério. O controle deve ser alcançável sem um dispositivo apontador.
  • Reiniciar o contador de expiração em qualquer movimento do mouse, mas não em eventos de teclado: JavaScript que estende o temporizador de inatividade em eventos de mousemove mas ignora eventos de keydown ou focus vai expirar sessões silenciosamente para usuários que usam apenas teclado e que estão ativamente trabalhando na página.
  • Estender a sessão por meio de recarregamento completo da página: Quando um usuário clica em "Permanecer conectado", recarregar a página limpa quaisquer dados que ele tenha inserido em formulários. A extensão deve ocorrer por meio de uma chamada de API ou atualização de cookie em segundo plano, preservando o estado do DOM.
  • Usar valores de setTimeout que não são configuráveis ou expostos ao usuário: Definir rigidamente uma duração de sessão de cinco minutos sem nenhum controle de interface para o usuário escolher uma duração maior viola o critério, a menos que um dos três mecanismos de ajuste (desativar, ajustar ou estender) esteja disponível.
  • Deixar de testar o fluxo de expiração com tecnologias assistivas reais antes do lançamento: Desenvolvedores que testam apenas com mouse podem não perceber que a caixa de diálogo de aviso é inacessível para usuários de leitores de tela, porque testes com visão não revelam falhas de gerenciamento de foco.
  • Presumir que widgets incorporados de terceiros cumprem automaticamente: Processadores de pagamento, widgets de chat ao vivo e mecanismos de reserva incorporados por iframes ou scripts frequentemente impõem seus próprios limites de tempo. A responsabilidade pela conformidade com a WCAG da página inteira — incluindo conteúdo incorporado que você controla — recai sobre o proprietário da página.

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 requisitos obrigatórios de acessibilidade na web alinhados com a WCAG 2.2 Nível AA para uma ampla gama de entidades públicas e privadas que operam serviços digitais na Turquia. WCAG 2.2.1 Ajustável no Tempo é um critério de Nível A, o que significa que está na camada fundamental de conformidade — está entre os primeiros requisitos que as entidades abrangidas devem satisfazer.

Nos termos da circular, instituições e órgãos públicos — incluindo ministérios, prefeituras, universidades e empresas estatais — são obrigados a alcançar conformidade total dentro de um ano a partir da data de publicação da circular. Entidades do setor privado abrangidas pela regulamentação têm um prazo de dois anos para se adequar. O escopo do setor privado é explicitamente amplo: abrange plataformas de e-commerce, bancos e instituições financeiras, hospitais privados e prestadores de serviços de saúde, empresas de telecomunicações com 200.000 ou mais assinantes, agências de viagens, empresas privadas de transporte de passageiros e escolas privadas que operam sob autorização do Ministério da Educação Nacional (MoNE).

Para organizações nessas categorias, uma falha em WCAG 2.2.1 não é apenas uma lacuna de boas práticas — é uma não conformidade legal que pode atrair escrutínio regulatório, reclamações por canais oficiais e danos à reputação. Considere os fluxos de negócio específicos mais propensos a desencadear essa violação: um checkout de e-commerce com reserva de carrinho temporizada, uma sessão de banco online que expira silenciosamente enquanto um cliente preenche um formulário de pagamento, um sistema de agendamento de consultas hospitalares que expira antes que uma pessoa com deficiência motora consiga concluir seu cadastro, ou o portal de autoatendimento de uma operadora de telecomunicações que desconecta automaticamente usuários de um fluxo de gestão de contrato. Cada um desses é um cenário plausível de falha dentro de um tipo de entidade explicitamente nomeado na circular.

As organizações devem tratar a conformidade com WCAG 2.2.1 não como um item técnico de checklist, mas como um requisito de design que precisa ser abordado em nível de arquitetura — em políticas de gerenciamento de sessão, requisitos de contratação de widgets de terceiros e padrões de componentes de interface — em vez de ser adaptado posteriormente como um remendo. Programas de auditoria devem incluir testes manuais de todas as interações temporizadas, não apenas varreduras automatizadas, precisamente porque ferramentas automatizadas não conseguem detectar essa classe de violação sem observação humana.