WCAG 3.3.6: Prevenção de Erros (Todos)

O Que Esta Regra Significa

WCAG 3.3.6 — Prevenção de Erros (Todos) é um critério de sucesso de Nível AAA sob o princípio Compreensível. Ele estende os requisitos de 3.3.4 (Prevenção de Erros: Jurídico, Financeiro, Dados) para cobrir todas as páginas que exigem que um usuário envie informações, independentemente de esse envio envolver compromissos legais, transações financeiras ou dados pessoalmente identificáveis.

Em essência, o critério exige que, para qualquer página da web em que um usuário envie informações, pelo menos uma das três condições a seguir seja satisfeita:

• Reversível: Os envios são reversíveis após o fato. O usuário pode desfazer, cancelar ou retratar uma ação dentro de um prazo razoável. Por exemplo, uma mensagem enviada pode ser recuperada, ou um formulário enviado pode ser cancelado a partir de uma fila de confirmação.
• Verificado: Os dados inseridos pelo usuário são verificados quanto a erros de entrada antes do envio final, e o usuário tem a oportunidade de corrigir esses erros. Isso envolve validação em linha, resumos antes do envio ou fluxos de revisão passo a passo.
• Confirmado: É fornecido um mecanismo para revisar, confirmar e corrigir informações antes que o envio seja finalizado. Isso pode ser uma tela de revisão, uma caixa de diálogo de confirmação ou um assistente de múltiplas etapas com uma etapa final de revisão.

A principal diferença entre 3.3.4 e 3.3.6 é o escopo. O critério 3.3.4 se aplica apenas a acordos legais, transações financeiras, respostas de testes e exclusões de dados controlados pelo usuário. O critério 3.3.6 amplia isso para todas as páginas que exigem qualquer forma de envio de entrada do usuário — incluindo formulários de contato, inscrições em newsletters, seções de comentários, respostas a pesquisas, atualizações de perfil, configurações de pesquisa e qualquer outra inserção de dados controlada pelo usuário.

O que conta como aprovação: Um formulário é aprovado se implementar de forma consistente pelo menos um dos três mecanismos acima. Uma página de confirmação antes do envio final, uma tela de resumo com opção de "Editar", validação no lado do cliente ou do servidor com oportunidades de correção de erros, ou uma janela de desfazer claramente comunicada satisfazem o critério.

O que conta como reprovação: Um formulário de etapa única que envia dados imediatamente ao clicar no botão, sem validação, sem tela de revisão e sem mecanismo de desfazer, reprova neste critério. Da mesma forma, um formulário que valida, mas não oferece oportunidade de corrigir erros antes de reenviar, também reprova.

A especificação WCAG não exige os três mecanismos simultaneamente — satisfazer qualquer um deles é suficiente. No entanto, combinar dois ou três mecanismos fornece defesa em profundidade e atende a uma gama mais ampla de usuários e contextos.

Por Que Isso Importa

A prevenção de erros não é apenas um detalhe de usabilidade — é um requisito fundamental de acessibilidade para usuários que enfrentam risco elevado de erros de entrada devido a deficiência ou limitações situacionais.

Deficiências cognitivas e de aprendizagem: Usuários com dislexia, TDAH ou comprometimentos de memória frequentemente cometem erros de digitação, trocam dígitos ou perdem o controle de formulários complexos com vários campos. Sem um mecanismo de revisão, um endereço de e-mail digitado incorretamente em um formulário de contato pode significar uma resposta perdida, ou um endereço inserido incorretamente em um formulário de entrega pode causar extravio de encomendas. Esses não são casos extremos — de acordo com a Organização Mundial da Saúde, aproximadamente 1 bilhão de pessoas em todo o mundo vivem com algum tipo de condição cognitiva ou neurológica que afeta o funcionamento diário.

Deficiências motoras: Usuários com tremores, controle motor fino limitado ou que dependem de acesso por varredura ou software de entrada por voz frequentemente ativam envios de formulários acidentalmente ou inserem caracteres indesejados. Um usuário com doença de Parkinson navegando em um formulário complexo com uma interface de varredura pode enviar inadvertidamente um formulário incompleto ou incorreto. Sem etapas de reversibilidade ou confirmação, esses erros se tornam permanentes.

Usuários de leitores de tela: Usuários cegos que navegam com JAWS, NVDA ou VoiceOver podem não ter a mesma visão geral visual de um formulário preenchido que usuários videntes têm antes de enviar. Uma tela de confirmação ou resumo lida em voz alta por um leitor de tela dá a esses usuários uma última chance de verificar seus dados antes de serem enviados de forma irreversível.

