WCAG 3.2.2: Ao Inserir

O que Esta Regra Significa

WCAG 3.2.2 On Input faz parte do princípio Compreensível e se enquadra na Diretriz 3.2 Previsível. Ela estabelece que alterar a configuração de qualquer componente da interface do usuário não deve causar automaticamente uma mudança de contexto, a menos que o usuário tenha sido informado antecipadamente de que tal comportamento ocorrerá.

Uma mudança de contexto é uma alteração importante no conteúdo de uma página da web que pode desorientar usuários que não conseguem ver a página inteira de uma vez. De acordo com a especificação WCAG, mudanças de contexto incluem: mudanças de agente do usuário (navegador), mudanças de viewport, mudanças de foco e mudanças de conteúdo que alteram significativamente o significado da página. Enviar um formulário, abrir uma nova janela ou navegar para outra página são todos exemplos de mudanças de contexto. Simplesmente revelar conteúdo adicional, como em um acordeão expansível, não é.

O critério se aplica especificamente a alterar a configuração de um componente de UI — por exemplo, selecionar um botão de opção (radio), marcar uma caixa de seleção ou escolher uma opção em um dropdown <select> — em oposição a ativar um controle (como clicar em um botão). Se uma ação exige uma etapa explícita de ativação (pressionar Enter, clicar em Enviar), geralmente ela não se enquadra neste critério. O padrão problemático é quando o simples ato de selecionar um valor aciona instantaneamente a navegação ou um recarregamento significativo da página sem qualquer aviso.

O que conta como aprovação: Um formulário que usa um botão de envio para processar as seleções do usuário, mesmo que essas seleções incluam dropdowns ou caixas de seleção, atende a este critério. Um dropdown que filtra resultados na mesma página sem recarregar ou deslocar o foco de forma significativa é aprovado. Uma página que avisa os usuários antecipadamente — por exemplo, com uma nota visível como "Selecionar um idioma recarregará a página" — de que uma determinada entrada acionará uma mudança de contexto também é aprovada.

O que conta como reprovação: Um seletor de país ou idioma que redireciona automaticamente o usuário para uma nova URL no momento em que uma opção é escolhida reprova. Um formulário que é enviado automaticamente e navega para longe quando um botão de opção é selecionado, sem qualquer botão de envio, reprova. Um widget de preenchimento automático que desloca o foco do teclado para uma nova região da página sem aviso após a seleção também reprova.

Exceções oficiais: A especificação WCAG observa que, se o usuário for avisado sobre o comportamento antes de usar o componente, a mudança automática de contexto é aceitável. Esse aviso deve estar presente antes de a interação ocorrer, não depois.

Por Que Isso Importa

Mudanças inesperadas de contexto são uma das experiências mais desorientadoras na web, e o impacto é amplificado de forma dramática para usuários com deficiência. Quando uma página de repente navega, recarrega ou desloca o foco sem aviso, usuários que não conseguem ver todo o layout visual da página perdem completamente sua orientação.

Usuários de leitores de tela são especialmente vulneráveis. Quando uma pessoa cega usando NVDA ou JAWS seleciona uma opção em um dropdown e a página imediatamente recarrega ou navega, o leitor de tela anuncia o novo contexto da página do zero. A pessoa perde a noção de onde estava, o que estava fazendo e precisa navegar novamente por toda a página para se situar. Isso não é um pequeno inconveniente — pode tornar a tarefa completamente impossível de ser concluída de forma independente.

Usuários que utilizam apenas o teclado, incluindo pessoas com deficiências motoras que não podem usar o mouse, enfrentam um problema semelhante. Elas podem estar navegando em um formulário usando Tab e teclas de seta e acionar acidentalmente uma mudança de contexto que não pretendiam. Sem controle motor fino, recuperar-se de uma navegação de página não intencional pode exigir um esforço significativo.

Deficiências cognitivas agravam ainda mais o problema. Usuários com transtornos de atenção, dificuldades de aprendizagem ou comprometimentos de memória dependem de interfaces previsíveis e estáveis para entender o que está acontecendo. Mudanças súbitas de contexto quebram o modelo mental que construíram durante a sessão, muitas vezes forçando-os a recomeçar ou abandonar a tarefa.

