WCAG 2.2.5: Reautenticação

O Que Esta Regra Significa

WCAG 2.2.5 Re-autenticação pertence à Diretriz 2.2 (Tempo Suficiente) e é um requisito de Nível AAA. O critério afirma: "Quando uma sessão autenticada expira, o usuário pode continuar a atividade sem perda de dados após se re-autenticar." Em termos práticos, isso significa que, se um usuário estiver no meio de preencher um formulário, concluir uma compra, redigir uma mensagem ou realizar qualquer tarefa em múltiplas etapas em uma plataforma autenticada e sua sessão expirar, ele deve conseguir fazer login novamente e retomar exatamente de onde parou — com todos os dados inseridos anteriormente preservados.

Este critério está intimamente relacionado a WCAG 2.2.1 (Tempo Ajustável, Nível A) e 2.2.4 (Interrupções, Nível AAA), mas aborda um cenário específico: o momento em que um limite de sessão é cruzado. Enquanto 2.2.1 exige que você dê tempo suficiente aos usuários ou permita que eles estendam sua sessão, 2.2.5 trata do caso de falha — o que acontece depois que o tempo se esgota. Os dois trabalham em conjunto: idealmente você tanto estende a sessão quanto preserva os dados se ela de fato expirar.

Um acerto sob este critério exige que a plataforma preserve todos os dados inseridos pelo usuário — entradas de texto, opções selecionadas, anexos de arquivos, caixas de seleção, botões de opção e qualquer outro estado de formulário — durante um evento de re-autenticação. Após o usuário fazer login novamente, ele deve ser devolvido ao mesmo ponto da atividade que estava realizando, com seus dados intactos e a tarefa concluível sem repetição.

Uma falha ocorre quando um tempo limite de sessão causa qualquer um dos seguintes: o usuário é redirecionado para uma página de login e, após o login bem-sucedido, é enviado para a página inicial em vez da página em que estava; os dados do formulário inseridos antes do tempo limite são perdidos e o usuário precisa inserir tudo novamente; o estado parcialmente concluído de um assistente em múltiplas etapas é redefinido; ou o usuário é simplesmente desconectado sem nenhum mecanismo para se re-autenticar e retomar.

A especificação oficial da WCAG não define uma duração mínima de sessão para este critério — ele se aplica independentemente de quão longo ou curto seja o período de tempo limite. No entanto, observe que nenhuma exceção é fornecida para perda de dados devido a preocupações de segurança; a expectativa é que as implementações encontrem maneiras seguras de preservar o estado, como armazenamento de sessão no servidor associado à identidade do usuário, ou tokens criptografados no lado do cliente que sobrevivam ao fluxo de re-autenticação.

Por Que Isso Importa

Tempos limite de sessão que apagam dados criam um ônus desproporcionalmente severo para pessoas com deficiência. Muitos usuários com deficiência precisam de significativamente mais tempo para concluir tarefas digitais do que seus pares sem deficiência, e muitas vezes não podem simplesmente "digitar mais rápido" ou "contornar" um tempo limite arbitrário.

Usuários que são cegos ou têm baixa visão navegam em formulários usando leitores de tela, o que é inerentemente mais lento do que a varredura visual. Uma pessoa cega preenchendo um longo formulário de sinistro de seguro pode gastar 20 ou 30 minutos navegando cuidadosamente campo a campo, apenas para ter seu trabalho apagado quando um tempo limite de sessão de 15 minutos é acionado. Ela então precisa começar novamente — sem garantia de que a mesma coisa não acontecerá uma segunda vez.

Pessoas com deficiências motoras — como aquelas que usam dispositivos de acesso por varredura, tecnologia de rastreamento ocular ou ponteiras bucais — podem levar várias vezes mais tempo do que a média para inserir texto e navegar em formulários. Um usuário com ELA ou atrofia muscular espinhal pode estar preenchendo um formulário de encaminhamento médico crítico e digitando apenas alguns caracteres por minuto. Tempos limite de sessão que destroem seu trabalho não são um pequeno inconveniente; podem ser uma barreira completa para concluir tarefas essenciais.

Usuários com deficiências cognitivas, incluindo aqueles com dislexia, TDAH, lesões cerebrais traumáticas ou demência, podem precisar reler instruções várias vezes, fazer pausas para processar informações ou simplesmente avançar mais lentamente por processos em múltiplas etapas. Pesquisas mostram consistentemente que essa população é desproporcionalmente afetada por pressão de tempo e perda de dados — ambos se somam à carga cognitiva de tentar recomeçar do zero.