Baixa literacia digital e populações idosas: Idosos e usuários novos em interfaces digitais são particularmente vulneráveis a envios acidentais. Uma etapa de confirmação com resumos em linguagem simples fornece uma rede de segurança que reduz drasticamente os custos de suporte e a frustração do usuário.

Cenário do mundo real: Considere um portal de governo eletrônico turco em que um cidadão preenche um longo formulário burocrático para registrar uma empresa. Se o cidadão omitir acidentalmente um campo obrigatório ou inserir seu número de identificação fiscal incorretamente e o formulário for enviado imediatamente sem etapa de revisão, ele pode não perceber o erro até receber um aviso formal de rejeição dias depois. Uma simples tela de confirmação mostrando todos os dados inseridos antes do envio final teria evitado isso completamente.

Benefícios de SEO e usabilidade: Páginas que implementam prevenção de erros robusta tendem a ter menores taxas de abandono de formulários, maiores taxas de conversão e melhores índices de satisfação do usuário. Os mecanismos de busca cada vez mais consideram sinais de experiência do usuário nos rankings, e páginas com altas taxas de rejeição devido a erros de formulário sofrem indiretamente em visibilidade orgânica.

Regras Relacionadas do Axe-core

WCAG 3.3.6 exige testes manuais porque nenhuma ferramenta automatizada pode determinar se um determinado fluxo de envio de formulário satisfaz os requisitos de reversibilidade, verificação de erros ou confirmação deste critério. Varredores automatizados de acessibilidade como o axe-core podem verificar a presença de atributos ARIA individuais, rótulos e mensagens de erro, mas não podem avaliar a lógica geral do fluxo de envio, a existência de uma etapa de confirmação ou se um mecanismo de desfazer é realmente funcional. O critério é fundamentalmente sobre design de interação e fluxo de experiência do usuário — não sobre marcação estática.

• Não existe uma regra dedicada do axe-core para 3.3.6. Axe-core e mecanismos semelhantes testam elementos individuais do DOM em relação a requisitos específicos de atributo ou função. Determinar se um formulário de múltiplas páginas inclui uma etapa de revisão antes do envio final exige entender o fluxo de navegação da aplicação e o comportamento do lado do servidor — informações às quais ferramentas de análise estática não têm acesso. Um testador humano deve percorrer toda a jornada de envio para avaliar a conformidade.
• Regras relacionadas que apoiam a qualidade geral do formulário (embora não especificamente 3.3.6): Regras como label (todo campo de entrada tem um rótulo associado), aria-required-attr (atributos ARIA obrigatórios estão presentes) e form-field-multiple-labels (campos de entrada não têm rótulos conflitantes) contribuem para a base de formulários acessíveis. Garantir que essas regras sejam aprovadas é um pré-requisito para uma prevenção de erros significativa, mas aprová-las não garante conformidade com 3.3.6.
• Por que a automação é insuficiente: Uma varredura automatizada de uma página de checkout pode confirmar que todos os campos de entrada têm rótulos e que as mensagens de erro estão associadas programaticamente aos campos. Mas ela não pode determinar se clicar em "Enviar" leva o usuário a uma tela de revisão, se existe uma opção "Cancelar" ou se o sistema envia um e-mail de confirmação com um link de cancelamento. Essas são questões de comportamento e processo que apenas a avaliação humana pode responder.

Como Testar