Usuários com distúrbios vestibulares podem sentir desconforto físico ou desorientação quando as páginas mudam inesperadamente, especialmente se a mudança envolver animação ou deslocamentos de posição de rolagem.

Um cenário concreto do mundo real: considere uma página de checkout de e-commerce na Turquia em que um usuário seleciona sua província em um dropdown. Se essa seleção recarregar a página instantaneamente para atualizar as opções de envio, um usuário de leitor de tela pode de repente se ver no topo da página sem qualquer indicação do que aconteceu. Ele teria que navegar novamente por todos os campos do formulário para encontrar onde estava, sem saber se suas entradas anteriores foram preservadas. Esse tipo de fricção pode levar usuários a abandonar a compra completamente.

Do ponto de vista de usabilidade e SEO, páginas que se comportam de forma previsível têm taxas de rejeição mais baixas. Os usuários são menos propensos a sair frustrados, e os rastreadores de mecanismos de busca podem indexar o conteúdo de forma mais confiável, sem redirecionamentos inesperados interferindo nos caminhos de rastreamento.

Regras Relacionadas do Axe-core

WCAG 3.2.2 On Input exige testes manuais. Ferramentas automatizadas como axe-core não conseguem detectar de forma confiável violações deste critério porque o comportamento problemático é contextual e depende da intenção por trás de uma interação, não simplesmente da presença ou ausência de um atributo ou estrutura HTML específica. Uma ferramenta pode identificar que um elemento <select> tem um manipulador de evento onchange, mas não pode determinar se esse manipulador aciona uma mudança de contexto, se o usuário foi avisado sobre isso ou se o comportamento resultante é desorientador na prática.

• Teste manual necessário — Padrões de navegação com onchange: Varreduras automatizadas podem sinalizar elementos <select>, <input type='radio'> e <input type='checkbox'> que têm manipuladores de eventos JavaScript (particularmente onchange), mas não podem determinar se esses manipuladores causam uma mudança de contexto. Um testador humano deve interagir com cada controle e observar se a página navega, recarrega, desloca o foco para uma região dramaticamente diferente ou abre uma nova janela sem uma etapa explícita de ativação por parte do usuário.
• Teste manual necessário — Presença e adequação do aviso prévio: Mesmo que uma mudança de contexto seja detectada, uma ferramenta automatizada não pode determinar se o usuário foi adequadamente avisado sobre ela antes de interagir com o controle. Uma pessoa deve verificar se qualquer aviso prévio é visível antes de o componente ser encontrado, se está claramente redigido e se de fato descreve o comportamento que ocorrerá.
• Teste manual necessário — Gerenciamento de foco após a entrada: Algumas violações se manifestam como o foco sendo movido para um local inesperado após a mudança de entrada, em vez de uma navegação explícita. Ferramentas automatizadas não conseguem rastrear de forma confiável os destinos de foco acionados por eventos onchange e confirmar se o posicionamento resultante do foco constitui uma mudança de contexto desorientadora.

Como Testar

1. Base de varredura automatizada: Execute axe DevTools ou Lighthouse na página para identificar quaisquer problemas sinalizados sob WCAG 3.2. Embora o 3.2.2 em si exija testes manuais, o axe pode apontar problemas relacionados (como rótulos ausentes ou problemas de gerenciamento de foco) que fornecem um ponto de partida. Anote todos os controles de formulário — especialmente dropdowns <select>, grupos de botões de opção e caixas de seleção — para acompanhamento manual.
2. Identifique todos os controles de entrada com manipuladores de mudança: Nas DevTools do navegador, inspecione o JavaScript da página ou use o painel de Event Listeners para identificar qualquer <select>, <input type='radio'>, <input type='checkbox'> ou widget personalizado que tenha um listener de evento onchange, oninput ou equivalente anexado.
3. Teste manual de interação via teclado: Usando apenas o teclado (Tab para navegar, teclas de seta para opções de radio/select), interaja com cada controle identificado. Observe se selecionar uma opção faz com que a página navegue, recarregue, abra uma nova janela ou mova o foco para uma parte significativamente diferente da página. Se sim, confirme se um aviso visível foi exibido antes de o controle ser encontrado.
4. Teste com NVDA + Firefox: Inicie o Firefox com o NVDA ativo. Navegue até cada controle de formulário usando o cursor virtual do NVDA (teclas de seta) e depois interaja usando o modo de formulários (Enter ou Espaço). Selecione opções em dropdowns e grupos de botões de opção e ouça quaisquer anúncios inesperados indicando um carregamento de página, navegação ou grande mudança de contexto. Observe se o NVDA lê um novo título de página ou uma região dramaticamente diferente.
5. Teste com VoiceOver + Safari (macOS/iOS): Ative o VoiceOver e navegue até cada controle usando VO+seta para a direita. Interaja com dropdowns e caixas de seleção. Se ocorrer uma mudança de contexto, o VoiceOver normalmente anunciará a nova página ou o deslocamento de foco. Determine se o usuário foi avisado previamente.
6. Teste com JAWS + Chrome: Use o JAWS no modo de cursor virtual para navegar pela página. Interaja com controles de formulário e monitore se o JAWS anuncia uma mudança de contexto (mudança de título da página, nova URL, posição de leitura deslocada) imediatamente após a entrada — sem que um botão de envio seja ativado.
7. Teste de observação visual: Para usuários videntes sem tecnologia assistiva, selecione opções em cada dropdown e grupo de botões de opção e observe se a página navega ou recarrega inesperadamente. Se isso acontecer, verifique se algum texto instrucional visível antes do controle avisou sobre esse comportamento.

