WCAG 2.2.6: Limites de tempo

O que Esta Regra Significa

WCAG 2.2.6 Timeouts (Nível AAA) exige que os usuários sejam avisados sobre a duração de qualquer inatividade que possa causar perda de dados, a menos que os dados sejam preservados por mais de 20 horas de inatividade do usuário. Em termos práticos, isso significa que, se seu aplicativo ou serviço web pode perder dados de um usuário — como entradas de formulário, um carrinho de compras ou uma transação em andamento — porque o usuário ficou inativo por um período de tempo, você deve informar os usuários exatamente quanto tempo eles têm antes que esses dados sejam perdidos.

O critério se aplica a qualquer situação em que um timeout resulte em perda de dados. Exemplos comuns incluem expiração de sessão em portais bancários ou governamentais que apagam dados de formulários, carrinhos de compras que esvaziam após um período de inatividade, assistentes ou formulários de múltiplas etapas que são redefinidos quando um cookie de sessão expira e sistemas de testes ou reservas online que descartam respostas parciais. O gatilho principal é a combinação de inatividade (não um limite rígido de tempo para concluir uma tarefa, que é coberto por 2.2.1) e a consequência de perda de dados.

O que conta como aprovação: Uma página atende ao 2.2.6 se informar claramente os usuários, no início de uma sessão — ou antes de começarem a inserir dados — sobre a duração específica de inatividade que resultará em perda de dados. Alternativamente, uma página é aprovada se nenhuma perda de dados puder ocorrer independentemente de quanto tempo o usuário fique inativo (por exemplo, porque o servidor persiste todos os dados do formulário por mais de 20 horas, ou indefinidamente). Exibir um aviso apenas depois que a sessão já expirou não satisfaz o critério.

O que conta como reprovação: Uma página falha se perder silenciosamente dados do usuário após um período de inatividade sem jamais informar o usuário sobre esse risco. Também falha se existir um aviso, mas ele for apresentado apenas no momento da perda de dados (tarde demais para agir), ou se o aviso for vago — por exemplo, afirmar "sua sessão pode expirar" sem especificar a duração real de inatividade que aciona o timeout.

Exceções oficiais: O critério isenta explicitamente situações em que os dados são preservados por mais de 20 horas de inatividade. O limite de 20 horas foi escolhido para acomodar usuários que iniciam uma tarefa em um dia e a retomam no dia seguinte. Se seu sistema armazena de forma confiável todos os dados inseridos no servidor por pelo menos 20 horas sem exigir qualquer ação do usuário, você não é obrigado a exibir um aviso. Além disso, este critério não se aplica a timeouts que sejam essenciais para a segurança — por exemplo, uma exigência legal ou regulatória rígida de que uma sessão deve ser encerrada após um período fixo, independentemente da ação do usuário. Nesses casos, o critério ainda incentiva a divulgação, mas reconhece a restrição legal.

Por Que Isso Importa

Timeouts sem aviso adequado afetam desproporcionalmente pessoas com deficiências cognitivas, deficiências motoras e aquelas que são cegas ou têm baixa visão. Usuários com deficiências cognitivas como dislexia, TDAH ou lesão cerebral traumática podem precisar de muito mais tempo para ler instruções, redigir textos ou revisar informações antes de enviar um formulário. Se uma sessão expira silenciosamente enquanto ainda estão trabalhando, eles perdem todo o esforço e precisam recomeçar — uma experiência profundamente desanimadora que pode levá-los a abandonar a tarefa por completo.

Pessoas com deficiências motoras que dependem de acesso por varredura, dispositivos de rastreamento ocular ou outros métodos alternativos de entrada interagem com interfaces em um ritmo muito mais lento do que um usuário de mouse. Concluir um longo formulário de sinistro de seguro ou uma solicitação governamental de várias páginas pode levar a elas muitas vezes mais tempo do que o timeout de sessão padrão supõe. Sem conhecer a contagem regressiva, elas não têm oportunidade de agir — como salvar o progresso ou solicitar uma extensão — antes que seus dados desapareçam.

Usuários de leitores de tela também enfrentam um desafio ampliado: navegar por formulários complexos leva mais tempo quando cada campo precisa ser lido em voz alta e confirmado pelo teclado. Uma sessão que expira enquanto um usuário ainda está trabalhando metodicamente em um formulário longo não é apenas inconveniente — pode representar horas de esforço perdido e uma barreira significativa ao acesso a serviços essenciais.

