WCAG 3.3.3: Sugestão de Erro

O Que Esta Regra Significa

WCAG 3.3.3 Sugestão de Erro é um critério de Nível AA sob o princípio Compreensível. Ele se baseia diretamente em 3.3.1 (Identificação de Erro), que exige que os erros sejam identificados em texto. Sugestão de Erro vai além: quando um erro de entrada é detectado automaticamente, a interface também deve sugerir como o usuário pode corrigi-lo, desde que essa sugestão não comprometa a segurança ou o propósito do conteúdo.

A distinção fundamental aqui é entre identificação de erro e sugestão de erro. Dizer a um usuário "Sua data de nascimento é inválida" é identificação. Dizer a um usuário "Sua data de nascimento é inválida — insira uma data no formato DD/MM/AAAA" é uma sugestão. Ambos são exigidos sob seus respectivos critérios, mas Sugestão de Erro exige que orientações corretivas e acionáveis acompanhem a mensagem de erro sempre que viável.

O critério se aplica sempre que um erro de entrada é detectado automaticamente — isto é, quando a lógica de validação do lado do cliente ou do servidor determina que um valor enviado ou inserido não atende aos critérios esperados. Aplica-se a todos os controles de formulário: campos de texto, selects, checkboxes, botões de opção, seletores de data, campos de upload de arquivo e qualquer componente interativo que colete dados do usuário.

O que conta como aprovação: A mensagem de erro é apresentada em texto (não apenas por meio de cor ou ícone), identifica claramente o campo com erro e fornece orientação específica sobre como corrigi-lo. Por exemplo: "A senha deve ter pelo menos 8 caracteres e incluir uma letra maiúscula" em vez de apenas "Senha inválida." A sugestão deve aparecer próxima ao campo, ser associada programaticamente a ele (via aria-describedby ou similar) e ser perceptível por tecnologias assistivas.

O que conta como reprovação: Qualquer mensagem de erro que apenas declare que ocorreu um erro sem explicar o que está errado ou como corrigi-lo. Mensagens genéricas como "Erro", "Entrada inválida" ou "Campo obrigatório" sem contexto adicional falham neste critério. Erros comunicados apenas por meio de uma borda vermelha ou ícone de aviso, sem texto descritivo, também falham.

Exceções definidas: O critério inclui duas exceções explícitas em que uma sugestão não é exigida. Primeiro, se fornecer a sugestão colocaria em risco a segurança — por exemplo, em um formulário de login em que explicar exatamente por que uma senha falhou (senha errada vs. nome de usuário errado) poderia ajudar ataques de força bruta. Segundo, se fornecer a sugestão comprometeria o propósito do conteúdo — por exemplo, um quiz educacional em que revelar a resposta correta anula o objetivo da avaliação. Essas exceções são estreitas e não devem ser usadas para evitar a exigência em contextos de formulários padrão.

Por Que Isso Importa

Sugestão de Erro existe porque preencher formulários é uma das atividades cognitivamente mais exigentes que os usuários realizam na web, e também uma das mais consequentes — erros em formulários de checkout, pedidos de benefícios governamentais, formulários de admissão médica ou portais bancários podem ter consequências no mundo real para usuários que não conseguem entender o que deu errado ou como se recuperar.

Deficiências cognitivas: Usuários com dislexia, TDAH, dificuldades de aprendizagem ou letramento limitado podem ter dificuldade para decodificar mensagens de erro vagas e conectá-las ao campo específico ou formato exigido. Sem uma sugestão corretiva clara, podem abandonar o formulário completamente ou enviar informações incorretas. De acordo com a Organização Mundial da Saúde, aproximadamente 1 em cada 6 pessoas globalmente — mais de 1,3 bilhão — vive com algum tipo de deficiência, e deficiências cognitivas estão entre as categorias mais prevalentes e menos acomodadas.

Usuários cegos e com baixa visão: Usuários de leitores de tela dependem inteiramente de descrições em texto para entender erros de validação. Quando uma mensagem de erro diz apenas "Inválido" e não fornece sugestão, o usuário não tem mecanismo para determinar o que "inválido" significa para aquele campo. Eles não podem olhar para rótulos adjacentes, texto de placeholder ou pistas de formatação visual para inferir o formato esperado. Uma sugestão clara, associada programaticamente à entrada via aria-describedby, é o único canal de informação confiável.