Considere um cenário concreto do mundo real: uma pessoa com esclerose múltipla está solicitando um benefício de invalidez do governo por meio do portal web de uma instituição pública. A solicitação tem 8 etapas e exige o envio de documentos médicos, o preenchimento de histórico de emprego e a redação de uma declaração pessoal. Ela chega à etapa 6 em 45 minutos, a sessão expira e todos os dados inseridos são perdidos. Agora precisa reunir os mesmos documentos novamente e repetir todo o processo, podendo acabar abandonando a solicitação por completo. Isso não é hipotético — é um padrão documentado repetidamente em pesquisas de acessibilidade e testes com usuários.

Além da deficiência, a perda de dados em tempo limite de sessão afeta todos os usuários e tem impactos de negócio mensuráveis: carrinhos de compra abandonados, registros incompletos e leads perdidos. Preservar o estado da sessão é tanto um imperativo de acessibilidade quanto uma prática sólida de UX e otimização de conversão. De acordo com o Baymard Institute, o abandono de formulários é um grande contribuinte para as taxas de abandono de carrinho no e-commerce, e a perda inesperada de dados é um dos principais motivos citados para usuários não concluírem compras online.

Regras Relacionadas do Axe-core

WCAG 2.2.5 exige apenas testes manuais. Não há regras automatizadas do axe-core que possam detectar de forma confiável violações deste critério. O seguinte explica por que ferramentas automatizadas falham e o que testadores humanos devem fazer em vez disso:

• Não existe regra automatizada para preservação de estado de sessão: Axe-core e mecanismos de acessibilidade automatizados semelhantes operam inspecionando o DOM atual e avaliando condições estáticas ou quase estáticas, como proporções de contraste de cor, correção de atributos ARIA e texto alternativo ausente. Eles não podem simular a passagem do tempo, acionar um evento de expiração de sessão, enviar credenciais de re-autenticação e então verificar se os dados inseridos anteriormente foram restaurados. Toda essa sequência é um comportamento com estado e dependente de tempo que exige uma pessoa (ou um teste de ponta a ponta roteirizado) para observar.
• Detecção de tempo limite de sessão está fora do escopo da análise estática: Mesmo que uma ferramenta automatizada pudesse detectar que uma página implementa um tempo limite de sessão (por exemplo, lendo uma meta tag de atualização ou uma chamada JavaScript setTimeout), ela não pode avaliar o que acontece com os dados do usuário depois que o tempo limite é acionado. O comportamento de preservação de dados reside na lógica de gerenciamento de sessão no servidor, não na estrutura do DOM que as ferramentas automatizadas analisam.
• Complexidade do fluxo de re-autenticação: A experiência de re-autenticação pode envolver várias páginas (formulário de login, prompt de MFA, redirecionamento), e a restauração de estado pode depender de lógica no servidor, cookies, armazenamento local ou parâmetros de URL. Nenhuma ferramenta de inspeção de DOM de página única consegue rastrear esse fluxo de múltiplas páginas e múltiplos sistemas.
• Por que o teste manual é essencial: Um testador qualificado deve iniciar manualmente um fluxo autenticado, deliberadamente esperar ou acionar a expiração da sessão, concluir o processo de re-autenticação e então verificar a integridade dos dados. Este é o único método confiável para testar conformidade. Varreduras automatizadas podem ser usadas como ponto de partida para sinalizar problemas relacionados (como mecanismos de aviso de sessão ausentes cobertos em 2.2.1), mas não podem substituir o teste manual para 2.2.5.

Como Testar