Considere este cenário do mundo real: uma pessoa com esclerose múltipla está solicitando um benefício por incapacidade por meio de um portal governamental. O formulário tem 12 seções e exige o envio de documentos comprobatórios. A sessão expira após 15 minutos de inatividade, mas a pessoa fez uma pausa no meio da seção 7 para buscar um documento em outro cômodo. Ao retornar, todos os dados foram apagados e ela precisa começar novamente — sem qualquer aviso prévio de que isso aconteceria. De acordo com 2.2.6, o portal seria obrigado a informar a pessoa desde o início que a inatividade por mais de 15 minutos resultará em perda de dados, permitindo que ela se planeje adequadamente.

Além da acessibilidade, divulgar proativamente o comportamento de timeout melhora a experiência do usuário para todos e reduz as taxas de abandono em fluxos de conversão de alto valor, como checkout, registro e formulários de inscrição. Também gera confiança, pois os usuários não ficam se perguntando por que seus dados desapareceram.

Regras Relacionadas do Axe-core

WCAG 2.2.6 exige testes manuais. Não há nenhuma regra automatizada do axe-core que possa detectar essa violação, e entender o porquê é importante tanto para testadores quanto para desenvolvedores.

• Teste manual necessário — Divulgação de timeout de sessão: Ferramentas automatizadas como axe-core podem analisar o DOM em busca da presença ou ausência de elementos específicos, atributos e padrões de texto, mas não podem determinar se um aplicativo web perderá dados do usuário após um período de inatividade. O comportamento de timeout é normalmente regido pela configuração de sessão do lado do servidor (por exemplo, um TTL de sessão em PHP ou Node.js), e a divulgação — se existir — pode aparecer em um texto de onboarding, em uma caixa modal, em uma página de ajuda ou até em uma seção de termos de serviço. Nenhuma análise estática de DOM pode correlacionar de forma confiável um trecho de texto informativo com o comportamento real de timeout do lado do servidor. Uma ferramenta não pode saber se uma frase como "Para sua segurança, as sessões expiram após 15 minutos" é precisa, se se aplica aos dados da página atual ou se está posicionada suficientemente cedo na jornada do usuário para ser acionável. Apenas um testador humano que possa interagir com o aplicativo, observar seu comportamento ao longo do tempo e avaliar a completude e o momento de qualquer divulgação pode determinar a conformidade.
• Teste manual necessário — Verificação de preservação de dados: O axe-core também não pode verificar a exceção de 20 horas. Se os dados são realmente armazenados no servidor por mais de 20 horas — e, portanto, se uma divulgação é necessária ou não — depende inteiramente da lógica de backend, que é invisível para uma ferramenta de varredura baseada em navegador. Os testadores devem revisar a configuração do servidor, conversar com os desenvolvedores ou testar empiricamente, deixando um formulário parcialmente preenchido por um período prolongado e observando se os dados persistem.

Como Testar

1. Pré-varredura automatizada: Execute o axe DevTools ou o Lighthouse na página que contém o formulário, fluxo de checkout ou outra interface de entrada de dados. Embora nenhuma das ferramentas sinalize diretamente uma violação de 2.2.6, use esta etapa para identificar quaisquer regiões ARIA live relacionadas a timeout ou componentes de diálogo que possam fazer parte do mecanismo de aviso e verifique se eles próprios são acessíveis (funções corretas, rótulos, gerenciamento de foco).
2. Identificar o comportamento de timeout: Converse com a equipe de desenvolvimento ou revise a configuração do lado do servidor para determinar a duração do timeout de inatividade da sessão. Locais comuns incluem arquivos de configuração do servidor web, configurações de middleware de sessão da aplicação e documentação do provedor de autenticação. Registre a duração exata em minutos.
3. Verificar a divulgação antecipada: Carregue a página do zero e leia todo o conteúdo apresentado ao usuário antes de qualquer início de inserção de dados. Procure uma declaração clara — no corpo da página, em um parágrafo introdutório, em um banner ou em uma modal — que especifique a duração exata do timeout de inatividade e informe que os dados serão perdidos se o usuário ficar inativo por esse período. A divulgação deve indicar a duração explicitamente (por exemplo, "15 minutos"), não de forma vaga (por exemplo, "um curto período").
4. Testar com um leitor de tela: Usando NVDA com Firefox, VoiceOver com Safari ou JAWS com Chrome, navegue pela página desde o início. Confirme que qualquer divulgação de timeout é alcançável e lida em voz alta pelo leitor de tela sem exigir que o usuário a procure ativamente. Se a divulgação estiver em um banner visualmente proeminente, verifique se ela está na ordem de leitura antes do primeiro campo do formulário.
5. Simular inatividade: Comece a preencher o formulário. Em seguida, pare de interagir com a página por um período ligeiramente inferior ao período de timeout e observe o que acontece. Depois, repita, esperando até que o período de timeout tenha passado. Registre se os dados são perdidos, se um aviso é exibido antes que a perda de dados ocorra e se esse aviso foi comunicado antes do início da sessão.
6. Testar a exceção de 20 horas: Se a equipe afirmar que os dados são preservados por mais de 20 horas, verifique isso empiricamente preenchendo parcialmente um formulário, aguardando pelo menos 20 horas e retornando à página para confirmar se os dados ainda estão presentes. Alternativamente, revise a configuração do armazenamento de sessão do lado do servidor com a equipe de desenvolvimento.
7. Teste de teclado e foco: Se um diálogo ou notificação de aviso de timeout aparecer, verifique, usando apenas navegação por teclado, se ele recebe foco automaticamente, se seu conteúdo é totalmente legível e se o usuário pode dispensá-lo ou agir (por exemplo, estender a sessão) sem usar o mouse.

