Design de Formulários

O que Design de Formulários faz?

Um formulário é uma conversa na qual a organização pede algo e a pessoa paga com tempo, esforço e risco. Funciona quando cada pergunta merece seu lugar, cada resposta pode ser dada nos termos da pessoa e cada erro é detectado cedo, explicado no local e corrigível sem perder o trabalho. A falha de modelo mais comum é um formulário que parece pronto e não está: rótulos no placeholder, campos obrigatórios inventados, type="number" para números de cartão, sem autocomplete, erros apenas como bolhas do navegador ou bordas vermelhas, um botão de envio que diz "Enviar" e um caminho de sucesso que foi o único testado.

Aplique os princípios ranqueados de interface-guidelines (todos podem usar > diz a verdade > diz o que significa > a resposta vem primeiro > erros são sobrevivíveis > permanece no lugar > o possível é visível > convenção > polimento). Se essa habilidade estiver instalada, leia o SKILL.md dela primeiro. Sua seção 3 de references/human-interface.md contém as regras básicas de formulários (rótulos visíveis, marcação opcional, colagem, timing de validação, botão de envio desabilitado, comportamento de salvamento); esta habilidade vai além e não as repete.

Resumo

Responda a estas perguntas antes de desenhar um campo. Anote-as se o formulário tiver mais de cinco perguntas.

• Para que serve cada resposta? Nomeie a decisão ou ação que a utiliza. Um campo sem uso nomeado é cortado.
• Quem responde, com que frequência, em qual dispositivo? Um candidato que preenche uma vez na vida em um telefone, ou um funcionário inserindo 200 registros por dia em uma mesa. Isso decide uma coisa por página versus uma página densa.
• De quem são os dados? Da própria pessoa (preenchimento automático se aplica, WCAG 1.3.5 se aplica) ou de outra pessoa (um destinatário, um paciente, um cliente sendo inserido por um funcionário).
• Eles têm a resposta em mãos? Número do passaporte, ID da apólice, renda do ano anterior. Se não, diga com antecedência o que reunir e permita salvar.
• Quanto custa uma resposta errada e o que é irreversível após o envio (pagamento, declaração legal, postagem pública)?
• Onde estão os respondentes? Países, scripts, formatos de endereço, formatos de telefone, estruturas de nome.
• O que o sistema já pode saber? Nunca pergunte por isso (WCAG 3.3.7).
• Leitor agente: um agente preencherá isso para alguém (extensões de preenchimento automático, agentes de navegador, assistentes)? Suponha que sim para qualquer coisa pública.

Regras

Pergunte menos

• Corte campos antes de desenhá-los. Cada campo deve ter um uso nomeado agora, não "pode ser útil". Baymard descobre que o checkout médio tem 11,3 campos onde 8 são suficientes; a contagem de campos prejudica mais que a contagem de etapas. [P: Baymard 2024]
• Colete o nome completo em um campo a menos que as partes impulsionem um comportamento específico (ordenação, endereço formal). Muitos nomes não se dividem em nome e sobrenome. Nunca exija um sobrenome. [S: W3C i18n; P: Baymard]
• Esconda campos raramente usados atrás de um link, não de um campo obrigatório: linha 2 do endereço, empresa, código de cupom. [P: Baymard]
• Defina endereço de cobrança como o de entrega com uma caixa marcada que oculta os campos de cobrança. [P: Baymard]
• Ofereça criação de conta após a transação, não como uma barreira antes dela. [P: Baymard]
• Permita "Não sei" onde isso é uma resposta válida, em vez de forçar um palpite. [S: GOV.UK páginas de pergunta]
• Derive o que puder: cidade e região a partir do CEP onde confiável, tipo de cartão a partir do número, país a partir da busca de endereço. Mantenha os valores derivados visíveis e editáveis. [P: Baymard]

Estrutura e fluxo

