WCAG 3.3.7: Entrada Redundante

O Que Esta Regra Significa

WCAG 3.3.7 Redundant Entry é um critério de sucesso de Nível A introduzido no WCAG 2.2. Ele afirma: "Information previously entered by or provided to the user that is required to be entered again in the same process is either auto-populated or available for the user to select." Em termos simples, se um usuário já digitou seu endereço de e-mail, endereço de entrega, data de nascimento ou qualquer outra informação durante uma sessão, sua interface não deve obrigá-lo a digitá-la novamente dentro do mesmo processo ou fluxo.

O critério se aplica amplamente a qualquer formulário de múltiplas etapas, processo de checkout, assistente de registro, fluxo de agendamento de consultas ou sequência semelhante em que dados coletados em uma etapa possam ser necessários novamente em uma etapa posterior. Os comportamentos afetados incluem campos de texto, menus suspensos, caixas de seleção, botões de opção e qualquer outro controle de formulário que colete dados fornecidos pelo usuário. Quando a mesma informação é exigida novamente, ela deve ser ou pré-preenchida automaticamente usando o valor fornecido anteriormente, ou oferecida como uma opção selecionável para que o usuário possa confirmar em vez de digitá-la novamente.

Um acerto para este critério se parece com: um formulário de endereço de cobrança que é pré-preenchido com o endereço de entrega que o usuário inseriu na tela anterior, ou uma etapa de confirmação que exibe o endereço de e-mail inserido anteriormente pelo usuário em um campo somente leitura. Outro padrão que atende ao critério é uma caixa de seleção rotulada "Meu endereço de cobrança é o mesmo que meu endereço de entrega" que, quando marcada, copia os valores automaticamente. Um erro se parece com: um fluxo de registro em múltiplas etapas que pede um endereço de e-mail na etapa 1 e novamente na etapa 3 sem pré-preencher o segundo campo, ou um formulário de sinistro de seguro que pede o nome do requerente e o número da apólice em várias telas separadas sem nenhum preenchimento automático.

WCAG 3.3.7 define duas exceções oficiais. A primeira exceção se aplica quando reintroduzir a informação é essencial para o processo — por exemplo, um campo "Confirme sua nova senha" pede intencionalmente que os usuários digitem a mesma senha duas vezes como proteção contra erros de digitação, e isso é considerado uma verificação de segurança essencial. A segunda exceção se aplica quando a informação inserida anteriormente não é mais válida — por exemplo, se uma sessão expirou ou um produto ficou sem estoque e o usuário precisa reiniciar um processo com dados atualizados. Fora dessas exceções, entrada redundante é uma falha de conformidade.

Por Que Isso Importa

A entrada redundante sobrecarrega desproporcionalmente usuários cujas condições tornam a digitação lenta, dolorosa, propensa a erros ou cognitivamente exaustiva. Entender quem é afetado ajuda desenvolvedores e designers a perceberem por que este critério é mais do que um recurso de conveniência — ele é uma barreira real para muitas pessoas.

Usuários com deficiências motoras, como aqueles com tremores, lesões na medula espinhal ou condições como ELA ou esclerose múltipla, podem depender de acesso por varredura, ponteiras bucais, software de rastreamento ocular ou controle por voz para inserir texto. Para esses usuários, digitar até mesmo um endereço curto pode levar vários minutos e exigir esforço físico significativo. Ser obrigado a repetir essa entrada não é apenas irritante — pode causar dor física ou tornar a tarefa praticamente impossível em uma única sessão.

Usuários com deficiências cognitivas, incluindo dislexia, transtornos de déficit de atenção, lesão cerebral traumática e condições relacionadas à demência, podem ter dificuldade em lembrar o que inseriram três etapas atrás. Transcrever informações com precisão a partir da memória ou de um documento em papel várias vezes aumenta muito as taxas de erro e de abandono. De acordo com a Organização Mundial da Saúde, mais de 1 bilhão de pessoas em todo o mundo vivem com algum tipo de deficiência, e deficiências cognitivas representam um dos maiores e mais negligenciados segmentos no planejamento de acessibilidade.

Usuários com diferenças nos membros superiores, incluindo aqueles que nasceram com ou adquiriram diferenças nos membros, digitam muito mais lentamente e podem usar dispositivos de entrada alternativos. Cada pressionamento de tecla adicional exigido multiplica a carga sobre esses usuários.