1. Execute uma varredura automatizada como linha de base: Use axe DevTools, Lighthouse ou o modo de auditoria integrado do widget Accsible para analisar todas as páginas que contêm formulários. Embora essas ferramentas não sinalizem violações de 3.3.6 diretamente, elas estabelecem uma base ao identificar rótulos ausentes, mensagens de erro inexistentes ou feedback de validação associado de forma incorreta. Resolva todas as descobertas automatizadas antes de prosseguir para testes manuais.
2. Identifique todos os formulários de envio no site: Crie um inventário completo de todas as páginas que aceitam e enviam entrada do usuário — formulários de contato, formulários de registro, formulários de login, formulários de preferência de pesquisa, páginas de atualização de perfil, seções de comentários, inscrições em newsletters e quaisquer assistentes de múltiplas etapas. Cada um deve ser testado de forma independente.
3. Teste o caminho feliz com erros intencionais: Em cada formulário, insira intencionalmente dados incorretos, incompletos ou malformados (por exemplo, um endereço de e-mail inválido, um número de telefone com letras, deixar campos obrigatórios em branco). Envie o formulário e observe: a página impede o envio e fornece mensagens de erro? As mensagens de erro estão associadas aos campos corretos? O usuário tem uma oportunidade clara de corrigir e reenviar?
4. Teste mecanismos de confirmação ou revisão: Para formulários que passam na validação, preencha o formulário com dados válidos e envie. Observe se uma tela de confirmação, caixa de diálogo de resumo ou etapa de revisão aparece antes de os dados serem irrevogavelmente enviados. Verifique se a etapa de revisão permite que o usuário volte e edite as entradas.
5. Teste a reversibilidade após o envio: Após um envio bem-sucedido, verifique se existe um mecanismo de cancelamento, desfazer ou retratação. Isso pode ser um link "Cancelar envio" em um e-mail de confirmação, uma tela de gerenciamento de fila em uma área administrativa ou uma notificação no aplicativo com uma ação de desfazer. Verifique se o mecanismo funciona e é claramente comunicado aos usuários.
6. Teste com leitor de tela usando NVDA + Firefox: Navegue até cada formulário usando NVDA e Firefox. Percorra todos os campos com a tecla Tab, insira dados e envie o formulário. Verifique se as mensagens de erro são anunciadas quando aparecem, se a tela de revisão (se presente) é totalmente legível na ordem do documento e se todos os controles interativos (botões de editar, confirmar, cancelar) na tela de confirmação são acessíveis via teclado e devidamente rotulados.
7. Teste com leitor de tela usando VoiceOver + Safari (macOS/iOS): Repita o processo acima usando VoiceOver no Safari. Preste atenção especial às atualizações dinâmicas de conteúdo — se erros de validação aparecerem dinamicamente via JavaScript sem recarregar a página, confirme que eles são exibidos por meio de regiões dinâmicas (aria-live) para que o VoiceOver os anuncie sem exigir que o usuário explore a página manualmente.
8. Teste apenas com teclado: Sem usar o mouse, navegue por todo o fluxo de envio do formulário usando apenas as teclas Tab, Shift+Tab, Enter e Espaço. Confirme que todos os elementos interativos — incluindo botões de editar, voltar, confirmar e cancelar em telas de revisão — são alcançáveis e operáveis sem um dispositivo apontador.

Como Corrigir

Formulário de Contato Sem Validação ou Revisão — Incorreto

<!-- Fails 3.3.6: submits immediately with no validation, no review, no undo -->
<form action='/submit-contact' method='post'>
  <label for='name'>Name</label>
  <input type='text' id='name' name='name'>

  <label for='email'>Email</label>
  <input type='text' id='email' name='email'>

  <label for='message'>Message</label>
  <textarea id='message' name='message'></textarea>

  <button type='submit'>Send</button>
</form>

Formulário de Contato com Validação e Etapa de Confirmação — Correto

<!-- Step 1: Form with client-side validation before submission -->
<form id='contact-form' novalidate>
  <div role='group' aria-labelledby='form-heading'>
    <h2 id='form-heading'>Contact Us</h2>

    <div class='field-group'>
      <label for='name'>Full Name <span aria-hidden='true'>*</span></label>
      <input
        type='text'
        id='name'
        name='name'
        required
        aria-required='true'
        aria-describedby='name-error'
        autocomplete='name'
      >
      <span id='name-error' class='error-msg' role='alert' aria-live='assertive'></span>
    </div>

    <div class='field-group'>
      <label for='email'>Email Address <span aria-hidden='true'>*</span></label>
      <input
        type='email'
        id='email'
        name='email'
        required
        aria-required='true'
        aria-describedby='email-error'
        autocomplete='email'
      >
      <span id='email-error' class='error-msg' role='alert' aria-live='assertive'></span>
    </div>

    <div class='field-group'>
      <label for='message'>Message <span aria-hidden='true'>*</span></label>
      <textarea
        id='message'
        name='message'
        required
        aria-required='true'
        aria-describedby='message-error'
      ></textarea>
      <span id='message-error' class='error-msg' role='alert' aria-live='assertive'></span>
    </div>

    <!-- Review button triggers a confirmation summary before final submission -->
    <button type='button' onclick='showReviewScreen()'>Review &amp; Send</button>
  </div>
</form>

<!-- Step 2: Confirmation/review screen (shown after validation passes) -->
<section id='review-screen' hidden aria-labelledby='review-heading'>
  <h2 id='review-heading'>Review Your Message</h2>
  <p>Please review your details before sending. You can go back to make changes.</p>

  <dl>
    <dt>Full Name</dt>
    <dd id='review-name'></dd>
    <dt>Email</dt>
    <dd id='review-email'></dd>
    <dt>Message</dt>
    <dd id='review-message'></dd>
  </dl>

  <!-- Edit option satisfies the 'reversible/correctable before final commit' requirement -->
  <button type='button' onclick='goBackToForm()'>Edit My Details</button>
  <button type='button' onclick='submitFinalForm()'>Confirm and Send</button>