Usuários com deficiência motora: Usuários que dependem de acesso por varredura, controle por voz ou dispositivos de entrada alternativos enfrentam esforço físico significativo ao preencher formulários. Ter que voltar a navegar até um formulário após um envio falho — sem entender o que precisa ser alterado — impõe um custo desproporcional. Sugestões claras reduzem o esforço de reentrada e o número de ciclos de envio falho.

Falantes não nativos e usuários mais velhos: Usuários que não são fluentes no idioma do formulário, ou que têm menos experiência com convenções da web, também se beneficiam substancialmente de sugestões corretivas explícitas. Uma mensagem como "Digite seu número de telefone sem espaços ou traços, por exemplo 05321234567" remove a ambiguidade para usuários que, de outra forma, talvez nunca conseguissem concluir o formulário com sucesso.

Cenário do mundo real: Considere um cidadão turco solicitando um benefício de assistência social por meio de um portal de governo eletrônico. A solicitação exige um TR Identity Number (TC Kimlik Numarası), um formato específico de 11 dígitos. Se o usuário inserir 10 dígitos e receber apenas a mensagem "TC Kimlik Numarası hatalı" (TC Identity Number está incorreto), um usuário com deficiência cognitiva, idoso ou usuário de leitor de tela pode não saber se o número é curto demais, contém um caractere inválido ou tem um problema de formatação. Adicionar "TC Kimlik Numarası 11 haneli olmalıdır, örneğin: 12345678901" (TC Identity Number deve ter 11 dígitos, por exemplo: 12345678901) resolve imediatamente a ambiguidade e permite que o usuário se autocorrija.

Benefícios de usabilidade e conversão: Além da acessibilidade, o abandono de formulários é uma métrica de negócios crítica. Pesquisas mostram consistentemente que mensagens de erro pouco claras estão entre as principais razões pelas quais usuários abandonam checkouts de e-commerce e fluxos de registro. Sugestões de erro específicas e acionáveis reduzem as taxas de abandono de formulários e melhoram as taxas de conclusão para todos os usuários — tornando este critério um forte argumento de negócios, bem como uma exigência de acessibilidade.

Regras Relacionadas do Axe-core

WCAG 3.3.3 exige testes manuais porque ferramentas automatizadas não podem avaliar a qualidade ou completude do texto da mensagem de erro. Um scanner automatizado pode detectar que existe uma mensagem de erro e que ela está associada programaticamente a um campo de formulário, mas não pode determinar se a mensagem realmente fornece uma sugestão corretiva útil. Isso exige julgamento humano para avaliar se o texto é específico, acionável e suficiente para orientar o usuário em direção a uma entrada válida.

• Revisão manual — qualidade do conteúdo da mensagem de erro: Testadores devem acionar manualmente cada condição de validação (enviar um campo obrigatório vazio, inserir dados no formato errado, exceder limites de caracteres, etc.) e avaliar cada mensagem de erro resultante. O testador pergunta: esta mensagem diz ao usuário não apenas que ocorreu um erro, mas especificamente o que ele deve fazer para corrigi-lo? Se a mensagem for genérica ("Inválido", "Erro", "Verifique este campo"), ela falha em 3.3.3 independentemente de estar exposta programaticamente.
• Revisão manual — associação programática: Testadores devem verificar se o texto de sugestão de erro está vinculado programaticamente ao campo de entrada relevante usando aria-describedby, regiões aria-live ou associação inline, para que leitores de tela o anunciem sem exigir navegação adicional. Isso se sobrepõe parcialmente a regras do axe como label e aria-input-field-name, mas o próprio texto da sugestão não é verificado por essas regras.
• Revisão manual — validade da exceção de segurança: Testadores devem verificar se qualquer formulário que omita sugestões corretivas por motivos de segurança (por exemplo, formulários de login) realmente se qualifica sob a exceção de segurança, e se essa exceção não está sendo usada para evitar a exigência em campos não sensíveis.
• Parcialmente automatizado — regra label: Embora a regra label do axe-core verifique se entradas de formulário têm nomes acessíveis, ela não verifica se mensagens de erro fornecem sugestões corretivas. Ela pode revelar rótulos ausentes que agravariam o problema de sugestão de erro, e corrigir problemas de rótulo é um pré-requisito para uma implementação eficaz de sugestão de erro.

Como Testar

