WCAG 3.3.4: Prevenção de Erros (Jurídicos, Financeiros, Dados)

O que Esta Regra Significa

O Critério de Sucesso 3.3.4 das WCAG, intitulado Prevenção de Erros (Legal, Financeiro, Dados), é um requisito de Nível AA sob o Princípio 3 (Compreensível) e a Diretriz 3.3 (Ajuda na Entrada). Aplica-se especificamente a páginas da web em que usuários podem causar compromissos legais ou transações financeiras, ou em que o usuário modifica ou exclui dados controláveis pelo usuário em um sistema de armazenamento de dados.

O critério determina que pelo menos uma das três salvaguardas a seguir seja fornecida para qualquer envio desse tipo:

• Reversível: O envio pode ser desfeito depois de ter sido enviado. Por exemplo, um pedido pode ser cancelado dentro de uma janela de tempo definida, ou um registro excluído pode ser restaurado.
• Verificado: Os dados inseridos pelo usuário são verificados quanto a erros de entrada, e o usuário tem a oportunidade de corrigir esses erros antes que o envio seja finalizado.
• Confirmado: É fornecido um mecanismo para revisar, confirmar e corrigir informações antes do envio final. Isso normalmente assume a forma de um passo de resumo ou revisão antes que um botão de envio conclua a transação.

É importante observar que apenas uma dessas três condições precisa ser satisfeita para aprovação. Fornecer apenas um passo de revisão e confirmação é suficiente, assim como oferecer uma janela de cancelamento pós-envio, ou uma validação robusta em tempo real com oportunidade de correção. A melhor prática, no entanto, é combinar múltiplas salvaguardas.

Escopo do critério: A regra se aplica a três categorias de transação. Primeiro, abrange compromissos legais, como assinar uma assinatura, concordar com um contrato ou enviar um formulário legal vinculativo. Segundo, abrange transações financeiras, incluindo compras, transferências de fundos, solicitações de empréstimo e pagamentos de contas. Terceiro, abrange qualquer ação que modifique ou exclua dados controlados pelo usuário em um sistema de armazenamento de dados — por exemplo, atualizar informações de perfil, excluir arquivos de um serviço em nuvem ou editar registros em um painel administrativo.

Uma aprovação se parece com: um checkout de e-commerce que apresenta um resumo do pedido com um link "Editar" e um botão "Finalizar Pedido" como passo final. Uma falha se parece com: um formulário de compra em página única em que clicar em "Comprar Agora" cobra imediatamente o cartão, sem tela de revisão, sem opção de cancelamento e sem etapa de validação.

O critério tem uma exceção definida: não se aplica a formulários em que o envio de informações incorretas não é consequente e o envio pode ser repetido de forma trivial. Formulários simples de contato ou inscrições em newsletter geralmente ficam fora do escopo, embora boas práticas ainda incentivem a validação nesses formulários.

Por Que Isso Importa

Erros durante transações de alto risco podem ter consequências graves, às vezes irreversíveis: dinheiro transferido para a conta errada, um acordo legal assinado sob falsos pressupostos, prontuários médicos atualizados com informações incorretas ou uma assinatura comprada no plano errado. Para usuários sem deficiências, detectar e corrigir esses erros costuma ser simples. Para muitos grupos de pessoas com deficiência, isso pode ser extremamente difícil ou até impossível sem as salvaguardas exigidas por este critério.

Usuários com deficiências cognitivas — incluindo pessoas com dislexia, TDAH, comprometimentos de memória ou deficiências intelectuais — têm maior probabilidade de cometer erros de digitação e menor probabilidade de percebê-los antes de clicar em enviar. Uma tela de revisão lhes dá o tempo e a clareza de que precisam para identificar erros. De acordo com a Organização Mundial da Saúde, aproximadamente 1 bilhão de pessoas no mundo vivem com algum tipo de condição cognitiva, neurológica ou de saúde mental que afeta o funcionamento diário.

Usuários com deficiências motoras que dependem de acesso por varredura, dispositivos de rastreamento ocular ou teclados alternativos são propensos a ativações acidentais e pressionamentos de tecla não intencionais. Uma etapa de confirmação atua como um amortecedor crítico: mesmo que "Enviar" seja ativado por engano, o usuário tem outra oportunidade de cancelar antes que a transação seja concluída. Sem essa salvaguarda, um único toque acidental pode disparar uma transação financeira que o usuário não consegue reverter.