Como Corrigir

Sessão com perda silenciosa de dados — Incorreto

<!-- A multi-step form with a 10-minute server session timeout.
     No warning is displayed anywhere on the page.
     After 10 minutes of inactivity, the session is destroyed
     and all entered data is lost. -->
<form action='/submit-application' method='post'>
  <h1>Benefit Application</h1>
  <label for='full-name'>Full Name</label>
  <input type='text' id='full-name' name='full-name'>
  <!-- ... many more fields ... -->
  <button type='submit'>Submit Application</button>
</form>

Sessão com perda silenciosa de dados — Correto

<!-- The timeout duration is disclosed clearly before any form fields.
     The disclosure is in the natural reading order so screen readers
     encounter it before the first input. -->
<main>
  <h1>Benefit Application</h1>
  <div role='note' aria-label='Session timeout notice'>
    <p>
      <strong>Important:</strong> This form will time out after
      <strong>10 minutes of inactivity</strong>, and any information
      you have entered will be lost. Please have all required documents
      ready before you begin, or save your progress regularly.
    </p>
  </div>
  <form action='/submit-application' method='post'>
    <label for='full-name'>Full Name</label>
    <input type='text' id='full-name' name='full-name'>
    <!-- ... many more fields ... -->
    <button type='submit'>Submit Application</button>
  </form>
</main>

Sessão de checkout com aviso vago — Incorreto

<!-- The warning exists but is vague — it does not state the actual
     timeout duration, making it impossible for users to plan. -->
<p class='notice'>Your session may expire due to inactivity.</p>
<form action='/checkout' method='post'>
  <label for='card-number'>Card Number</label>
  <input type='text' id='card-number' name='card-number'
         autocomplete='cc-number'>
  <button type='submit'>Place Order</button>
</form>

Sessão de checkout com aviso vago — Correto

<!-- The warning now states the exact duration so users can
     make an informed decision about when to begin the checkout. -->
<p class='notice'>
  For your security, your checkout session will expire after
  <strong>20 minutes of inactivity</strong>. Any payment information
  entered will need to be re-entered if the session expires.
</p>
<form action='/checkout' method='post'>
  <label for='card-number'>Card Number</label>
  <input type='text' id='card-number' name='card-number'
         autocomplete='cc-number'>
  <button type='submit'>Place Order</button>
</form>

Dados preservados no servidor por mais de 20 horas — Correto (exceção se aplica)

<!-- When all form data is saved to the server continuously
     and preserved for at least 20 hours, no timeout warning
     is required by 2.2.6. This is the ideal UX pattern:
     autosave is indicated to the user for transparency. -->
<main>
  <h1>Job Application</h1>
  <p>
    Your progress is automatically saved as you type.
    You can leave and return to this form at any time within
    <strong>30 days</strong> and your answers will be preserved.
  </p>
  <form action='/apply' method='post'>
    <label for='cover-letter'>Cover Letter</label>
    <textarea id='cover-letter' name='cover-letter'></textarea>
    <p aria-live='polite' id='autosave-status'>Draft saved.</p>
    <button type='submit'>Submit Application</button>
  </form>
</main>

Erros Comuns

