Um formulário de atendimento pede que a pessoa escolha o município onde o serviço será realizado. A lista tem centenas de opções, inclui nomes parecidos e precisa guardar o identificador correto da cidade. Um campo pesquisável pode encurtar o caminho, mas cria novas perguntas: o texto digitado já vale como resposta? Como a pessoa distingue duas cidades homônimas? O que acontece se a consulta demora ou não encontra uma correspondência? A qualidade do combobox depende dessas decisões, além do desenho da caixa de sugestões.

O exemplo deste artigo é um cadastro fictício de visitas técnicas. O município determina a região atendida e a equipe precisa receber um valor reconhecido pelo sistema. Vamos usar esse cenário para escolher o controle, definir seus estados e preparar a verificação. A mesma análise pode orientar catálogos, filtros e cadastros internos, desde que o projeto revise as regras de seleção e o vocabulário que seu público usa para encontrar opções.

Escolha o controle pelo tipo de decisão

Antes de procurar um componente, examine a tarefa. Se há poucas alternativas que cabem na tela e precisam ser comparadas, expor todas pode ajudar. Se a lista é longa e a pessoa conhece parte do nome, a pesquisa pode reduzir a procura. A quantidade é apenas uma parte da análise. Considere frequência de uso, familiaridade com as opções e consequências de selecionar o item incorreto. Um catálogo grande não exige automaticamente uma busca em toda situação, especialmente quando pode ser dividido de forma útil em etapas.

A documentação de select do GOV.UK ajuda a avaliar quando um seletor entra no desenho do formulário. No cadastro de visitas, por exemplo, escolher primeiro uma região pode reduzir o conjunto de cidades, desde que essa pergunta faça sentido para o público. Em outro contexto, perguntar a região antes do município acrescentaria uma decisão que a pessoa não sabe responder. Compare essas possibilidades com usuários e conteúdos representativos do serviço. Componente Select do GOV.UK Design System.

Para escolhas pequenas, observe como a apresentação das alternativas muda a tarefa. Se o cadastro oferece atendimento remoto ou presencial, dois botões de opção podem deixar a diferença visível desde o início. A pessoa consegue comparar os textos sem abrir uma lista. No campo de município, a lista extensa pede outra forma de localizar a resposta. Um formulário pode usar componentes diferentes porque cada pergunta exige uma decisão diferente. Botões de opção em formulários.

Defina quando a resposta passa a valer

O campo pode aceitar entrada livre com sugestões ou exigir a escolha de um item conhecido. Defina isso antes de desenhar as mensagens. No exemplo, digitar o nome da cidade serve para encontrar opções. A resposta válida é a seleção que associa o formulário ao identificador do município. Se a pessoa digitar um nome e sair do campo sem escolher uma sugestão, preserve o texto e indique como confirmar a cidade, conforme a regra adotada. A mensagem deve explicar o que falta fazer sem atribuir um erro que a pessoa não consegue localizar.

Planeje também a edição da resposta. Depois de escolher uma opção, a pessoa pode descobrir que selecionou a cidade errada e começar a digitar de novo. Defina o que acontece com a seleção anterior, quando ela deixa de valer e como o estado é apresentado. O sistema precisa evitar enviar um identificador antigo ao mesmo tempo que a interface exibe um texto novo. Descreva essa transição na especificação e faça uma verificação de ponta a ponta, incluindo o valor recebido após enviar o formulário.

Faça as sugestões distinguirem itens parecidos

Organize a linha de resultado para mostrar a informação que permite decidir. No exemplo, o município pode aparecer junto da unidade federativa. Se houver outras distinções relevantes no sistema, escolha somente as que ajudam a pessoa a reconhecer a opção. Dados internos podem ser úteis para uma equipe de operações, mas não precisam ocupar o lugar do nome conhecido pelo público. Confira como os resultados aparecem com nomes longos e como a distinção permanece perceptível em uma tela estreita ou com ampliação.

Revise também a lógica da procura. Quem digita uma parte do nome espera reconhecer o motivo de o resultado aparecer. Decida como a pesquisa vai tratar acentos, espaços e termos incompletos conforme os dados e a implementação disponíveis. Prepare exemplos que a equipe consiga repetir. No cadastro de cidades, inclua nomes com grafias semelhantes e casos em que a pessoa procura uma forma abreviada. Documente quais casos são apoiados e quais exigem uma busca mais específica. Como organizar a busca interna em sites.