Usuários de leitores de tela que navegam por formulários longos de forma linear podem não ter uma visão holística do que inseriram. Um resumo falado na etapa de confirmação — lendo os valores inseridos — permite que identifiquem erros que não poderiam inspecionar visualmente.

Usuários com ansiedade ou dificuldades de atenção se beneficiam enormemente de saber que existe uma rede de segurança. Pesquisas mostram de forma consistente que, quando usuários percebem um processo como tolerante a erros, eles se engajam com mais confiança e abandonam transações com menos frequência. Isso beneficia diretamente as taxas de conversão e a satisfação do usuário, tornando a conformidade com o 3.3.4 uma vantagem de negócios, além de uma obrigação ética.

Cenário do mundo real: Uma usuária com deficiência visual em Istambul está reservando um voo doméstico usando um leitor de tela. Ela seleciona uma data, mas acidentalmente navega além do campo de quantidade de passageiros, deixando-o no padrão de dois passageiros em vez de um. Se o site de reservas cobrar o cartão no momento em que ela ativa "Confirmar", ela terá comprado duas passagens e poderá enfrentar tarifas não reembolsáveis. Uma tela de revisão que leia em voz alta "1 passageiro: Ayşe Yılmaz, Ancara para Istambul, 14 de março, Econômica — Total: ₺850" permitiria que ela percebesse o erro imediatamente.

Regras Relacionadas do Axe-core

O WCAG 3.3.4 exige testes manuais. Nenhuma regra automatizada do axe-core mapeia diretamente para este critério porque as salvaguardas que ele exige — reversibilidade, validação com oportunidade de correção e etapas de confirmação — são questões de fluxo de aplicação e lógica de negócios, não de estrutura de marcação ou atributos do DOM. Ferramentas automatizadas podem analisar HTML e ARIA, mas não conseguem determinar se um botão "Pagar Agora" aciona uma cobrança irreversível, se existe uma política de cancelamento ou se os dados exibidos em uma tela de revisão refletem com precisão o que foi inserido.

• Por que a automação não consegue detectar isso: Um scanner automatizado vê um elemento <button> com o texto "Enviar" e marcação válida. Ele não tem como saber se ativar esse botão inicia uma transação financeira vinculativa, se um diálogo de confirmação aparecerá em seguida ou se a transação pode ser desfeita depois. Essas são decisões de arquitetura e UX que existem acima do nível de nós individuais do DOM, exigindo um testador humano que entenda toda a jornada do usuário.
• Sinais parciais a observar durante varreduras automatizadas: Embora o axe-core não sinalize violações do 3.3.4 diretamente, auditores às vezes usam o axe para identificar problemas relacionados que aumentam o risco — como ausência de atributos autocomplete em campos de pagamento (relevante para 1.3.5), ausência de mensagens de erro (relevante para 3.3.1 e 3.3.3) ou ausência de rótulos em controles de formulário (relevante para 1.3.1 e 4.1.2). Essas falhas relacionadas tornam a prevenção de erros ainda mais difícil de alcançar.
• Abordagem recomendada de auditoria manual: Testadores devem mapear toda jornada de usuário que envolva um envio legal, financeiro ou de modificação de dados e, em seguida, avaliar cada jornada em relação aos três critérios: Existe uma forma de desfazer? Há validação em linha com oportunidade de correção? Há uma etapa de revisão e confirmação? Falhar em todos os três em qualquer jornada desse tipo constitui uma falha no 3.3.4.

Como Testar