Considere um cenário do mundo real: uma pessoa com artrite reumatoide está marcando uma consulta médica por meio do portal online de um hospital. Na tela 1 ela insere seu número de identificação nacional, nome, data de nascimento e número de telefone de contato. Na tela 3 o portal pede novamente seu nome e data de nascimento para confirmar o registro do paciente. Essa pessoa precisa redigitar, com grande esforço, informações que forneceu apenas duas telas antes, correndo o risco de erros de digitação que podem causar incompatibilidade de registros e sofrendo esforço físico desnecessário. Um simples pré-preenchimento ou autopreenchimento desses campos removeria completamente a barreira.

Além da acessibilidade, eliminar entrada redundante melhora taxas de conversão, reduz abandono de formulários e diminui chamados de suporte causados por erros de digitação — gerando valor de negócio mensurável junto com um design inclusivo.

Regras Relacionadas do Axe-core

WCAG 3.3.7 é um critério que exige testes manuais. Atualmente não existe nenhuma regra automatizada do axe-core que possa detectar de forma confiável violações de entrada redundante, porque ferramentas automatizadas não conseguem entender a relação semântica entre dados inseridos em múltiplas etapas ou páginas em um processo dinâmico. Elas não têm consciência de quais informações foram coletadas em uma etapa anterior, quais informações estão sendo solicitadas na etapa atual ou se essas duas informações são logicamente idênticas. Somente uma pessoa testadora que percorre o fluxo completo pode observar e avaliar se os mesmos dados estão sendo solicitados duas vezes sem pré-preenchimento.

• Teste manual necessário (novo no WCAG 2.2): axe-core e outros scanners automatizados de acessibilidade analisam o DOM de um único estado de página por vez. Eles não conseguem rastrear valores inseridos pelo usuário em múltiplos carregamentos de página ou etapas de formulário, não conseguem comparar rótulos de campos entre etapas para identificar duplicação semântica e não conseguem avaliar se um mecanismo de pré-preenchimento está funcionando corretamente. As pessoas testadoras devem percorrer manualmente processos de múltiplas etapas, registrar quais dados inserem em cada etapa e verificar, em cada etapa subsequente, se os dados fornecidos anteriormente estão pré-preenchidos ou disponíveis para seleção. Qualquer ferramenta que afirme detectar automaticamente violações de 3.3.7 produziria uma taxa de falso negativo extremamente alta e não deve ser usada como único método de teste.

Como Testar

1. Varredura automatizada como ponto de partida: Execute axe DevTools, Lighthouse ou o auditor Accsible em cada etapa individual do seu processo de múltiplas etapas. Embora essas ferramentas não sinalizem diretamente violações de 3.3.7, elas revelarão problemas relacionados, como atributos de autocomplete ausentes, campos de formulário sem rótulo e outras falhas de critérios 3.3.x que frequentemente ocorrem em conjunto. Documente todos os campos de formulário que encontrar em cada etapa.
2. Mapeie os requisitos de dados entre as etapas: Antes do teste manual, crie uma tabela ou planilha simples listando cada etapa do processo e todos os campos de dados que ela coleta. Em seguida, identifique qualquer rótulo de campo ou tipo de dado que apareça em mais de uma etapa. Esse exercício de mapeamento revela possíveis violações antes mesmo de você abrir um navegador.
3. Percurso manual — desktop: Usando um mouse e teclado padrão, conclua todo o processo de múltiplas etapas (por exemplo, checkout, registro, envio de sinistro). Insira valores realistas em todos os campos. Quando chegar a uma etapa que aparece no seu mapa como campo duplicado, verifique se o campo está pré-preenchido com sua entrada anterior ou se uma opção selecionável apresentando sua entrada anterior está disponível. Se nenhuma das opções estiver presente, registre uma falha. Repita esse teste com um leitor de tela (NVDA com Firefox, JAWS com Chrome, VoiceOver com Safari) para confirmar que valores pré-preenchidos são anunciados corretamente e que controles de seleção para valores inseridos anteriormente são acessíveis via teclado.
4. Percurso manual — mobile: Conclua o mesmo fluxo no iOS (VoiceOver + Safari) e Android (TalkBack + Chrome). Preste atenção a se recursos nativos de autocomplete ou preenchimento automático são suprimidos pela aplicação, o que pode, inadvertidamente, criar barreiras de entrada redundante mesmo que a pessoa desenvolvedora pretendesse que o autocomplete ajudasse.
5. Teste as exceções: Identifique quaisquer campos que intencionalmente peçam entrada duplicada (por exemplo, confirmação de senha, redigitar e-mail). Verifique se eles se qualificam como verificações essenciais de segurança ou validação sob a exceção do WCAG e não são simplesmente campos redundantes que deveriam ser removidos ou pré-preenchidos.
6. Teste com autocomplete desativado: Algumas pessoas usuárias desativam o autocomplete do navegador por motivos de privacidade. Teste se o mecanismo próprio de pré-preenchimento da aplicação (no servidor ou acionado por JavaScript) ainda funciona corretamente quando o autocomplete do navegador está desligado, garantindo que o critério seja atendido independentemente do comportamento do navegador.