1. Identifique fluxos autenticados com formulários ou processos em múltiplas etapas. Comece mapeando todas as áreas do site que exigem autenticação e envolvem entrada de dados pelo usuário — fluxos de checkout, editores de perfil, formulários de solicitação, sistemas de reserva, interfaces de mensagens e painéis administrativos. Estas são as áreas de maior risco para falhas em 2.2.5.
2. Determine a duração do tempo limite de sessão. Verifique a configuração do servidor, as configurações da aplicação ou consulte a equipe de desenvolvimento para descobrir quando as sessões expiram. Alternativamente, inicie uma sessão e espere até ser desconectado automaticamente. Anote a duração. Tempos limite comuns variam de 15 minutos a 2 horas.
3. Inicie uma tarefa e insira dados substanciais. Faça login e comece a preencher um formulário representativo — por exemplo, um fluxo de registro ou compra com vários campos. Insira texto em campos de texto, faça seleções e avance por quaisquer etapas de assistente. Não envie o formulário.
4. Acione a expiração da sessão. Espere o tempo limite natural ocorrer ou — se você tiver acesso de desenvolvedor — expire artificialmente a sessão invalidando o cookie de sessão nas ferramentas de desenvolvedor do navegador (aba Application > Cookies > excluir o cookie de sessão) ou expirando a sessão diretamente no servidor.
5. Observe o prompt de re-autenticação. Verifique se o site solicita que você se re-autentique (acerto) ou simplesmente redireciona para uma página de login sem aviso (um problema de usabilidade relacionado, embora 2.2.5 se concentre na preservação de dados, não no aviso em si). Tente fazer login novamente.
6. Verifique a preservação de dados após o login. Após se re-autenticar com sucesso, observe para onde você é redirecionado e se seus dados inseridos anteriormente estão intactos. Se você for enviado para a página inicial e/ou seus dados de formulário tiverem sumido, isso é uma falha de 2.2.5.
7. Teste com tecnologias assistivas. Repita a sequência de teste acima usando NVDA com Firefox, JAWS com Chrome e VoiceOver com Safari para garantir que o prompt de re-autenticação seja acessível a usuários de leitores de tela e que o estado restaurado da página seja anunciado corretamente. Um usuário vidente pode reconhecer visualmente os dados restaurados; um usuário de leitor de tela precisa que o foco seja colocado corretamente e que o conteúdo restaurado esteja na ordem de leitura.
8. Teste navegação apenas por teclado. Garanta que todo o processo de re-autenticação — desde o aviso de expiração de sessão até o login novamente e o retorno à tarefa preservada — possa ser concluído usando apenas o teclado, sem exigir mouse.
9. Teste com simulações de tempo limite estendido. Se possível, reduza o tempo limite de sessão para 1–2 minutos em um ambiente de desenvolvimento e execute testes de jornada completa do usuário para tornar o ciclo de teste mais rápido e repetível.

Como Corrigir

Formulário de Login Simples com Tempo Limite de Sessão — Incorreto

<!-- BAD: Session expires silently. On re-login, user is sent to homepage.
     All entered data in the checkout form is lost. -->
<form action='/checkout' method='POST' id='checkout-form'>
  <input type='text' name='full_name' placeholder='Full Name' />
  <input type='text' name='address' placeholder='Address' />
  <button type='submit'>Place Order</button>
</form>

<!-- Server-side: session expires after 10 minutes of inactivity.
     No state saved. POST redirect on login goes to /dashboard. -->

Formulário de Login Simples com Tempo Limite de Sessão — Correto

<!-- GOOD: Before session expires, form state is saved server-side
     (or to sessionStorage as a fallback). After re-auth, the user
     is redirected back to the checkout page with data restored. -->

<!-- 1. JavaScript saves form state periodically to the server -->
<script>
  function saveFormState() {
    const formData = new FormData(document.getElementById('checkout-form'));
    const data = Object.fromEntries(formData.entries());
    // Save to server-side session keyed to authenticated user identity
    fetch('/api/save-draft', {
      method: 'POST',
      headers: { 'Content-Type': 'application/json' },
      body: JSON.stringify({ formId: 'checkout', data })
    });
  }
  // Auto-save every 60 seconds and on input change
  setInterval(saveFormState, 60000);
  document.getElementById('checkout-form')
    .addEventListener('input', saveFormState);
</script>

<!-- 2. On the server: when user re-authenticates,
     redirect to /checkout?restore=true
     which reloads saved draft data into the form -->
<form action='/checkout' method='POST' id='checkout-form'>
  <!-- Form fields are pre-populated from saved draft -->
  <input type='text' name='full_name' value='[restored value]'
         aria-label='Full Name' />
  <input type='text' name='address' value='[restored value]'
         aria-label='Address' />
  <button type='submit'>Place Order</button>
</form>

Assistente em Múltiplas Etapas Perdendo Progresso — Incorreto

<!-- BAD: Multi-step form uses only client-side state.
     Session expiry wipes wizard progress completely.
     Re-login sends user to step 1 with no data. -->