• Escolha a forma a partir do resumo, não do hábito. Tarefas raras, estressantes ou desconhecidas: uma pergunta por página, com a pergunta como h1/legend. Entrada frequente de especialistas: uma página, agrupada, rápida no teclado. O GOV.UK começa cada serviço com uma coisa por página e mescla apenas quando a pesquisa diz isso. [S: GOV.UK estrutura de formulário]
• Ordene as perguntas como a pessoa pensa sobre elas, as mais fáceis e certas primeiro, e ramifique para que ninguém veja uma pergunta que não pode se aplicar. [S: GOV.UK; J]
• Diga o que a pessoa precisará antes de começar (documentos, tempo, custo) e o que acontece depois. [S: GOV.UK páginas iniciais]
• Formulários longos de várias sessões recebem uma lista de tarefas com status simples e salvar-e-voltar. Use uma apenas quando as pessoas não podem terminar em uma sentada ou devem escolher sua própria ordem. [S: GOV.UK lista de tarefas]
• Voltar funciona. Inclua um link Voltar nas páginas de pergunta e nunca quebre o botão Voltar do navegador; ao retornar, as respostas anteriores são pré-preenchidas. [S: GOV.UK]
• Encerre fluxos consequentes com uma página de revisão de respostas: cada resposta com um link Alterar cujo nome acessível nomeia o campo ("Alterar data de nascimento"), retornando ao resumo após a edição. [S: GOV.UK revisão de respostas; WCAG 3.3.4]
• Layouts de várias colunas quebram a ordem de leitura para pessoas e agentes. Uma coluna, exceto campos curtos naturalmente pareados (mês e ano de validade, cidade e CEP). [P: Baymard, Wroblewski; J]

Rótulos, dicas e agrupamento

• Rótulo acima do campo. A vantagem de velocidade relatada por Penzo 2006 vem de um teste de rastreamento ocular pequeno e informal e foi contradita por Das 2008; escolha rótulos no topo porque eles sobrevivem a telas estreitas, traduções longas e zoom, não porque são comprovadamente os mais rápidos. [E, fraco: Penzo 2006, Das 2008]
• Dicas vão entre o rótulo e o campo e são vinculadas com aria-describedby. Exemplos de formato ("Por exemplo, 27 3 2007") pertencem à dica, nunca ao placeholder. [S: GOV.UK]
• Agrupe controles relacionados com fieldset e legend: cada conjunto de rádios, caixas de seleção e resposta de múltiplas partes (data, validade do cartão). A legenda é a pergunta. [S: WCAG 1.3.1; GOV.UK]
• Em uma página de uma pergunta, o rótulo ou legenda é o título da página para que leitores de tela ouçam uma vez. [S: GOV.UK páginas de pergunta]
• Marque campos opcionais com "(opcional)" e não use asteriscos para obrigatórios. Se a maioria dos campos é opcional, questione se eles pertencem. [S: GOV.UK]

Tipos de entrada e preenchimento automático

• Defina autocomplete em cada campo sobre a pessoa, com o token exato do WHATWG (given-name, email, postal-code, cc-number, one-time-code, new-password). Ele alimenta o preenchimento automático do navegador, gerenciadores de senhas e preenchimento por agentes, e é um requisito do WCAG 1.3.5. autocomplete="off" em dados pessoais é um defeito. [S: WHATWG autofill; WCAG 1.3.5]
• Use type para significado e inputmode para teclado. type="email", type="tel", type="url" onde se aplicam. Identificadores compostos de dígitos (cartão, CEP, conta, código) são type="text" inputmode="numeric", nunca type="number", que descarta zeros à esquerda, muda com a rolagem, arredonda valores longos e confunde software de ditado. [S: GOV.UK 2020; MDN]
• Controles nativos primeiro. select para uma lista fechada com cerca de uma dúzia de opções, rádios para algumas opções que as pessoas devem comparar, um combobox com digitação antecipada para listas longas como países. Dropdowns personalizados ocultam suas opções dos agentes. [S: APG; P: sonda em interface-guidelines]
• Datas memoráveis são três campos de texto (dia, mês, ano) com tokens bday-* para datas de nascimento, aceitando nomes de meses. Seletores de data são adequados apenas para datas que as pessoas escolhem em relação a um calendário. [S: GOV.UK entrada de data]
• Dimensione o campo para a resposta esperada. Uma caixa de CEP tão larga quanto uma caixa de rua sugere algo errado. [S: GOV.UK; J]
• Aceite respostas no formato da pessoa: espaços e traços em números de cartão e telefone, qualquer maiúscula/minúscula em CEPs, nomes de meses, espaços iniciais ou finais. Normalize no servidor. [S: GOV.UK]
• Padrões campo por campo (nomes, endereços por país, telefone, dinheiro, cartões, arquivos) estão em references/fields.md.