Como Corrigir

Dropdown select com envio automático — Incorreto

<!-- BAD: Selecting a country immediately redirects the page -->
<label for='country'>Select Country</label>
<select id='country' name='country' onchange='window.location.href="/region/" + this.value'>
  <option value='tr'>Turkey</option>
  <option value='de'>Germany</option>
  <option value='us'>United States</option>
</select>

Dropdown select com envio automático — Correto

<!-- GOOD: Selection is confirmed via a submit button; no automatic navigation -->
<form action='/region/' method='get'>
  <label for='country'>Select Country</label>
  <select id='country' name='country'>
    <option value='tr'>Turkey</option>
    <option value='de'>Germany</option>
    <option value='us'>United States</option>
  </select>
  <!-- Explicit submit button gives the user control over when navigation occurs -->
  <button type='submit'>Go</button>
</form>

Padrão de envio automático com botão de opção (radio) — Incorreto

<!-- BAD: Selecting a payment method immediately submits the form -->
<fieldset>
  <legend>Payment Method</legend>
  <label>
    <input type='radio' name='payment' value='card' onchange='this.form.submit()'>
    Credit Card
  </label>
  <label>
    <input type='radio' name='payment' value='bank' onchange='this.form.submit()'>
    Bank Transfer
  </label>
</fieldset>

Padrão de envio automático com botão de opção (radio) — Correto

<!-- GOOD: onchange can update UI state without navigating; submit requires user action -->
<fieldset>
  <legend>Payment Method</legend>
  <label>
    <input type='radio' name='payment' value='card' onchange='showPaymentDetails(this.value)'>
    Credit Card
  </label>
  <label>
    <input type='radio' name='payment' value='bank' onchange='showPaymentDetails(this.value)'>
    Bank Transfer
  </label>
</fieldset>
<!-- showPaymentDetails() reveals additional fields inline — no context change -->
<div id='payment-details' aria-live='polite'></div>
<button type='submit'>Confirm Payment</button>

Seletor de idioma com aviso prévio — Correto

<!-- ACCEPTABLE: User is warned before interacting that selecting will reload the page -->
<p id='lang-notice'>Selecting a language will immediately reload the page.</p>
<label for='lang-select'>Language</label>
<select
  id='lang-select'
  name='lang'
  aria-describedby='lang-notice'
  onchange='window.location.href="/" + this.value + "/"'
>
  <option value='en'>English</option>
  <option value='tr'>Türkçe</option>
  <option value='de'>Deutsch</option>
</select>
<!-- The aria-describedby links the warning to the control for screen reader users -->

Erros Comuns