1. Inventariar formulários de alto risco: Antes de iniciar os testes, crie uma lista de todos os formulários ou fluxos interativos no site que envolvam transações financeiras (checkout, pagamento, faturamento), compromissos legais (assinatura de contrato, adesão a assinatura, formulários de consentimento) ou modificação/exclusão de dados (edição de perfil, exclusão de arquivos, remoção de conta). Esses são os únicos fluxos no escopo do 3.3.4.
2. Executar uma varredura automatizada em busca de problemas relacionados: Use axe DevTools ou Lighthouse para identificar falhas de acessibilidade em nível de formulário em cada página dentro do escopo. Embora essas ferramentas não sinalizem o 3.3.4 diretamente, resolver problemas como rótulos ausentes, atributos de autocomplete ausentes e ausência de anúncios de erro estabelece uma base de qualidade do formulário antes de avaliar a salvaguarda de prevenção de erros.
3. Testar a salvaguarda "Verificado": Envie deliberadamente cada formulário dentro do escopo com erros intencionais — dígitos trocados em um número de cartão, uma data inválida, um campo de confirmação de e-mail que não corresponde. Observe se o sistema interrompe o envio, identifica o erro específico, descreve como corrigi-lo (conforme 3.3.3) e mantém o usuário no formulário para fazer correções. Se o formulário for enviado silenciosamente ou apenas exibir um erro genérico sem identificar qual campo falhou, essa salvaguarda não é atendida.
4. Testar a salvaguarda "Confirmado": Preencha cada formulário dentro do escopo com dados válidos e percorra todo o fluxo. Verifique se é apresentada uma etapa de revisão antes do envio final. Confirme se a etapa de revisão exibe todos os dados inseridos em um formato legível, inclui um mecanismo para voltar e editar e exige uma ação final deliberada para concluir o envio. Usando NVDA com Firefox e JAWS com Chrome, navegue por essa etapa de revisão com um leitor de tela para confirmar que todos os valores são anunciados e que os controles de edição e confirmação são acessíveis via teclado.
5. Testar a salvaguarda "Reversível": Conclua um envio e tente desfazê-lo. Para e-commerce, procure um link de cancelamento no e-mail de confirmação ou na página de histórico de pedidos. Para exclusão de dados, procure um mecanismo de restauração ou lixeira. Avalie se a janela de reversão é claramente comunicada ao usuário antes de ele enviar, e não apenas depois.
6. Passo a passo com leitor de tela (VoiceOver + Safari no macOS/iOS): Navegue por todo o fluxo de checkout ou envio usando apenas o teclado e o VoiceOver. Confirme se a tela de revisão lê todos os valores inseridos em uma ordem lógica, se os links de edição são anunciados com contexto suficiente (por exemplo, "Editar endereço de entrega" e não apenas "Editar") e se o propósito do botão de confirmação final é inequívoco.
7. Verificação de carga cognitiva: Avalie se a etapa de revisão é apresentada em linguagem simples. Um resumo que lista nomes de campos de banco de dados brutos ou usa jargão jurídico sem explicação pode tecnicamente se qualificar como uma tela de revisão, mas falhar na prática para usuários com deficiências cognitivas.

Como Corrigir

Checkout em etapa única sem revisão — Incorreto

<!-- Problemático: clicar em "Complete Purchase" cobra o cartão imediatamente -->
<form action='/checkout/complete' method='post'>
  <input type='hidden' name='cart_id' value='abc123'>
  <input type='hidden' name='payment_token' value='tok_xyz'>
  <button type='submit'>Complete Purchase</button>
</form>

Checkout em etapa única com etapa de revisão adicionada — Correto

<!-- Etapa 1: formulário coleta dados e envia para página de revisão (não é final) -->
<form action='/checkout/review' method='post'>
  <!-- campos de pagamento e entrega -->
  <button type='submit'>Review Order</button>
</form>

<!-- Etapa 2: página de revisão resume todos os dados inseridos e oferece links de edição -->
<section aria-labelledby='review-heading'>
  <h2 id='review-heading'>Review Your Order</h2>
  <dl>
    <dt>Delivery address</dt>
    <dd>Atatürk Cad. No:5, Kadıköy, Istanbul</dd>
    <dd><a href='/checkout/edit-address'>Edit delivery address</a></dd>
    <dt>Total</dt>
    <dd>₺1,249.00</dd>
  </dl>
  <form action='/checkout/complete' method='post'>
    <input type='hidden' name='order_token' value='tok_abc'>
    <!-- Botão final é claramente rotulado como a ação vinculativa -->
    <button type='submit'>Place Order and Pay ₺1,249.00</button>
  </form>
</section>

Exclusão irreversível de dados sem confirmação — Incorreto

<!-- Problemático: botão de exclusão envia diretamente sem diálogo de confirmação -->
<form action='/account/delete-profile' method='post'>
  <button type='submit'>Delete My Account</button>
</form>

Exclusão irreversível de dados com diálogo de confirmação — Correto