Validação e erros

• Valide ao enviar por padrão; validação inline apenas depois que a pessoa sai de um campo que terminou e limpe um erro assim que for corrigido. Nunca sinalize no primeiro caractere digitado. As evidências conflitam: Bargas-Avila 2007 descobriu que erros listados após a conclusão superam erros imediatos; Wroblewski 2009 descobriu que a validação inline ao sair do campo ajudou (n=22). GOV.UK valida ao enviar; Baymard recomenda ao sair do campo e remover erros na correção. Decida pelo comprimento do formulário e pelo quanto o campo é verificável sozinho. [E: Bargas-Avila 2007; E, fraco: Wroblewski 2009; S: GOV.UK; P: Baymard]
• Em um envio com falha: mantenha todas as respostas, coloque um resumo de erros no topo com um link por problema para seu campo, mova o foco para o resumo, prefixe o título da página com "Erro: " e mostre a mesma redação ao lado de cada campo. [S: GOV.UK resumo de erros; WCAG 3.3.1]
• Vincule cada mensagem ao seu campo com aria-describedby (adicione aria-errormessage junto se quiser; o suporte a leitores de tela ainda é irregular) e defina aria-invalid="true". A mensagem deve ser texto visível: serializadores de agente descartam aria-invalid mas mantêm o texto adjacente. [S: WCAG 3.3.1; P: Roselli 2023; P: sonda em interface-guidelines]
• Desligue as bolhas de validação do navegador (novalidate) e renderize as mensagens na página. As bolhas desaparecem, não podem ser vinculadas a partir de um resumo e não são texto da página. A validação do servidor permanece autoritativa. [S: GOV.UK validação]
• Escreva erros que digam como corrigir, específicos para a causa: "Insira uma data de nascimento no passado", não "Data inválida". Uma mensagem por causa (vazio, formato errado, fora do intervalo), nas palavras do formulário. [S: GOV.UK mensagem de erro; WCAG 3.3.3]
• Uma condição que a pessoa não pode corrigir editando (inelegível, conta bloqueada, serviço fora do ar) é uma página com o motivo e o próximo passo, não um erro de campo. [S: GOV.UK]

Login, senhas, chaves de acesso

• Deixe gerenciadores de senhas e colagem funcionarem. autocomplete="username" e current-password ou new-password; nunca bloqueie colagem; sem maxlength abaixo de 64; ofereça Mostrar senha; remova o campo de confirmação de senha quando Mostrar é oferecido. [S: NIST SP 800-63B-4 3.1.1.2; GOV.UK campo de senha; WCAG 3.3.8]
• Sem regras de composição, sem expiração periódica, sem dicas. Verifique novas senhas contra listas de senhas conhecidamente violadas e diga por que uma foi recusada. [S: NIST SP 800-63B-4]
• Ofereça chaves de acesso sem forçar uma escolha antecipada: mantenha o campo de nome de usuário, adicione autocomplete="username webauthn" e uma solicitação WebAuthn condicional, depois ofereça criação de chave de acesso após um login com senha. [S: WHATWG autofill; P: web.dev passkey autofill]
• Códigos de uso único: um campo, autocomplete="one-time-code", inputmode="numeric", colagem aceita. Caixas de dígito único divididas que rejeitam um código colado falham no WCAG 3.3.8. [S: WCAG 3.3.8]
• Não diga qual dos dois (usuário ou senha) estava errado. [S: GOV.UK senhas]
• Não bloqueie o login com um CAPTCHA de quebra-cabeça. Quebra-cabeças de texto e lógica falham no WCAG 3.3.8 sem uma alternativa não cognitiva. [S: WCAG 3.3.8]

Envio