• Anexar atribuições de window.location.href diretamente ao atributo onchange de um elemento <select> sem um botão de envio, causando navegação imediata da página no momento em que o usuário escolhe uma opção.
• Usar this.form.submit() dentro do manipulador onchange de um botão de opção, o que envia o formulário inteiro e navega para longe no instante em que uma opção de radio é selecionada — antes que o usuário possa revisar suas escolhas.
• Colocar o aviso prévio depois do controle no DOM, de modo que usuários de leitores de tela e navegadores por teclado encontrem o controle antes de ouvir ou ler o aviso sobre o comportamento que ele aciona.
• Exibir o aviso prévio apenas como um tooltip ou texto de placeholder que não é exposto de forma confiável às tecnologias assistivas, deixando usuários de leitores de tela sem qualquer indicação de que uma mudança de contexto seguirá sua entrada.
• Construir widgets de dropdown personalizados usando elementos <div> e <ul> que disparam navegação na seleção via JavaScript, mas carecem da estrutura semântica que permitiria a testadores ou overlays de acessibilidade identificá-los como controles interativos que exigem escrutínio sob o 3.2.2.
• Acionar o envio automático de um formulário no último campo (por exemplo, uma entrada de PIN ou OTP) quando o número necessário de caracteres é atingido, sem notificar o usuário de que isso acontecerá.
• Abrir uma caixa de diálogo modal ou uma nova janela do navegador em resposta a uma caixa de seleção marcada, sem qualquer aviso prévio — isso constitui uma mudança de contexto porque desloca significativamente o viewport e o foco do usuário.
• Confundir atualizações previsíveis de conteúdo na mesma página com mudanças de contexto e adicionar botões de envio desnecessários em torno de interações que já são aceitáveis (como um filtro de busca em tempo real), o que pode poluir a interface — as equipes devem entender que atualizações inline não desorientadoras não exigem uma etapa de envio.
• Confiar apenas em varreduras automatizadas de acessibilidade e marcar o 3.2.2 como aprovado porque nenhuma regra automatizada o sinalizou, sem realizar os testes manuais obrigatórios de teclado e leitor de tela que este critério exige.
• Aplicar um manipulador onchange que muda o contexto a um <select> usado para ordenação ou filtragem em uma lista de resultados, causando um recarregamento completo da página em vez de uma atualização via AJAX, e deixando de avisar os usuários de que esse recarregamento ocorrerá após a seleçã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 requisitos obrigatórios de acessibilidade na web com base na WCAG 2.2. WCAG 3.2.2 On Input é um critério de Nível A, que representa a linha de base mínima de conformidade sob a circular — o que significa que o cumprimento não é opcional, mas legalmente exigido para todas as entidades abrangidas.

A circular define um cronograma de implementação em dois níveis. Instituições públicas — incluindo ministérios, prefeituras, universidades públicas e órgãos governamentais — devem alcançar conformidade total de Nível A em um ano a partir da publicação da circular. Entidades do setor privado abrangidas pela regulamentação têm um prazo de dois anos para se adequar.

Os seguintes tipos de entidades são explicitamente abrangidos pela circular e, portanto, devem garantir que seus serviços digitais estejam em conformidade com a WCAG 3.2.2: plataformas de e-commerce, instituições públicas em todos os níveis de governo, bancos e instituições financeiras, hospitais e prestadores de serviços de saúde, empresas de telecomunicações com 200,000 ou mais assinantes, agências de viagens licenciadas, empresas de transporte privado e escolas privadas autorizadas pelo Ministério da Educação Nacional (MoNE).

Para essas entidades, uma violação da WCAG 3.2.2 — como um seletor de idioma em um portal bancário que redireciona automaticamente após a seleção, ou um formulário de agendamento de consultas de um hospital que é enviado automaticamente quando um botão de opção de departamento é escolhido — constitui uma não conformidade regulatória direta. Considerando que a Turquia tem uma população substancial de usuários com deficiência e que os serviços digitais do governo são cada vez mais o canal primário para que cidadãos acessem serviços públicos, as consequências práticas de ignorar este critério são significativas.

Organizações sujeitas à circular devem tratar os testes de WCAG 3.2.2 como uma etapa obrigatória de auditoria durante o QA. Como ferramentas automatizadas não conseguem detectar violações deste critério, testes manuais realizados por especialistas em acessibilidade treinados — cobrindo interação via teclado, comportamento de leitores de tela com NVDA e JAWS e revisão explícita de todas as interações acionadas por onchange — devem ser incorporados ao processo de conformidade. Documentar os resultados dos testes e quaisquer exceções aceitas (com avisos prévios em vigor) é recomendável para demonstrar diligência às autoridades regulatórias.