Um formulário é onde o visitante para de ler e começa a agir: se inscrever na conferência, renovar uma filiação, pedir um auxílio, fazer uma pergunta.
Cada um desses visitantes já tinha decidido agir. Quando sai sem enviar, foi o formulário que o fez desistir.
Este guia percorre as decisões que fazem a diferença, na ordem em que o visitante as encontra. Cada seção tem um exemplo que funciona e em que você pode digitar. Os exemplos rodam no seu navegador e não enviam nada, e cada padrão daqui também roda nos formulários deste site.
Por que agora é um guia só. Ele começou como uma série de oito partes. Nós a reunimos numa única página com exemplos ao vivo, porque se aprende mais sobre um formulário preenchendo um do que lendo sobre ele.
É o primeiro dos nossos artigos a receber esse tratamento. Estamos revisando tudo o que publicamos para deixar mais curto, mais fácil de percorrer e mais prático.
Quer ver os erros primeiro? As versões quebradas têm formulários ao vivo que falham de propósito.
Todo campo precisa de um rótulo visível
Um rótulo fica fora do campo e permanece lá. Um texto de exemplo (placeholder) fica dentro do campo e desaparece assim que alguém digita.
Formulários que usam o texto de exemplo como rótulo parecem limpos num protótipo, que é o único momento em que alguém os vê vazios. Depois de preenchidos, as perguntas somem:
- Um visitante que confere as respostas antes de enviar não tem com o que compará-las.
- Quem é interrompido por um telefonema volta para caixas que já não dizem o que são.
- O preenchimento automático completa todos os campos de uma vez, e conferir vira todo o trabalho do visitante. Teste no exemplo abaixo: os rótulos ficam, então conferir leva um olhar.
Exemplo ao vivo
Campos com rótulo, depois do preenchimento automático
Este exemplo roda no seu navegador. Nada do que você digita é enviado. Experimente a versão quebrada.
O texto de exemplo ainda tem uma função: mostrar o formato de uma resposta. O rótulo pergunta “Telefone” e o texto de exemplo mostra (555) 012-3456. Quando o exemplo some, o visitante já não precisa dele.
Para quem usa leitor de tela, um rótulo ligado ao campo no código é anunciado quando o campo recebe o foco. O anúncio do texto de exemplo varia, e ele nunca foi feito para ser o nome de um campo.
Para órgãos e instituições públicas, um rótulo visível também é exigido pela norma de acessibilidade que eles precisam cumprir, e quem avalia as contratações verifica isso.
Não conte com um verificador automático para pegar este problema. As regras que a maioria das ferramentas aplica aceitam o texto de exemplo como nome do campo, então um formulário só com textos de exemplo pode passar na verificação. Nós conferimos: a versão quebrada deste formulário passa nas mesmas regras automáticas que reprovam o menu e o botão de envio dela.
Rótulos flutuantes, bem construídos
Um rótulo flutuante começa dentro do campo, onde ficaria um texto de exemplo. Ele sobe para cima do campo quando o visitante o seleciona ou digita uma resposta.
Ele economiza uma linha de altura num formulário longo, e pode ser bem feito. Bem feito significa três coisas:
- É um rótulo de verdade ligado ao campo, então é anunciado como qualquer outro.
- Continua legível nas duas posições, com contraste total, nunca desbotado para o cinza do texto de exemplo.
- Sai do caminho antes que o texto do visitante possa se sobrepor a ele.
Exemplo ao vivo
Um rótulo flutuante que continua legível
Este exemplo roda no seu navegador. Nada do que você digita é enviado.
A maioria dos rótulos flutuantes decide se deve subir fazendo uma única pergunta: o campo está vazio? O truque de CSS habitual verifica se o texto de exemplo está aparecendo.
Essa pergunta recebe a resposta errada assim que entra uma máscara de entrada.
Quando uma máscara de entrada preenche o campo
Uma máscara de entrada formata a resposta enquanto ela é digitada: um telefone vira (703) 555-0142, uma data vira 10/11/2026.
As máscaras ajudam, até que os caracteres da máscara sejam escritos no campo antes de alguém digitar. Aí o campo nunca está vazio, e três coisas quebram:
- Um rótulo flutuante vê (___) ___-____, conclui que há uma resposta e sobe quando a página carrega, ou fica por cima da máscara.
- A própria validação do formulário vê texto e pode deixar passar um telefone em branco.
- Um leitor de tela lê os sublinhados em voz alta.
Exemplo ao vivo
Uma máscara de telefone que sabe quando o campo está vazio
Este exemplo roda no seu navegador. Nada do que você digita é enviado. Experimente a versão quebrada.
Como construir uma máscara que funciona:
- Conte dígitos, não caracteres. O campo está vazio até ter um dígito. A pontuação que a máscara acrescentou nunca é uma resposta.
- Mostre o modelo só enquanto o campo estiver selecionado, atrás do texto do visitante e fora do valor. O rótulo sobe primeiro, então nada se sobrepõe.
- Aceite qualquer formato. Alguém cola 703.555.0142 ou digita com espaços. Fique com os dígitos e formate você mesmo.
- Mantenha o cursor onde o visitante o colocou. Uma máscara que joga o cursor para o fim transforma cada correção em redigitação.
- Deixe passar números internacionais. Um + no início deve desligar a máscara dos EUA. Uma máscara rígida é o motivo pelo qual pessoas de outros países não conseguem se inscrever.
- Guarde os dígitos, não o texto formatado. O registro deve conter 7035550142, para que a busca, a remoção de duplicados e o próximo sistema concordem sobre qual é o número.
Peça o teclado certo
No celular, o tipo do campo decide qual teclado aparece:
- Um campo de e-mail coloca o @ na primeira tela.
- Um campo de telefone abre um teclado numérico.
- Um campo de texto genérico dá ao visitante o teclado completo para tudo, e ele precisa procurar nas telas de símbolos para digitar um endereço.
Exemplo ao vivo
O teclado certo para cada campo
Este exemplo roda no seu navegador. Nada do que você digita é enviado.
Mostrar o código Ocultar o código HTML, 4 linhas
<input type="email" autocomplete="email" autocapitalize="off" spellcheck="false">
<input type="tel" autocomplete="tel">
<input inputmode="numeric" autocomplete="postal-code">
<input inputmode="decimal">Os mesmos atributos alimentam o preenchimento automático. Quando os campos dizem o que contêm (nome, e-mail, organização, CEP), o navegador oferece preenchê-los, e a parte mais lenta de um formulário no celular vira um toque.
Os teclados de celular também colocam a primeira letra em maiúscula e corrigem palavras que não conhecem. Isso ajuda numa caixa de mensagem. Num endereço de e-mail ou num número de referência, muda a resposta sem ninguém perceber, então desligue a maiúscula automática e a correção automática nos campos que guardam identificadores.
O tamanho importa tanto quanto o teclado:
- Faça áreas de toque com pelo menos 44 pixels de altura.
- Ligue o rótulo de cada caixa de seleção, para que as palavras também possam ser tocadas.
- Mantenha o texto dos campos em 16 pixels ou mais. Abaixo disso, o iPhone dá zoom no campo e deixa a página ampliada depois que o visitante termina de digitar.
Erros que dizem como corrigir a resposta
Quando uma verificação falha, o formulário sabe qual campo falhou e qual regra foi quebrada. “Entrada inválida” joga esse conhecimento fora.
Uma mensagem útil nomeia o campo, diz o que está errado e mostra uma resposta correta: “Digite um telefone dos EUA de 10 dígitos com o código de área, como 555-012-3456.”
O momento também importa. Um formulário que verifica a cada tecla chama um endereço de e-mail de inválido durante todo o tempo em que ele está sendo digitado. Verifique quando o visitante sai do campo, porque é aí que a resposta deve estar concluída.
Depois que um campo é marcado como errado, verifique-o enquanto a pessoa digita, para que a mensagem desapareça no momento em que a resposta for corrigida. Depois:
- Coloque cada mensagem ao lado do seu campo, onde o visitante já está olhando.
- Ao enviar, liste todos os problemas no topo com um link para cada campo, e leve o foco para essa lista.
- Nunca dependa só da cor. Uma borda vermelha é invisível para alguns visitantes daltônicos e para todos os leitores de tela. Palavras, um ícone e uma borda mais grossa transmitem a mensagem.
- Ligue a mensagem ao campo no código, para que ela seja anunciada quando o campo receber o foco.
- Nunca apague um campo por causa de um erro em outro. Um erro de digitação no telefone não é motivo para esvaziar a caixa de mensagem.
Exemplo ao vivo
Erros que dizem como corrigir a resposta
Este exemplo roda no seu navegador. Nada do que você digita é enviado. Experimente a versão quebrada.
Pegue erros de digitação no e-mail sem bloquear ninguém
Alguém digita gamil.com em vez de gmail.com. O endereço está bem formado, então todos os validadores o aceitam.
Sua resposta, recibo ou confirmação de inscrição não chega a lugar nenhum. Do lado do visitante, ele escreveu para você e você nunca respondeu.
Alguns por cento dos endereços digitados à mão têm um erro, e os mais comuns são previsíveis. Quando o visitante sai do campo:
- Compare o endereço com uma lista curta de erros de grafia conhecidos.
- Explique a sugestão e ofereça uma correção com um toque.
- Deixe o visitante manter o que digitou. Endereços incomuns existem, e a última palavra é sempre do visitante.
- Uma exceção: um final que não existe, como hey.con. Nenhuma mensagem pode chegar lá, então peça uma correção e não ofereça mantê-lo. Compare com a lista oficial de terminações de domínio, não com um palpite.
Exemplo ao vivo
Uma verificação de e-mail que pergunta em vez de bloquear
Este exemplo roda no seu navegador. Nada do que você digita é enviado.
Mostre cada estado do botão de envio
Um botão de envio deve ao visitante quatro estados:
- Parado convida ao clique.
- Processando mostra que o clique foi recebido. O botão muda o texto e se desativa, para que um segundo clique nervoso não envie o formulário duas vezes.
- Falhou explica o que deu errado, perto do botão, enquanto cada campo mantém o que o visitante digitou.
- Concluído substitui o formulário por uma confirmação que diz o que foi recebido e o que acontece em seguida. Os leitores de tela o anunciam, além de ele aparecer na tela.
Exemplo ao vivo
Um botão de envio que mostra cada estado
Mensagem recebida
Este exemplo roda no seu navegador. Nada do que você digita é enviado. Experimente a versão quebrada.
Dedique o maior cuidado à falha. Se o formulário mantém as palavras do visitante, uma conexão que cai custa mais um clique. Se as perde, pouquíssimas pessoas reescrevem uma mensagem longa de memória. Ative a falha simulada acima e clique em enviar.
Construa um formulário de verdade por baixo do script. Se o script não carregar numa rede corporativa restrita, o formulário ainda deve ser enviado da forma comum e mostrar uma página de confirmação simples.
Quando uma requisição excede o tempo limite, diga que o resultado é desconhecido. Mostrar sucesso quando você não sabe leva a pedidos de desculpas por mensagens que nunca chegaram.
Divida formulários longos em etapas
Um pedido de auxílio ou uma inscrição em evento pode chegar a trinta perguntas. Numa página só, a barra de rolagem diz ao visitante quanto trabalho falta antes mesmo de ele começar.
Dividido em etapas, o mesmo formulário pede alguns minutos de cada vez. O que faz as etapas funcionarem:
- Um assunto por etapa.
- Um indicador de progresso que diz a verdade: “Etapa 2 de 3”, nunca uma barra que salta de 20 para 90 por cento.
- Verifique cada etapa antes de avançar, para que os problemas apareçam enquanto as perguntas estão frescas.
- Voltar nunca perde nada. Um visitante que volta para corrigir uma data encontra todas as respostas seguintes onde as deixou.
- Termine com uma tela de revisão que mostra cada resposta com uma forma de editá-la, antes do envio final.
- Leve o foco para o título da nova etapa, para que quem usa leitor de tela ouça onde está.
- Enter avança uma etapa. Ele nunca deve enviar um formulário pela metade.
Exemplo ao vivo
Um formulário em três etapas que guarda as suas respostas
- Seus dados
- Seu evento
- Outros
- Revisão
Pedido recebido
Esta era a última etapa. Em um formulário de verdade, aqui o pedido é salvo e a equipe é avisada. Este exemplo não enviou nada e apagou o que tinha salvo.
Preencha uma etapa e depois recarregue a página. As suas respostas voltam, e só este navegador as teve.
Este exemplo roda no seu navegador. Nada do que você digita é enviado. Experimente a versão quebrada.
Guarde as respostas para que as pessoas possam voltar
As pessoas raramente terminam um formulário longo de uma vez. Precisam de um valor de orçamento do financeiro, de uma carta de referência, da aprovação de um colega. Um formulário que esquece tudo quando a aba fecha obriga a recomeçar, e muitos não recomeçam.
Há duas formas de guardar as respostas. Seja qual for a escolhida, avise as pessoas: “Salvo neste dispositivo” ao lado do formulário é suficiente.
Num formulário curto ou anônimo, guarde as respostas no próprio navegador do visitante enquanto ele digita, como faz o exemplo em etapas acima. Recarregue esta página e as suas respostas voltam.
- Nada sai do dispositivo, e nada exige uma conta.
- Um botão “Apagar minhas respostas” permite que alguém num computador compartilhado as remova.
- Nunca guarde senhas, dados de pagamento ou qualquer informação sensível no navegador.
Num pedido longo, salve rascunhos no servidor e envie ao visitante por e-mail um link para continuar. Proteja esse link:
- Envie-o apenas para o endereço informado no formulário.
- Faça-o expirar.
- Limite quantos links um visitante pode pedir. Caso contrário, a caixa de continuar vira uma forma de enviar os seus e-mails para estranhos.
Barre o spam sem um quebra-cabeça
Um CAPTCHA transforma o seu problema de spam numa tarefa do visitante. Ele pesa mais para quem tem baixa visão, mãos lentas ou usa leitor de tela.
A maior parte do spam em formulários é automática e descuidada, então três verificações que o visitante nunca vê barram quase todo ele:
- Um honeypot: um campo extra escondido das pessoas e dos leitores de tela. Robôs preenchem todos os campos, então um honeypot preenchido marca o envio como spam.
- Um cronômetro: ninguém responde a um formulário de contato dois segundos depois de a página carregar.
- Um limite de frequência: trinta envios por minuto vindos de um mesmo endereço não são trinta pessoas.
Exemplo ao vivo
O campo que só os robôs preenchem
Este exemplo roda no seu navegador. Nada do que você digita é enviado.
O que passa por essas verificações foi digitado por uma pessoa. Marque para revisão em vez de bloquear, para que um falso positivo nunca faça perder uma mensagem real.
Mostre a todos os remetentes a mesma confirmação, para que quem opera um robô não aprenda nada com a resposta.
O que acontece depois do botão
Ninguém preenche um formulário para ver uma tela de confirmação. As pessoas querem uma resposta, e tudo o que existe entre enviado e respondido é um segundo sistema que falha com mais frequência do que qualquer botão.
A configuração comum é um formulário que envia um e-mail para uma caixa de entrada, e esse e-mail é a única cópia. Se um filtro de spam o retém, ou se o destinatário mudou de função na primavera passada, o pedido some sem deixar rastro.
Primeiro salve, depois notifique.
Exemplo ao vivo
O que acontece depois do botão
- Salvar o envioUm registro com data e hora, em um arquivo que você controla.
- Avisar a equipeA partir do seu domínio, com o endereço do visitante para resposta.
- Confirmar ao visitanteO que foi recebido, um número de referência e quando esperar uma resposta.
- Uma pessoa respondeDentro do prazo prometido na confirmação.
Depois, garanta que as notificações continuem chegando:
- Envie-as do seu próprio domínio autenticado, com o endereço do visitante como resposta, para que passem nas verificações que os provedores de e-mail exigem.
- Dê ao encaminhamento dos formulários um responsável com nome, e revise-o sempre que as pessoas mudarem de função.
- Fique atento ao silêncio. Um formulário que recebia em média cinco envios por semana e não recebe nenhum há três semanas está quebrado, mesmo que todas as páginas carreguem.
- Faça um envio de teste programado por toda a cadeia, do formulário até a caixa de entrada que a equipe lê. Ele pega o que o monitoramento de disponibilidade não consegue.
Teste as versões quebradas
Ler sobre um texto de exemplo que desaparece não é o mesmo que preencher um formulário e se perder nele.
A página das versões quebradas tem formulários ao vivo com os erros contra os quais este guia alerta. Cada um é explicado antes de começar, e cada um tem um link de volta para a versão corrigida aqui.
Por que é uma página separada. Exigimos de todas as páginas do LFW.com uma pontuação perfeita nas verificações automáticas de acessibilidade, e o site é verificado todas as noites. Formulários que falham de propósito quebrariam essa regra no próprio guia.
Por isso as falhas ficam numa única página, e cada uma é dispensada com precisão: uma regra, num elemento, naquela página. Qualquer outra coisa que falhe ali continua disparando um alarme, e a página mantém a sua pontuação real, mais baixa. Ela também fica fora dos resultados de busca.
Se quiser saber como estão os seus próprios formulários, a auditoria gratuita verifica os campos da sua página inicial quanto a rótulos, contraste e as outras regras automáticas de acessibilidade.
Também criamos e corrigimos formulários para organizações em WordPress. Fale conosco sobre os seus formulários.
Receba o LFW Weekly Recap
Uma newsletter enviada toda sexta-feira com a semana na LFW. Um e-mail por semana e nenhum outro artigo do blog.
Primeiro enviamos um e-mail de confirmação. Nada mais chega até você clicar.
Confira sua caixa de entrada
Um link de confirmação está a caminho de . Clique nele para receber o resumo. Se ele não chegar à caixa de entrada em alguns minutos, confira a pasta de spam e marque como Não é spam.