• O botão de envio nomeia o resultado: "Criar conta", "Pagar R$ 42,00", "Enviar inscrição". "Continuar" entre etapas; "Salvar e continuar" apenas se salvou. [S: GOV.UK botão; fundamento]
• Envios legais, financeiros e de exclusão de dados são reversíveis, verificados ou confirmados com uma etapa de revisão (WCAG 3.3.4). A revisão mostra exatamente o que será enviado e quanto custa. [S: WCAG 3.3.4]
• O envio é idempotente: desabilite a reentrada enquanto estiver em andamento, mostre progresso no botão e proteja no servidor com uma chave de idempotência. Uma nova tentativa após um tempo limite não deve cobrar duas vezes. [S: GOV.UK botão; P: Stripe idempotency]
• A página de confirmação informa o que aconteceu, um número de referência e o que acontece a seguir, e sobrevive a um recarregamento. Um toast não é um recibo. [S: GOV.UK páginas de confirmação; fundamento]

Para o leitor agente

• Cada controle tem um nome programático que corresponde ao seu rótulo visível, e suas escolhas são enumeráveis (select nativo, rádios visíveis). [J]
• As restrições são texto visível antes do envio (formato, comprimento, valores permitidos), não apenas em um atributo pattern. [J]
• Os erros são texto ao lado do campo e em um resumo, estáveis até serem corrigidos. [J]
• A URL ou título de cada etapa informa onde no fluxo o agente está; caminhos Voltar e Alterar existem. [J]
• Texto escrito por terceiros (pré-preenchido de um e-mail, uma nota de referência) é mostrado como dados citados, nunca como rótulo ou instrução. [J]
• Envios consequentes mantêm a autoridade no servidor: uma página de revisão de respostas ajuda as pessoas; não impede um agente que clique através dela. [J]

Ordem de construção

1. Liste as perguntas com o uso de cada resposta; delete aquelas sem uso.
2. Escolha a forma: uma página, uma coisa por página ou lista de tarefas. Esboce a ramificação.
3. Escreva o texto: perguntas, dicas, cada mensagem de erro por causa, rótulos de botão, confirmação.
4. Construa com elementos nativos: label for, fieldset/legend, type correto, inputmode, autocomplete, novalidate.
5. Validação do servidor e envio idempotente, depois validação do cliente usando as mesmas mensagens.
6. Estado de erro: resumo, foco, prefixo do título, mensagens inline, entrada preservada.
7. Páginas de revisão de respostas e confirmação; salvar e retornar se multi-sessão.
8. Estilo por último; a marca possui a aparência (brand-identity).

Verificar

• node <form-design>/scripts/form-check.mjs <url|file|dist> --try-submit contra uma compilação local ou de teste. Ele verifica nomes e rótulos visíveis, validade e finalidade do autocomplete, tipos de entrada, colagem, rádios nativos ocultos, legendas de grupo, conexão de erros, foco após um envio com falha e redação do envio. Erros saem com código 1. --try-submit realmente envia: nunca aponte para produção.
• node <interface-guidelines>/scripts/audit.mjs <url|dist> para a auditoria renderizada geral (contraste, alvos, teclado, refluxo, estabilidade do agente).
• Preencha-o com um gerenciador de senhas e preenchimento automático do navegador em um perfil real: cada campo pessoal é preenchido e nada cai na caixa errada.
• Preencha-o apenas com o teclado e a 320 px com texto a 200%.
• Preencha-o como agente a partir apenas do instantâneo de acessibilidade: encontre cada campo pelo nome, leia todas as escolhas, envie errado, leia os erros, corrija-os, termine.
• Dados ruins: um nome de uma palavra, um nome de 60 caracteres com apóstrofo e acentos, um endereço no Japão e outro na Irlanda sem CEP, um número de cartão colado com espaços, um clique duplo no envio, um tempo limite de sessão no meio do fluxo.

Armadilhas

• Placeholder como rótulo, ou um rótulo flutuante que encolhe na borda e falha no contraste.
• type="number" para cartão, telefone, CEP ou códigos.
• autocomplete="off"

...[truncado para tradução]