Separe espera, ausência de resultados e falha

Quando as opções vêm de uma consulta, a ausência de uma lista pode representar momentos diferentes. A busca pode estar aguardando resposta, pode ter terminado sem resultados ou pode ter encontrado um problema de comunicação. Desenhe mensagens que representem cada situação. Se a consulta ainda está em andamento, indicar que a cidade não existe pode induzir a pessoa a abandonar a escolha. Se houve falha, uma orientação de nova tentativa é mais útil que sugerir mudar a grafia sem evidência de que ela esteja incorreta.

No estado sem resultados, indique o que a pessoa consegue fazer a seguir. Pode conferir o termo, remover parte do texto ou escolher uma forma alternativa de atendimento, se o serviço realmente oferecer essa opção. Não esconda a regra de cobertura do serviço dentro de um estado de busca. Uma cidade pode existir na lista e ficar fora da região atendida. Nessa situação, explique a condição após a escolha e indique o próximo passo disponível. A pesquisa e a elegibilidade são decisões relacionadas, mas possuem causas e mensagens diferentes.

Descreva foco, abertura e seleção pelo teclado

O guia de práticas de autoria do W3C apresenta diferentes formas de combobox e as interações de teclado correspondentes. Escolha o padrão adequado ao tipo de entrada e à apresentação das sugestões. Em vez de desenhar uma lista genérica e decidir o comportamento depois, defina como abrir, explorar, confirmar e fechar a lista. A verificação precisa considerar o padrão usado e a estrutura implementada, pois nem todas as variações lidam com foco e seleção da mesma forma. Padrão Combobox do W3C.

Prepare um roteiro que a equipe consiga executar sem mouse. Comece entrando no campo a partir do controle anterior, digite um termo, percorra as sugestões e confirme uma opção. Repita fechando a lista sem escolher e depois alterando uma resposta já confirmada. Observe onde o foco fica em cada transição. Confira também se o nome do campo, as opções e as mudanças de estado são comunicados de maneira compreensível com as tecnologias assistivas utilizadas na avaliação. O protótipo orienta o teste, que precisa acontecer na interface implementada.

Verifique a resposta quando ela chega ao serviço

Teste um município válido, um termo sem correspondência e um caso em que o envio é tentado sem selecionar a opção. Verifique o que aparece na tela e o que é gravado pelo serviço. Se o formulário permite revisar os dados antes de enviar, confira se a revisão apresenta o nome reconhecível e a distinção necessária. A pessoa deve conseguir voltar, corrigir e avançar novamente. Uma escolha que parece correta apenas durante a pesquisa pode ficar ambígua quando aparece isolada no resumo.

Inclua situações de rede e mudança rápida de texto na avaliação. Uma consulta antiga pode terminar depois de uma mais recente. A equipe deve confirmar que a lista exibida corresponde ao termo atual e que uma opção anterior não será selecionada por engano. Registre esse cenário como comportamento verificável, com os termos digitados, a ordem das respostas e o resultado esperado. Esse detalhe não precisa aparecer para o público, mas determina se a interface consegue sustentar o que promete durante o preenchimento.

Entregue exemplos, regras e condições de uso

Documente o tipo de entrada, a regra de confirmação, as informações exibidas em cada sugestão e o destino do valor selecionado. Acrescente os estados de espera, falha, vazio e correção. Uma pequena amostra com nomes reais do domínio ou dados fictícios equivalentes ajuda outra pessoa a revisar o componente. Quando a mesma biblioteca for usada em outros cadastros, a equipe poderá distinguir as regras comuns dos requisitos específicos do município. Essa separação preserva a capacidade de reutilizar o componente sem transformar decisões do primeiro formulário em limitações para todos os próximos.

Antes de aprovar, peça que alguém use o controle com um caso representativo e explique como sabe qual opção ficou selecionada. Registre dúvidas concretas, como a dificuldade de distinguir dois nomes ou de perceber que a resposta foi confirmada. Volte ao desenho e ao contrato de dados para resolver a origem de cada problema. Um combobox bem definido oferece um caminho previsível desde o primeiro termo digitado até a resposta efetivamente recebida pelo serviço.