<div id='wizard'>
  <div class='step active' id='step-3'>
    <h2>Step 3 of 5: Employment History</h2>
    <textarea name='employment_history'>Typed content here...</textarea>
  </div>
</div>

<script>
  // State is only in JavaScript variables — lost on session expiry
  let wizardState = { step: 3, data: {} };
</script>

Assistente em Múltiplas Etapas Perdendo Progresso — Correto

<!-- GOOD: Wizard state is persisted server-side at each step
     and linked to the user's account. On re-authentication,
     the server restores the user to their last saved step
     with all data intact. A visible confirmation is shown. -->

<div id='wizard'>
  <div class='step active' id='step-3'
       aria-live='polite' aria-label='Step 3 of 5: Employment History'>
    <p role='status'>
      Your progress has been restored from your last session.
    </p>
    <h2>Step 3 of 5: Employment History</h2>
    <!-- Data is pre-populated from server-side draft -->
    <textarea name='employment_history'
              aria-label='Describe your employment history'>
      Previously entered content restored here...
    </textarea>
    <!-- Wizard nav saves progress before moving to next step -->
    <button type='button' onclick='saveAndProceed()'>Next Step</button>
  </div>
</div>

<script>
  async function saveAndProceed() {
    await fetch('/api/wizard/save', {
      method: 'POST',
      body: JSON.stringify({ step: 3, data: collectStepData() }),
      headers: { 'Content-Type': 'application/json' }
    });
    goToStep(4);
  }
</script>

Aviso de Expiração de Sessão Sem Preservação de Dados — Incorreto

<!-- BAD: Site shows a countdown warning but does not save data.
     If the user misses the warning (e.g., screen reader user
     focused elsewhere), they lose all their work. -->
<div id='timeout-warning' style='display:none'>
  <p>Your session will expire in 2 minutes. <a href='/extend'>Extend</a></p>
</div>

Aviso de Expiração de Sessão Sem Preservação de Dados — Correto

<!-- GOOD: Warning uses aria-live so screen readers announce it.
     Data is saved server-side regardless of whether the user
     extends the session — so re-auth always restores state. -->
<div id='timeout-warning'
     role='alertdialog'
     aria-live='assertive'
     aria-labelledby='warning-title'
     aria-describedby='warning-desc'
     hidden>
  <h2 id='warning-title'>Session Expiring Soon</h2>
  <p id='warning-desc'>
    Your session will expire in 2 minutes. Your work has been
    saved automatically. You can extend your session or log in
    again to continue exactly where you left off.
  </p>
  <button onclick='extendSession()'>Extend Session</button>
  <button onclick='dismissWarning()'>Dismiss</button>
</div>

Erros Comuns