1. Base de varredura automatizada: Execute axe DevTools ou Lighthouse na página que contém o formulário. Observe quaisquer violações existentes relacionadas a rótulos de formulário, papéis ARIA ou identificação de erro (3.3.1). Estes devem ser resolvidos primeiro, pois são pré-requisitos para uma sugestão de erro eficaz. Varreduras automatizadas não sinalizarão sugestões ausentes — elas estabelecem apenas a base estrutural.
2. Acione todas as condições de validação: Para cada campo de formulário, acione deliberadamente todos os possíveis estados de erro: envie um campo obrigatório vazio, insira dados em um formato incorreto (formato de data errado, e-mail inválido, senha muito curta, valor não numérico em um campo numérico) e exceda quaisquer limites de caracteres. Documente cada mensagem de erro que aparecer.
3. Avalie a qualidade da sugestão: Para cada mensagem de erro, pergunte: (a) Ela identifica o campo específico? (b) Ela explica o que está errado? (c) Ela fornece orientação acionável sobre como corrigir a entrada? Uma mensagem que responde às três passa em 3.3.3. Uma mensagem que responde apenas a (a) passa em 3.3.1, mas falha em 3.3.3.
4. Teste com leitor de tela usando NVDA + Firefox: Navegue até o formulário usando Tab. Preencha com um valor inválido. Envie ou mova o foco. Ouça o que o NVDA anuncia. Verifique se o texto de sugestão de erro é lido em voz alta automaticamente (via região aria-live ou gerenciamento de foco para o erro) sem exigir que o usuário o procure manualmente.
5. Teste com leitor de tela usando VoiceOver + Safari (macOS/iOS): Execute os mesmos passos. Use VO+seta para a direita para ler o campo e sua descrição associada. Confirme que o texto da sugestão é anunciado como parte da descrição acessível do campo, não apenas como texto próximo que pode ser ignorado.
6. Teste com leitor de tela usando JAWS + Chrome: Após enviar um formulário com erros, confirme se o JAWS lê a sugestão de erro por meio do gerenciamento de foco (foco movido para o resumo de erros) ou por meio de atualizações de região aria-live. Use o cursor virtual do JAWS para navegar até o campo e confirme se a sugestão faz parte da descrição do campo.
7. Navegação apenas por teclado: Sem um leitor de tela, navegue pelo formulário usando apenas Tab, Shift+Tab e Enter. Verifique se as sugestões de erro estão visíveis na área de visualização, não escondidas fora da tela ou encobertas por outros elementos, quando o campo recebe foco após um envio falho.
8. Verifique as exceções de segurança: Para formulários de login e autenticação, confirme se a omissão de sugestões específicas é intencional e documentada, e se a exceção de segurança está limitada ao mínimo necessário de campos.

Como Corrigir

Mensagem de erro genérica — Incorreto

<!-- A mensagem de erro não fornece sugestão sobre como corrigir o problema -->
<label for='email'>Email Address</label>
<input type='email' id='email' name='email' aria-invalid='true' />
<span class='error'>Invalid email address.</span>

Mensagem de erro genérica — Correto

<!-- aria-describedby vincula o texto da sugestão à entrada;
     a sugestão explica exatamente qual formato é esperado -->
<label for='email'>Email Address</label>
<input
  type='email'
  id='email'
  name='email'
  aria-invalid='true'
  aria-describedby='email-error'
/>
<span id='email-error' class='error' role='alert'>
  Please enter a valid email address in the format [email protected].
</span>

Validação de senha sem orientação de formato — Incorreto

<!-- O usuário é informado de que a senha está errada, mas não por quê ou como corrigi-la -->
<label for='password'>Create Password</label>
<input type='password' id='password' name='password' aria-invalid='true' />
<p class='error'>Password is not valid.</p>

Validação de senha sem orientação de formato — Correto

<!-- A sugestão lista exatamente o que a senha deve conter,
     permitindo que o usuário se autocorrija sem adivinhações -->
<label for='password'>Create Password</label>
<input
  type='password'
  id='password'
  name='password'
  aria-invalid='true'
  aria-describedby='password-error'