Como Corrigir

Checkout em múltiplas etapas — mesmo endereço exigido em duas telas — Incorreto

<!-- Step 1: Shipping Address -->
<form id='shipping-form'>
  <label for='ship-name'>Full Name</label>
  <input type='text' id='ship-name' name='shipping_name'>

  <label for='ship-street'>Street Address</label>
  <input type='text' id='ship-street' name='shipping_street'>

  <label for='ship-city'>City</label>
  <input type='text' id='ship-city' name='shipping_city'>
</form>

<!-- Step 2: Billing Address — user must type everything again -->
<form id='billing-form'>
  <label for='bill-name'>Full Name</label>
  <input type='text' id='bill-name' name='billing_name'>

  <label for='bill-street'>Street Address</label>
  <input type='text' id='bill-street' name='billing_street'>

  <label for='bill-city'>City</label>
  <input type='text' id='bill-city' name='billing_city'>
</form>

Checkout em múltiplas etapas — mesmo endereço exigido em duas telas — Correto

<!-- Step 2: Billing Address — pre-fill option provided -->
<form id='billing-form'>
  <!-- Checkbox allows user to confirm same address rather than re-type it -->
  <input type='checkbox' id='same-as-shipping' name='same_as_shipping'>
  <label for='same-as-shipping'>My billing address is the same as my shipping address</label>

  <div id='billing-fields'>
    <!-- Fields are pre-populated server-side with shipping values;
         JavaScript can also copy values when checkbox is unchecked -->
    <label for='bill-name'>Full Name</label>
    <input type='text' id='bill-name' name='billing_name' value='Jane Doe' autocomplete='billing name'>

    <label for='bill-street'>Street Address</label>
    <input type='text' id='bill-street' name='billing_street' value='123 Elm Street' autocomplete='billing street-address'>

    <label for='bill-city'>City</label>
    <input type='text' id='bill-city' name='billing_city' value='Ankara' autocomplete='billing address-level2'>
  </div>
</form>

Assistente de registro pedindo e-mail duas vezes sem justificativa — Incorreto

<!-- Step 1 collected email. Step 3 asks again with no pre-fill. -->
<fieldset>
  <legend>Confirm Your Details</legend>
  <label for='confirm-email'>Email Address</label>
  <input type='email' id='confirm-email' name='confirm_email'>
  <!-- No value pre-populated; user must type the same email entered on step 1 -->
</fieldset>

Assistente de registro — e-mail pré-preenchido a partir de dados de sessão — Correto

<!-- Server renders the previously collected email into the value attribute -->
<fieldset>
  <legend>Confirm Your Details</legend>
  <label for='confirm-email'>Email Address</label>
  <!-- value is injected from server-side session; user can correct if needed -->
  <input type='email' id='confirm-email' name='confirm_email'
         value='[email protected]' autocomplete='email'>
</fieldset>

Agendamento de consulta — dados do paciente pedidos novamente na etapa de resumo — Incorreto

<!-- Summary step re-asks for date of birth already entered in patient info step -->
<label for='dob-confirm'>Date of Birth</label>
<input type='date' id='dob-confirm' name='dob_confirm'>
<!-- Empty field requires user to re-enter DOB from memory or paper -->

Agendamento de consulta — data de nascimento exibida como confirmação somente leitura — Correto

<!-- Previously entered DOB displayed in a read-only field for review;
     a hidden input carries the value for form submission -->
<label for='dob-confirm'>Date of Birth (from your patient record)</label>
<input type='date' id='dob-confirm' name='dob_confirm'
       value='1985-04-12' readonly aria-describedby='dob-hint'>
<span id='dob-hint'>This value was entered earlier. Contact support if it is incorrect.</span>

Erros Comuns