• Redirecionar para a página inicial após a re-autenticação em vez da página original: O padrão de falha mais comum. Após o login, a aplicação envia o usuário para /dashboard ou / em vez da URL em que ele estava quando a sessão expirou, forçando-o a voltar manualmente à sua tarefa — e seus dados já se foram.
• Armazenar o estado do formulário apenas na memória JavaScript ou no estado de componentes React/Vue: O estado de framework no lado do cliente não sobrevive a um recarregamento de página acionado por um redirecionamento de tempo limite de sessão para a página de login. O estado deve ser persistido no servidor ou em um mecanismo de armazenamento (por exemplo, localStorage) que seja restaurado de forma confiável ao retornar.
• Salvar uma "URL de retorno" mas não os dados do formulário: Algumas implementações armazenam a URL para redirecionar de volta após o login, mas não salvam os valores reais dos campos do formulário. O usuário chega à página correta, mas com campos vazios, o que ainda viola 2.2.5.
• Auto-salvar em sessionStorage, que é limpo quando a aba é fechada: Se a expiração da sessão fizer com que a aba do navegador navegue para outro lugar (por exemplo, redirecionar para login), sessionStorage é limpo. Use localStorage com um namespace associado ao usuário ou, de preferência, armazenamento de rascunho no servidor.
• Não testar com campos de upload de arquivo: Entradas de arquivo não podem ser pré-preenchidas por HTML por motivos de segurança. Se um formulário incluir um upload de arquivo que foi concluído antes da expiração da sessão, a referência ao arquivo é perdida. As aplicações devem lidar com isso armazenando referências a arquivos enviados no servidor e mostrando ao usuário que seu arquivo ainda está anexado.
• Limpar dados de rascunho salvos imediatamente na re-autenticação: Algumas implementações excluem o rascunho assim que o usuário faz login, antes de verificar se ele realmente viu e confirmou os dados restaurados. O rascunho deve ser preservado até que a tarefa seja explicitamente concluída ou cancelada.
• Não anunciar dados restaurados para usuários de leitores de tela: Após a re-autenticação e o redirecionamento, usuários de leitores de tela precisam de uma região aria-live ou de um anúncio focado confirmando que seus dados foram restaurados e que podem continuar de onde pararam. Sem isso, eles podem não saber que seu trabalho foi salvo.
• Tratar sessões baseadas em AJAX de forma diferente de sessões baseadas em página: Aplicações de página única que usam autenticação baseada em token (por exemplo, expiração de JWT) frequentemente falham silenciosamente em chamadas de API quando o token expira, sem dar ao usuário a chance de se re-autenticar e retomar. O mecanismo de re-autenticação deve ser igualmente robusto para arquiteturas SPA.
• Usar <meta http-equiv='refresh'> para forçar logout sem salvamento prévio de dados: Um meta refresh que dispara no tempo limite redireciona imediatamente o usuário sem qualquer preservação de estado no servidor, tornando a recuperação de dados impossível. O gerenciamento de sessão deve ser tratado na camada de aplicação com a devida persistência de estado.
• Presumir que sessões curtas eliminam a necessidade deste critério: Mesmo um tempo limite de sessão de 5 minutos pode pegar um digitador lento, um usuário com deficiência cognitiva relendo instruções ou alguém interrompido por um cuidador. A duração do tempo limite não altera a obrigação de preservar dados durante a re-autenticação.

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 o quadro nacional para acessibilidade digital e faz referência à WCAG 2.2 como sua base de padrão técnico. A circular exige conformidade para uma ampla gama de entidades que operam na Turquia, incluindo instituições e agências públicas, plataformas de e-commerce, bancos e prestadores de serviços financeiros, hospitais e prestadores de serviços de saúde privados, empresas de telecomunicações com 200.000 ou mais assinantes, agências de viagem, empresas de transporte privado e instituições de ensino privadas autorizadas pelo Ministério da Educação Nacional (MoNE).

WCAG 2.2.5 Re-autenticação é um critério de Nível AAA, o que significa que não está entre os requisitos mínimos legalmente obrigatórios sob a Circular (que visa conformidade de Nível A e AA). No entanto, organizações que buscam demonstrar liderança em acessibilidade, atender populações de usuários diversas, incluindo pessoas com deficiência, ou se posicionar como prestadoras de serviços digitais de excelência devem tratar critérios de Nível AAA — especialmente aqueles tão impactantes na prática quanto 2.2.5 — como metas aspiracionais que valem a pena perseguir.

Certas categorias de entidades abrangidas têm motivos particularmente fortes para implementar 2.2.5. Bancos e plataformas financeiras frequentemente exigem que usuários preencham longos formulários para solicitações de empréstimo, abertura de conta ou produtos de investimento, e seus tempos de sessão curtos motivados por segurança criam uma tensão direta com as obrigações de preservação de dados. Hospitais e portais de saúde expõem pacientes à perda de dados durante tarefas críticas como agendamento de consultas ou preenchimento de questionários de saúde, o que pode ter consequências reais para a continuidade do cuidado. Instituições públicas que operam serviços de governo eletrônico — como declaração de impostos, solicitações de licenças ou pedidos de benefícios — atendem cidadãos com deficiência que podem precisar de tempo estendido para concluir formulários governamentais complexos.

Mesmo onde a conformidade de Nível AAA não é legalmente exigida, organizações turcas devem estar cientes de que reguladores, organizações da sociedade civil e defensores dos direitos das pessoas com deficiência estão examinando cada vez mais a qualidade e a completude das implementações de acessibilidade digital. Documentar a conformidade com critérios de Nível AAA como 2.2.5 fortalece a declaração de acessibilidade de uma organização, reduz o risco de litígios e demonstra um compromisso genuíno com design inclusivo além do cumprimento mínimo de requisitos. Para entidades com alcance internacional, particularmente aquelas que operam em mercados da UE juntamente com a Turquia, critérios de Nível AAA podem se cruzar com requisitos sob o Ato Europeu de Acessibilidade (EAA) e implementações nacionais relacionadas.