<!-- Botão de disparo abre um diálogo de confirmação, não a ação destrutiva -->
<button type='button' aria-haspopup='dialog' aria-controls='confirm-delete-dialog'>
  Delete My Account
</button>

<dialog id='confirm-delete-dialog' aria-labelledby='dialog-title' aria-describedby='dialog-desc'>
  <h2 id='dialog-title'>Permanently Delete Account?</h2>
  <p id='dialog-desc'>
    This will permanently remove all your data. This action cannot be undone.
    Your subscription will be cancelled immediately.
  </p>
  <form action='/account/delete-profile' method='post'>
    <button type='submit'>Yes, permanently delete my account</button>
    <button type='button' onclick='this.closest("dialog").close()'>Cancel</button>
  </form>
</dialog>

Formulário financeiro sem validação em linha — Incorreto

<!-- Problemático: sem validação, IBAN errado é aceito silenciosamente -->
<form action='/transfer/submit' method='post'>
  <label for='iban'>Recipient IBAN</label>
  <input type='text' id='iban' name='iban'>
  <label for='amount'>Amount (TRY)</label>
  <input type='number' id='amount' name='amount'>
  <button type='submit'>Transfer</button>
</form>

Formulário financeiro com validação e revisão — Correto

<!-- Validação em linha com aria-describedby para associação de erro -->
<form action='/transfer/review' method='post' novalidate>
  <div>
    <label for='iban'>Recipient IBAN</label>
    <input
      type='text'
      id='iban'
      name='iban'
      aria-describedby='iban-hint iban-error'
      aria-required='true'
      autocomplete='off'
      pattern='[A-Z]{2}[0-9]{2}[A-Z0-9]{1,30}'
    >
    <p id='iban-hint'>Enter a valid TR IBAN starting with TR followed by 24 digits.</p>
    <p id='iban-error' role='alert' aria-live='assertive' hidden>
      Invalid IBAN format. Please check the number and try again.
    </p>
  </div>
  <!-- Envia para página de revisão, não para execução direta -->
  <button type='submit'>Review Transfer</button>
</form>

Erros Comuns

• Usar um tooltip como mecanismo de "revisão": Exibir valores inseridos em um tooltip ao passar o mouse antes do botão de envio não constitui uma etapa de revisão, porque tooltips não são acessíveis a usuários apenas de teclado ou usuários de leitores de tela e desaparecem antes que o usuário possa agir sobre eles.
• Rotular o botão final como "Continuar" em vez de descrever a ação: Um botão com o texto "Continuar" em uma página de revisão não deixa claro que clicar nele concluirá uma transação financeira. O botão deve descrever de forma inequívoca a ação vinculativa, como "Finalizar Pedido e Pagar ₺850" ou "Assinar Contrato".
• Fornecer uma política de cancelamento apenas nos termos de serviço: Enterrar o mecanismo de reversão em um documento jurídico vinculado que a maioria dos usuários não lerá não satisfaz o requisito de reversibilidade. A possibilidade de cancelar e a janela de tempo em que ela está disponível devem ser comunicadas no próprio fluxo da transação.
• Usar window.confirm() como único mecanismo de confirmação: Diálogos de confirmação nativos do navegador têm suporte precário por algumas tecnologias assistivas, não podem ser estilizados para legibilidade e são bloqueados em certas configurações de navegador. Eles não devem ser usados como única salvaguarda para envios de alto risco.
• Redefinir o formulário em caso de falha de validação sem preservar valores de campos válidos: Quando um formulário falha na validação, limpar todos os campos força usuários — especialmente aqueles com deficiências motoras — a reinserir todos os dados. Apenas o campo inválido deve ser limpo ou destacado; todas as entradas válidas devem ser preservadas.
• Colocar o link "Editar" na página de revisão sem associação programática: Um link "Editar" ao lado de cada grupo de dados deve ter um nome acessível descritivo (por exemplo, aria-label='Edit billing address'). Um simples "Edit" repetido várias vezes é ambíguo para usuários de leitores de tela que navegam por links.
• Não anunciar a etapa de revisão para leitores de tela: Se a página de revisão carregar sem mover o foco para o cabeçalho ou para uma região de resumo, usuários de leitores de tela podem não perceber que estão em uma página de revisão e podem ativar o botão de envio sem ler o resumo.
• Tratar o critério como se se aplicasse apenas a páginas de pagamento: O escopo inclui qualquer compromisso legal (inscrição em assinatura, formulários de consentimento, aceitação de contrato) e qualquer modificação de dados do usuário (exclusão de arquivos, atualização de prontuários médicos, alteração de configurações de conta). Desenvolvedores frequentemente ignoram painéis administrativos e páginas de configurações.
• Oferecer reversão apenas por telefone ou e-mail: Se o cancelamento exigir ligar para uma central de suporte, usuários com deficiências de fala ou audição podem não conseguir acessar o mecanismo de reversão. O caminho de reversão deve ser acessível em si — de preferência um fluxo de cancelamento dentro do próprio aplicativo.
• Ignorar o critério em webviews móveis: Algumas equipes implementam uma etapa de revisão no desktop, mas usam um fluxo condensado de etapa única no mobile para reduzir o espaço em tela. O critério se aplica igualmente a todos os tamanhos de viewport e não deve ser omitido em implementações responsivas ou web móveis.

