Validação de formulários

Métodos de Interação

Interação com mouse

1. Ao enviar dados inválidos, apresentar mensagens específicas junto aos campos e, quando adequado, um resumo com links para correção.
2. Clicar em um link do resumo leva ao campo correspondente na mesma página e posiciona o foco para corrigi-lo.
3. Preservar os dados preenchidos, inclusive os que precisam de correção.

Interação com teclado

1. Tab e Shift + Tab percorrem campos, botão de envio e links do resumo na ordem da interface.
2. Enter ou Barra de espaço ativa o botão de envio; Enter ativa os links do resumo.
3. Após um envio rejeitado, posicionar o foco no resumo ou no primeiro campo inválido, conforme o padrão escolhido.
4. Durante validações ao sair do campo ou durante a edição, manter o fluxo de foco e a entrada de texto.

Interação com gestos

1. Tocar no botão de envio permite validar o formulário.
2. Tocar no link do resumo leva ao campo; a mensagem continua disponível para consulta e correção.

Interação com teclado (ou gestos) + leitor de telas

1. Ao navegar até um campo inválido, apresentar rótulo, indicação de erro e mensagem associada por aria-describedby, preservando também a associação com as instruções.
2. Usar aria-invalid para indicar erro detectado; atualizar o estado quando o erro for corrigido e a nova validação confirmar a correção.
3. Se o foco for movido para um resumo, permitir a leitura de seu título, erros e links. Se o foco permanecer onde estava, anunciar erros dinâmicos com uma região de atualização adequada ao contexto.
4. Evitar anunciar a mesma mensagem simultaneamente pelo foco e por várias regiões aria-live.

Correção e novo envio

1. Após uma correção confirmada, remover ou atualizar a mensagem e a entrada correspondente no resumo, sem apagar outros erros.
2. Enviar novamente executa a validação necessária; somente confirmar sucesso depois que a operação for concluída.
3. Em verificações assíncronas, informar o andamento e evitar que respostas antigas substituam o resultado do valor atual.

Gherkin

Metodologia BDD (Behavior-Driven Development ou Desenvolvimento Orientado ao Comportamento) com foco em 3 pilares: Histórias de Usuário, Critérios de Aceite e Sintaxes Gherkin (Dado (Given), Quando (When), Então (Then)).

Cenário: Considerando que estou em uma página que contém um formulário com validação

Navegação por teclado

1. QUANDO uso Tab para mover o foco até o botão de envio
2. O foco que VEJO é fortemente indicado visualmente
3. ENTÃO, quando uso Enter ou Barra de espaço para enviar dados inválidos
4. VEJO mensagens que identificam os campos com erro e explicam como corrigir
5. E percebo que o foco foi direcionado ao resumo ou ao primeiro campo inválido, conforme o padrão definido
6. QUANDO uso Tab para focar um link do resumo e Enter para ativá-lo
7. VEJO que o foco chega ao campo correspondente na mesma página e posso corrigi-lo

Leitor de telas para desktop

1. QUANDO uso um leitor de tela no computador (NVDA, JAWS, VoiceOver) e envio um formulário com dados inválidos
2. OUÇO ou percebo que o envio não foi concluído e que existem erros a corrigir
3. ENTÃO, quando uso Tab para navegar até um campo inválido
4. OUÇO o rótulo, a indicação de erro e a orientação de correção
5. E, quando uso Enter para ativar um link do resumo, percebo que cheguei ao campo correspondente
6. OUÇO ou percebo as mensagens sem anúncios duplicados desnecessários

Leitor de telas para dispositivos móveis

1. QUANDO uso um leitor de tela no celular (Talkback, VoiceOver) e envio um formulário com dados inválidos
2. OUÇO ou percebo que o envio não foi concluído e que existem erros a corrigir
3. ENTÃO, quando deslizo o dedo para navegar até um campo inválido
4. OUÇO o rótulo, a indicação de erro e a orientação de correção
5. E, quando toco duas vezes ou uso o gesto adequado para ativar um link do resumo, percebo que cheguei ao campo correspondente
6. OUÇO ou percebo as mensagens sem anúncios duplicados desnecessários

Correção e novo envio

1. QUANDO corrijo um campo e a nova validação confirma a correção
2. VEJO que a mensagem e o estado inválido daquele campo são atualizados, preservando os outros erros e os valores preenchidos
3. ENTÃO, quando envio o formulário com todas as entradas válidas
4. VEJO ou OUÇO a confirmação somente depois que a operação for concluída

Validação durante a edição

1. QUANDO uma validação ocorre ao sair de um campo ou durante uma verificação específica
2. VEJO ou OUÇO uma mensagem no momento definido, sem erro prematuro antes de preencher
3. E percebo que o foco e a digitação não foram interrompidos

Pontos de atenção

1. Preferir mensagens concretas, como "Informe um e-mail no formato nome@exemplo.com", em vez de apenas "Valor inválido".
2. Distinguir campo vazio obrigatório, formato incorreto e regra de negócio. Não tratar uma falha de conexão ou indisponibilidade do serviço como erro de preenchimento.
3. Não depender apenas de bordas vermelhas, ícones ou mensagens temporárias. Manter a orientação até que a correção seja confirmada.
4. Associar o erro ao campo com aria-describedby e manter as instruções existentes nessa associação. Usar aria-invalid apenas quando o erro for detectado.
5. O resumo complementa as mensagens junto aos campos. Seus links devem indicar para leitores de tela que levam ao campo na mesma página e mover o foco para o destino adequado.
6. Escolher entre o anúncio pelo foco e uma região dinâmica conforme o fluxo. Usar role="alert" apenas quando a urgência justificar; role="status" pode servir para atualizações não urgentes. Evitar anúncios a cada tecla.
7. Preservar valores após um envio inválido. Não incluir senhas ou outros dados sensíveis no resumo ou em mensagens de estado.
8. A validação no cliente ajuda a orientar, mas a validação no servidor continua necessária. Verificações assíncronas devem considerar o valor atual e informar falhas da verificação.
9. Não desabilitar o botão de envio como única forma de indicar problemas: a pessoa precisa saber o que falta e como corrigir.
10. Se usar ícones complementares, preferir Material Icons e ocultar os decorativos das tecnologias assistivas; a informação deve continuar disponível em texto.
11. Bootstrap informa limitações de acessibilidade nos estilos personalizados de validação do cliente e tooltips. Avaliar os exemplos antes de adotá-los; cores e estilos não garantem associação ou anúncio acessível.

Referências

Padrões de Design

• W3C WAI — User Notification open_in_new (link externo, abre em uma nova aba) — Erros, notificações e retorno após envio de formulários.

Design System

• GOV.UK — Error message open_in_new (link externo, abre em uma nova aba) — Mensagens associadas aos campos e orientações de correção.
• GOV.UK — Error summary open_in_new (link externo, abre em uma nova aba) — Resumo de erros, links para os campos e gerenciamento de foco.
• USWDS — Validation open_in_new (link externo, abre em uma nova aba) — Validação e retorno sobre requisitos de entrada.
• Bootstrap — Validation open_in_new (link externo, abre em uma nova aba) — Exemplos de validação e limitações de acessibilidade documentadas.