/>
<span id='password-error' class='error' role='alert'>
  Password must be at least 8 characters and include at least one
  uppercase letter, one number, and one special character (e.g. !, @, #).
</span>

Campo de data com erro de formato ambíguo — Incorreto

<!-- Nenhuma indicação de qual formato de data é esperado -->
<label for='dob'>Date of Birth</label>
<input type='text' id='dob' name='dob' aria-invalid='true' />
<span class='error'>Date is incorrect.</span>

Campo de data com erro de formato ambíguo — Correto

<!-- A sugestão declara o formato exigido e fornece
     um exemplo concreto, removendo toda ambiguidade -->
<label for='dob'>Date of Birth</label>
<input
  type='text'
  id='dob'
  name='dob'
  aria-invalid='true'
  aria-describedby='dob-error'
  placeholder='DD/MM/YYYY'
/>
<span id='dob-error' class='error' role='alert'>
  Please enter your date of birth in DD/MM/YYYY format, for example
  15/03/1985.
</span>

Formulário com vários campos e resumo de erros no lado do servidor — Incorreto

<!-- O resumo de erros existe, mas os links não associam sugestões
     a campos individuais, e as mensagens são vagas -->
<div class='error-summary'>
  <p>Please correct the following errors:</p>
  <ul>
    <li>Name error</li>
    <li>Phone error</li>
  </ul>
</div>

Formulário com vários campos e resumo de erros no lado do servidor — Correto

<!-- O resumo de erros inclui sugestões específicas com links;
     cada item da lista aponta para o campo relevante;
     erros inline também aparecem ao lado de cada campo -->
<div class='error-summary' role='alert' aria-labelledby='error-heading'>
  <h2 id='error-heading'>There are 2 errors on this form</h2>
  <ul>
    <li>
      <a href='#full-name'>
        Full Name: Please enter your first and last name.
      </a>
    </li>
    <li>
      <a href='#phone'>
        Phone Number: Enter 10 digits without spaces, e.g. 05321234567.
      </a>
    </li>
  </ul>
</div>

<label for='full-name'>Full Name</label>
<input
  type='text'
  id='full-name'
  name='full-name'
  aria-invalid='true'
  aria-describedby='full-name-error'
/>
<span id='full-name-error' class='error'>
  Please enter your first and last name.
</span>

<label for='phone'>Phone Number</label>
<input
  type='tel'
  id='phone'
  name='phone'
  aria-invalid='true'
  aria-describedby='phone-error'
/>
<span id='phone-error' class='error'>
  Enter 10 digits without spaces or dashes, for example 05321234567.
</span>

Erros Comuns

• Usar placeholder como substituto para sugestões de erro: O texto de placeholder desaparece assim que o usuário começa a digitar e não é anunciado de forma confiável por leitores de tela como um erro. Nunca dependa apenas do texto de placeholder para comunicar qual formato é exigido depois que um erro ocorreu.
• Exibir mensagens de erro apenas em uma notificação toast que desaparece após alguns segundos: Notificações transitórias não são perceptíveis para todos os usuários — usuários de leitores de tela podem perder o anúncio, e a mensagem some antes que um leitor lento possa processá-la. Sugestões de erro devem persistir até que o erro seja corrigido.
• Usar aria-invalid='true' sem aria-describedby apontando para o texto da sugestão: Definir aria-invalid sinaliza que um campo tem um erro, mas sem aria-describedby vinculando ao elemento de sugestão, leitores de tela não lerão o texto da sugestão quando o campo receber foco.
• Fornecer a sugestão apenas no design visual (por exemplo, um tooltip ao passar o mouse) e não no DOM: Tooltips apenas ao passar o mouse são inacessíveis para usuários de teclado e usuários de leitores de tela. O texto da sugestão deve estar presente no DOM e associado programaticamente ao campo.
• Usar apenas cor ou ícones para indicar qual campo tem erro: Uma borda vermelha ou ícone de aviso não constitui uma sugestão de erro. A sugestão deve ser uma descrição em texto que explique a ação corretiva, não um indicador visual.
• Escrever sugestões que identificam o problema, mas não a solução: "Sua senha é muito curta" identifica o erro, mas não sugere uma correção. "Sua senha deve ter pelo menos 8 caracteres" fornece a orientação corretiva necessária. Ambas as partes são exigidas para conformidade com 3.3.3.
• Aplicar a exceção de segurança de forma muito ampla: A exceção de segurança se aplica de forma restrita a situações em que fornecer uma sugestão comprometeria genuinamente a segurança — tipicamente limitado a campos de autenticação. Ela não se aplica a campos padrão de formulário como nomes, endereços ou números de telefone, em que erros genéricos são injustificados.
• Colocar a sugestão de erro depois do botão de envio ou longe do campo: Sugestões de erro devem ser visual e programaticamente próximas ao campo que descrevem. Colocar todos os erros na parte inferior de um formulário longo, sem também incluir sugestões inline em cada campo, força os usuários a alternar contexto e lembrar qual sugestão se aplica a qual campo.
• Não mover o foco para o resumo de erros após um envio falho no lado do servidor: Quando uma página recarrega após um envio falho, o foco normalmente retorna ao topo da página. Sem gerenciamento programático de foco para o resumo de erros ou para o primeiro campo com erro, usuários de leitores de tela precisam navegar por toda a página para descobrir o que deu errado.
• Usar linguagem vaga como "Verifique sua entrada" ou "Algo deu errado": Essas mensagens não fornecem informação sobre o que está errado ou como corrigir. Cada sugestão de erro deve ser específica para o campo e para a regra de validação específica que foi violada.

Relação com os Regulamentos de Acessibilidade da Turquia

O cenário de acessibilidade da Turquia avançou significativamente com a Circular Presidencial 2025/10, publicada no Diário Oficial nº 32933 em 21 de junho de 2025. Esta circular estabelece requisitos obrigatórios de acessibilidade web e móvel alinhados com WCAG 2.2, com conformidade de Nível AA exigida para entidades que buscam o Erişilebilirlik Logosu (Logotipo de Acessibilidade) emitido pelo Ministério da Família e Serviços Sociais (Aile ve Sosyal Hizmetler Bakanlığı).

WCAG 3.3.3 Sugestão de Erro, como critério de Nível AA, está dentro do escopo deste requisito obrigatório. Qualquer entidade abrangida que opere formulários — para registro, pagamento, solicitações de serviço ou gerenciamento de conta — deve garantir que suas mensagens de erro não apenas identifiquem erros, mas forneçam sugestões corretivas acionáveis, conforme descrito neste critério.

As entidades abrangidas pela Circular Presidencial 2025/10 abrangem uma ampla gama de setores. Instituições públicas e órgãos governamentais são obrigados a cumprir, o que significa que todos os portais de governo eletrônico (por exemplo, serviços e-Devlet, portais municipais, sistemas de solicitação de benefícios) devem fornecer implementações de sugestão de erro em conformidade. Dado que muitos serviços governamentais exigem que cidadãos enviem dados pessoais complexos — números de identidade, códigos de endereço, números de imposto — sugestões de erro claras são especialmente críticas neste contexto.

Bancos e instituições financeiras estão incluídos, abrangendo plataformas de banco online, formulários de registro de conta de investimento e portais de solicitação de empréstimo. Esses formulários rotineiramente coletam dados sensíveis e com formato preciso, e a ausência de sugestões corretivas cria barreiras reais para clientes com deficiência e potencial exposição legal.

Hospitais e prestadores de serviços de saúde também devem cumprir, abrangendo sistemas de registro de pacientes, formulários de agendamento de consultas e portais de solicitação de seguro. Formulários médicos frequentemente envolvem requisitos de campo complexos (códigos de diagnóstico, números de apólice de seguro, formatos de data precisos), tornando sugestões de erro claras especialmente importantes para pacientes idosos e com deficiência cognitiva.

Empresas de telecomunicações com 200.000 ou mais assinantes estão incluídas, abrangendo portais de clientes de grandes operadoras, formulários de registro de SIM e interfaces de gerenciamento de conta. Plataformas de e-commerce — incluindo fluxos de checkout e registro de conta — devem cumprir, tornando Sugestão de Erro diretamente relevante para formulários de gerenciamento de produtos e carrinho que são centrais para suas operações de negócios.

Agências de viagem, empresas de transporte privado e escolas privadas autorizadas pelo Ministério da Educação Nacional (MoNE) também estão dentro do escopo. Formulários de reserva, solicitações de matrícula e interfaces de pagamento operadas por essas entidades devem atender aos padrões de Nível AA, incluindo 3.3.3.

De uma perspectiva prática de conformidade, organizações que buscam o Erişilebilirlik Logosu devem tratar WCAG 3.3.3 como um ponto-chave de auditoria durante qualquer avaliação de acessibilidade. Testes manuais de todos os fluxos de validação de formulários — incluindo estados de erro tanto do lado do cliente quanto do lado do servidor — são exigidos, e a documentação da justificativa da exceção de segurança deve ser mantida para quaisquer campos em que sugestões corretivas sejam intencionalmente omitidas. O não atendimento aos requisitos de Nível AA, incluindo Sugestão de Erro, impedirá a concessão do logotipo e pode expor entidades abrangidas a consequências administrativas sob a circular.