Relação com os Regulamentos de Acessibilidade da Turquia

O Decreto Presidencial 2025/10 da Turquia, publicado no Diário Oficial nº 32933 em 21 de junho de 2025, estabelece um abrangente marco nacional de acessibilidade que faz referência às WCAG 2.2 como seu padrão técnico. O Decreto determina que serviços digitais atendam, no mínimo, à conformidade Nível AA das WCAG 2.2, o que inclui o WCAG 3.3.4 Prevenção de Erros (Legal, Financeiro, Dados).

As entidades explicitamente abrangidas pelo Decreto cobrem uma ampla gama de setores. Instituições e órgãos públicos são obrigados a tornar todos os serviços digitais voltados ao cidadão acessíveis, incluindo solicitações online, portais de governo eletrônico e serviços de identidade digital — todos os quais frequentemente envolvem compromissos legais e modificação de dados. Bancos e instituições financeiras regulados pela BDDK (Agência de Regulação e Supervisão Bancária) devem cumprir, tornando o 3.3.4 diretamente relevante para cada transação bancária online, transferência de fundos e solicitação de empréstimo que oferecem. Hospitais e instituições de saúde que operam portais digitais de pacientes, sistemas de agendamento e prontuários eletrônicos devem garantir que qualquer inserção ou modificação de dados nesses sistemas atenda aos padrões de prevenção de erros. Provedores de telecomunicações com 200.000 ou mais assinantes — incluindo Turkcell, Vodafone TR e Türk Telekom — devem garantir que a gestão de assinaturas, mudanças de plano e fluxos de pagamento estejam cobertos. Plataformas de e-commerce, agências de viagem, empresas privadas de transporte e escolas privadas autorizadas pelo Ministério da Educação Nacional (MoNE) também estão dentro do escopo, cobrindo uma parcela substancial dos serviços web transacionais de alto volume no mercado turco.

A conformidade com o 3.3.4 não é apenas um item técnico sob esse marco. Organizações que buscam o Erişilebilirlik Logosu (Selo de Acessibilidade) emitido pelo Ministério da Família e Serviços Sociais devem demonstrar conformidade total com as WCAG 2.2 AA. O selo funciona como um sinal de confiança pública e é cada vez mais esperado por consumidores e órgãos de compras públicas. A falta de implementação de salvaguardas de prevenção de erros em fluxos financeiros ou jurídicos pode resultar tanto na negação do selo quanto em possíveis medidas administrativas sob as disposições de fiscalização do Decreto.

Para organizações turcas nos setores de e-commerce e fintech especificamente, o 3.3.4 se alinha de perto com requisitos existentes de proteção ao consumidor sob a legislação turca. A Lei de Proteção ao Consumidor (nº 6502) e regulamentos de e-commerce associados já exigem informações pré-contratuais claras e direitos de cancelamento para contratos à distância. Implementar uma etapa de revisão e confirmação compatível com o WCAG 3.3.4 satisfaz simultaneamente o requisito de acessibilidade e a obrigação de direito do consumidor de apresentar resumos de pedidos antes de vincular o comprador. Essa dupla conformidade torna o investimento em uma UX adequada de prevenção de erros um esforço de alto valor e baixa duplicação para provedores de serviços digitais na Turquia.