</section>

Assistente de Múltiplas Etapas Sem Etapa de Resumo — Incorreto

<!-- Fails 3.3.6: final step submits directly without allowing user to review previous steps -->
<form action='/register' method='post'>
  <!-- Step 3 of 3 — no ability to review steps 1 and 2 -->
  <h2>Step 3: Payment</h2>
  <label for='card'>Card Number</label>
  <input type='text' id='card' name='card'>
  <button type='submit'>Complete Registration</button>
</form>

Assistente de Múltiplas Etapas com Etapa Final de Revisão — Correto

<!-- Step 4 of 4: Summary review before final submission -->
<section aria-labelledby='summary-heading'>
  <h2 id='summary-heading'>Step 4 of 4: Review Your Registration</h2>
  <p>Please confirm the information below before completing your registration. Use the edit links to correct any errors.</p>

  <h3>Personal Details
    <a href='/register/step-1' aria-label='Edit personal details'>Edit</a>
  </h3>
  <dl>
    <dt>Full Name</dt><dd>Ayşe Kaya</dd>
    <dt>Date of Birth</dt><dd>15/04/1988</dd>
  </dl>

  <h3>Contact Information
    <a href='/register/step-2' aria-label='Edit contact information'>Edit</a>
  </h3>
  <dl>
    <dt>Email</dt><dd>[email protected]</dd>
    <dt>Phone</dt><dd>+90 532 000 0000</dd>
  </dl>

  <h3>Payment
    <a href='/register/step-3' aria-label='Edit payment details'>Edit</a>
  </h3>
  <dl>
    <dt>Card ending</dt><dd>**** 4242</dd>
  </dl>

  <!-- Final submit only after user has reviewed all data -->
  <form action='/register/complete' method='post'>
    <button type='submit'>Confirm and Complete Registration</button>
  </form>
</section>

Formulário com Envio Imediato e Sem Desfazer — Incorreto

<!-- Fails 3.3.6: deletes comment immediately with no undo or confirmation -->
<form action='/comments/42/delete' method='post'>
  <button type='submit'>Delete Comment</button>
</form>

Ação Destrutiva com Caixa de Diálogo de Confirmação — Correto

<!-- Passes 3.3.6: user must confirm before destructive action is executed -->
<button
  type='button'
  aria-haspopup='dialog'
  onclick='openConfirmDialog(42)'
>
  Delete Comment
</button>

<dialog
  id='confirm-delete-dialog'
  aria-labelledby='dialog-title'
  aria-describedby='dialog-desc'
>
  <h2 id='dialog-title'>Delete this comment?</h2>
  <p id='dialog-desc'>
    This action cannot be undone. The comment will be permanently removed.
  </p>
  <form action='/comments/42/delete' method='post'>
    <button type='submit'>Yes, Delete</button>
    <button type='button' onclick='this.closest("dialog").close()'>Cancel</button>
  </form>
</dialog>

Erros Comuns