• Exibir o aviso de timeout apenas dentro do console do navegador ou em um registro de servidor que é invisível para usuários finais — o aviso deve ser apresentado na interface do usuário, em um local que o usuário encontrará antes que a perda de dados ocorra.
• Colocar a divulgação em um rodapé, política de privacidade ou página de termos de serviço que os usuários provavelmente não lerão antes de começar a inserir dados, em vez de diretamente no formulário ou imediatamente antes dele.
• Usar uma caixa modal para avisar os usuários sobre uma expiração iminente de sessão, mas não mover o foco do teclado para a caixa — usuários de teclado e leitores de tela podem nunca perceber que o aviso apareceu.
• Declarar a duração de uma sessão (por exemplo, "sua sessão dura 30 minutos") em vez de um timeout de inatividade (por exemplo, "após 15 minutos de inatividade, seus dados serão perdidos") — são conceitos diferentes, e apenas a perda de dados acionada por inatividade é regida por 2.2.6.
• Presumir que, porque existe uma modal de aviso de timeout para usuários videntes, o critério está satisfeito — se a modal não for acessível via teclado, não tiver um nome acessível ou não for anunciada por regiões ARIA live ou gerenciamento de foco, usuários de leitores de tela não receberão o aviso.
• Definir o timeout de sessão do lado do servidor para 25 horas e concluir que nenhuma divulgação é necessária, sem verificar se o estado do lado do navegador ou da aplicação (por exemplo, um store do Redux ou localStorage) é apagado antes — o timeout efetivo é o do mecanismo que perde dados primeiro.
• Divulgar a duração do timeout em uma dica de ferramenta acionada apenas por hover — usuários que dependem de navegação por teclado ou dispositivos de toque podem nunca ver a divulgação.
• Confiar em um aviso genérico de CMS ou framework que diz "sessão expirada" exibido depois que a perda de dados já ocorreu, em vez de informar proativamente os usuários antes de começarem a inserir dados.
• Não levar em conta usuários que abrem o formulário em uma aba em segundo plano: se o temporizador de sessão continua enquanto a aba está inativa, os dados podem ser perdidos antes que o usuário tenha qualquer oportunidade de interagir com o formulário. Isso é especialmente problemático em navegadores móveis que suspendem abas em segundo plano de forma agressiva.
• Omitir o aviso em versões móveis ou em contextos de progressive web app (PWA) enquanto o exibe na versão desktop, criando uma experiência inconsistente que falha em 2.2.6 para uma parcela significativa de usuários.

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 obrigações vinculativas de acessibilidade web para uma ampla gama de entidades públicas e privadas que operam na Turquia. A circular determina a conformidade com WCAG 2.2 como padrão técnico, exigindo que as entidades abrangidas atendam, no mínimo, à conformidade de Nível AA. WCAG 2.2.6 Timeouts é um critério de Nível AAA e, portanto, não é diretamente exigido pelos requisitos básicos da circular. No entanto, o escopo e a intenção da circular criam fortes razões práticas para que as entidades abrangidas busquem a conformidade AAA em critérios como 2.2.6.

As entidades abrangidas pela Circular Presidencial 2025/10 incluem instituições e agências públicas, plataformas de e-commerce, bancos e instituições financeiras, hospitais e prestadores de serviços de saúde, operadoras de telecomunicações com mais de 200.000 assinantes, agências de viagens, empresas de transporte privado e escolas privadas autorizadas pelo Ministério da Educação Nacional (MoNE). Muitos desses setores operam portais online que envolvem exatamente os tipos de fluxos de entrada de dados que 2.2.6 foi projetado para proteger: solicitações de empréstimo, formulários de admissão de pacientes, sistemas de reserva de passagens, formulários de matrícula e pedidos de benefícios governamentais.

Para bancos e plataformas de e-commerce em particular, timeouts de sessão são uma medida de segurança rotineira, e a interação entre requisitos de segurança e obrigações de acessibilidade é diretamente relevante. Embora um banco possa ter uma obrigação regulatória de encerrar sessões ociosas após um período fixo, implementar WCAG 2.2.6 divulgando a duração do timeout antecipadamente não entra em conflito com esse requisito de segurança — pelo contrário, o complementa. Os usuários são informados sobre a restrição sem que o banco precise enfraquecer sua postura de segurança de sessão.

Prestadores de serviços de saúde e hospitais abrangidos pela circular lidam com algumas das tarefas de entrada de dados de maior risco imagináveis — formulários de histórico de pacientes, solicitações de pré-autorização e sistemas de agendamento de consultas. Pacientes com deficiências cognitivas ou motoras que perdem seus dados no meio de um formulário nesses contextos enfrentam não apenas frustração, mas possível atraso no recebimento de cuidados. Implementar 2.2.6 nesses ambientes é uma expressão direta do mandato de serviço inclusivo que sustenta a circular.

Embora o Nível AAA não seja legalmente exigido, alcançá-lo em critérios como 2.2.6 — que exigem um esforço de implementação relativamente baixo (adicionar uma única declaração de divulgação precisa a um formulário) enquanto oferecem benefícios significativos a grupos de usuários vulneráveis — representa uma prática de acessibilidade de classe mundial. Organizações que buscam demonstrar seu compromisso com a inclusão digital no mercado turco, ou aquelas que antecipam uma regulamentação mais rígida no futuro, se beneficiam ao tratar 2.2.6 como uma meta prática de implementação, e não como uma aspiração opcional.