• Construir formulários de múltiplas etapas como páginas independentes sem estado de sessão compartilhado, de modo que não haja mecanismo para levar adiante valores inseridos em etapas anteriores — o erro arquitetural mais fundamental que leva a falhas em 3.3.7.
• Fornecer uma caixa de seleção "igual ao endereço de entrega" mas não preencher de fato os campos de cobrança quando ela é marcada, obrigando usuários a ainda digitarem os detalhes do endereço manualmente mesmo depois de indicarem que eles devem coincidir.
• Pré-preencher campos no carregamento da página, mas depois limpá-los em caso de erro de validação, de modo que uma pessoa que comete um erro em uma etapa posterior precise reinserir todos os dados fornecidos anteriormente quando voltar para corrigi-lo.
• Armazenar dados de sessão de forma insegura e optar por desativá-los em vez de corrigir o problema de segurança, resultando em uma experiência de pré-preenchimento quebrada que tecnicamente constitui uma falha em 3.3.7.
• Usar a exceção de confirmação de senha como justificativa para obrigar usuários a redigitar endereços de e-mail, quando a confirmação de e-mail não é uma verificação de segurança essencial e não se qualifica sob a exceção do WCAG.
• Não passar valores transportados por meio de inputs ocultos em formulários renderizados no servidor, fazendo com que valores pré-preenchidos sejam perdidos quando uma pessoa navega para frente e para trás entre etapas usando os botões de histórico do navegador.
• Confiar apenas no preenchimento automático do navegador para atender a este critério, sem implementar pré-preenchimento em nível de aplicação — usuários que desativam o preenchimento automático por motivos de privacidade então não têm um caminho conforme pelo processo.
• Pré-preencher um campo, mas defini-lo como disabled em vez de readonly, o que faz com que o valor seja excluído do envio do formulário na maioria dos navegadores, quebrando o processo e potencialmente forçando a reentrada.
• Não testar o fluxo completo de ponta a ponta com pessoas que usam software de entrada por voz, como Dragon NaturallySpeaking, em que campos redundantes podem exigir repetir o mesmo comando de ditado verbal várias vezes, uma carga significativa que é fácil de ignorar em testes de desenvolvimento.
• Tratar este critério como aplicável apenas a campos de endereço, quando ele se aplica igualmente a quaisquer dados repetidos, incluindo nomes, números de telefone, números de identificação nacional, números de apólice, datas e qualquer outra informação fornecida pelo usuário solicitada mais de uma vez no mesmo processo.

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, exige conformidade com acessibilidade na web para uma ampla gama de entidades públicas e privadas que operam na Turquia. WCAG 3.3.7 Redundant Entry é um critério de Nível A sob o WCAG 2.2, e a conformidade de Nível A é a base obrigatória sob esta circular. Isso significa que qualquer entidade abrangida que opere um site, aplicação web ou serviço digital não deve exigir que usuários reinsiram informações que já forneceram dentro do mesmo processo — sem exceção — sob risco de não conformidade.

A circular estabelece um cronograma de implementação em fases: instituições públicas devem alcançar conformidade dentro de um ano da publicação da circular, enquanto entidades do setor privado nas categorias abrangidas têm dois anos para se adequar.

Os tipos de entidades abrangidas pela circular são extensos e incluem plataformas e marketplaces de e-commerce, todas as instituições públicas e órgãos governamentais, bancos e prestadores de serviços financeiros, hospitais e portais de saúde (públicos e privados), 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 todas essas entidades, processos digitais de múltiplas etapas — fluxos de checkout em sites de e-commerce, registro de pacientes em portais de hospitais, abertura de conta em plataformas bancárias, formulários de matrícula em sites de escolas — devem ser auditados e corrigidos para eliminar qualquer ocorrência de entrada redundante.

Na prática, essa regulamentação coloca a conformidade com WCAG 3.3.7 diretamente no escopo das equipes de compras, produto e jurídica em toda a economia digital da Turquia. Por exemplo, uma plataforma de e-commerce turca que opera um checkout em múltiplas etapas que pede um endereço de entrega em uma tela e um endereço de cobrança na seguinte sem oferecer uma opção de pré-preenchimento ou cópia está em violação direta tanto do WCAG 2.2 Nível A quanto da Circular Presidencial. Da mesma forma, o portal de agendamento de consultas de um hospital estadual que pede aos pacientes que reinsiram seu número de identidade ou data de nascimento em várias telas é não conforme. Organizações sujeitas à circular devem priorizar uma auditoria de ponta a ponta de todos os processos de múltiplas etapas como parte de seu roteiro de conformidade, tratando a eliminação de entrada redundante como uma tarefa de engenharia obrigatória, não um aprimoramento opcional.