• Implementar validação, mas não disponibilizá-la para leitores de tela: Exibir mensagens de erro visualmente por meio de mudanças de cor em CSS ou ícones sem associá-las ao campo de entrada usando aria-describedby ou inseri-las em uma região aria-live significa que usuários cegos nunca ouvirão o erro — o formulário parece ter sido enviado com sucesso, embora na verdade permaneça incompleto.
• Tratar a conformidade com 3.3.4 como suficiente para AAA: As equipes frequentemente implementam prevenção de erros apenas para formulários financeiros ou jurídicos (satisfazendo 3.3.4) e presumem que todos os formulários estão cobertos. O critério 3.3.6 exige as mesmas proteções para todos os formulários do site, incluindo inscrições em newsletters, comentários e atualizações de perfil.
• Fornecer uma tela de confirmação somente leitura, sem caminho para edição: Uma página de revisão que exibe os dados enviados, mas oferece apenas um botão "Confirmar" — sem maneira de retornar e corrigir erros — não satisfaz plenamente o espírito do critério e deixa os usuários sem recurso se perceberem um erro durante a revisão.
• Usar window.confirm() como único mecanismo de confirmação: Caixas de diálogo de confirmação nativas do navegador não são acessíveis a todos os usuários e não podem ser estilizadas ou estruturadas para maior clareza. Elas também se comportam de forma inconsistente entre tecnologias assistivas. Use um elemento <dialog> adequado com atributos ARIA apropriados.
• Redefinir todo o formulário em caso de falha de validação em vez de preservar entradas válidas: Quando um usuário envia um formulário com 10 campos e um erro, e o formulário limpa todos os campos, o usuário precisa inserir todos os dados novamente. Isso é particularmente oneroso para usuários com deficiências motoras ou fadiga cognitiva. Sempre preserve os dados válidos e concentre a atenção apenas nos campos com erro.
• Colocar mensagens de resumo de erros fora da área visível ou da ordem de foco do teclado: Um banner de resumo de erros inserido no topo da página após um envio com falha não ajuda usuários que estão focados no meio do formulário. Use aria-live='assertive' no contêiner de resumo e mova o foco para ele programaticamente em caso de falha no envio.
• Marcar botões de confirmação com rótulos vagos como "OK" ou "Sim": Em uma tela de revisão, os botões devem comunicar claramente o que acontecerá. "Confirmar e Enviar Mensagem" é inequívoco; "OK" não é — especialmente para usuários de leitores de tela que podem não ter o contexto visual ao redor disponível.
• Presumir que a validação no lado do servidor sozinha satisfaz o critério: Se a validação no lado do cliente estiver ausente, cada envio exige uma ida completa ao servidor antes que o usuário saiba de um erro. Usuários em conexões lentas ou que perdem a rede durante o envio podem ficar em um estado incerto, sem feedback de erro claro.
• Não testar o mecanismo de reversibilidade em condições realistas: As equipes às vezes implementam uma opção de "cancelar" em um e-mail de confirmação, mas nunca testam se o link de cancelamento é acessível, se funciona após o prazo expirar ou se o link é utilizável por leitores de tela. Um mecanismo de desfazer inacessível não satisfaz o critério.
• Falhar em lidar com casos extremos de preenchimento automático em telas de revisão: Quando o preenchimento automático do navegador ou do gerenciador de senhas preenche campos de formulário, os valores exibidos em uma tela de revisão podem não corresponder ao que foi realmente enviado se o JavaScript que preenche a revisão extrair do DOM antes de o preenchimento automático ser concluído. Sempre obtenha os valores imediatamente antes de renderizar a tela de revisão, não no carregamento inicial da página.

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 obrigatórias de acessibilidade digital para uma ampla gama de entidades que operam na Turquia. A circular exige que as organizações abrangidas estejam em conformidade com WCAG 2.2 em Nível AA como linha de base. As entidades explicitamente abrangidas incluem instituições e agências públicas, plataformas de comércio eletrônico, 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 privadas e escolas privadas autorizadas pelo Ministério da Educação Nacional (MoNE).

WCAG 3.3.6 é um critério de Nível AAA e, portanto, não é um requisito legal direto sob a Circular 2025/10. No entanto, sua importância no contexto regulatório turco não deve ser descartada. Vários dos tipos de entidades abrangidas — particularmente bancos, plataformas de comércio eletrônico e prestadores de serviços de saúde — operam formulários transacionais de alto risco em que a prevenção de erros não é apenas uma boa prática, mas uma necessidade legal e ética. Um formulário de transferência de dinheiro de um banco turco, um sistema de agendamento de consultas de um portal de saúde ou um fluxo de checkout de comércio eletrônico que carece de etapas de confirmação ou mecanismos de correção de erros pode não violar 3.3.6 em um sentido legalmente aplicável, mas cria risco significativo de dano para usuários com deficiência e expõe a organização a risco reputacional e operacional.

Além disso, a circular sinaliza uma trajetória clara em direção ao aumento dos requisitos de acessibilidade ao longo do tempo, consistente com o quadro do Ato Europeu de Acessibilidade (EAA) com o qual a Turquia vem se alinhando. Organizações que implementam critérios AAA como 3.3.6 hoje estão proativamente posicionadas para um endurecimento regulatório futuro e demonstram um compromisso com design inclusivo que vai além da conformidade mínima. Para entidades como hospitais privados e instituições financeiras que atendem populações idosas ou usuários com deficiências cognitivas e motoras em taxas desproporcionalmente altas, implementar 3.3.6 em todos os formulários é uma decisão sólida de gestão de risco, independentemente de seu status legal. O SDK de overlay da Accsible pode ajudar a exibir mensagens de erro, reforçar estados de validação e fornecer prompts de confirmação suplementares como uma camada de proteção aprimorada para organizações turcas que buscam liderar em acessibilidade.