Digitar uma senha em um campo mascarado exige atenção. Um erro pode estar no uso de maiúsculas, em um caractere difícil de reconhecer ou em uma sequência inserida no lugar errado. Oferecer a ação de mostrar e ocultar ajuda a pessoa a conferir o que digitou quando considerar adequado. Para o designer, porém, não basta colocar um ícone de olho ao lado do campo. É necessário projetar o nome da ação, os estados, o teclado e a relação com o restante do acesso.

Imagine um portal hipotético de clientes de uma agência. A pessoa entra para revisar uma proposta e encontra um formulário curto de autenticação. O objetivo do projeto é permitir que ela preencha e confira os dados sem transformar a interface em mais um obstáculo. Os exemplos a seguir são orientações de design, sem alegar um teste realizado. A configuração técnica da autenticação precisa ser tratada pela equipe responsável; aqui, o foco é a experiência de preencher, revisar e continuar.

Trate a visibilidade como uma escolha da pessoa

Comece definindo o estado inicial e a ação disponível. O campo pode apresentar o conteúdo mascarado, com um controle explícito para mostrá-lo quando desejado. A decisão de revelar deve ser consciente e fácil de reverter. Evite uma alteração inesperada apenas porque o campo recebeu foco ou porque a pessoa saiu dele. O comportamento precisa ser compreensível em uma tela compartilhada, em um celular e em qualquer outro contexto em que a pessoa esteja avaliando a própria privacidade visual.

Não use a visibilidade para pressionar o usuário a seguir um modo específico de preenchimento. Algumas pessoas preferem conferir o texto; outras querem mantê-lo oculto. O desenho deve permitir a escolha sem explicar em excesso uma ação simples. Posicione o controle junto do campo correspondente e preserve espaço para o conteúdo. Se há mais de um campo de senha, deixe claro qual deles será afetado. Uma ação que revela vários campos sem indicar seu alcance pode gerar uma surpresa desnecessária.

Nomeie a ação de modo direto

Mostrar senha e Ocultar senha são instruções compreensíveis para a mudança de visibilidade. Se houver um ícone, confira se o significado continua claro sem depender de reconhecer um desenho específico. Um olho com traço pode ser interpretado como estado atual ou como ação futura. O texto pode reduzir essa ambiguidade. Escolha a solução no contexto do formulário e mantenha coerência entre o que aparece visualmente e o nome comunicado pelos recursos de acessibilidade.

O componente de campo de senha do GOV.UK Design System oferece uma referência pública com ação de mostrar e ocultar. Use o padrão para examinar o comportamento, e não apenas para copiar a posição do botão. Confira como a ação se relaciona ao campo e ao envio do formulário. Um controle de visibilidade precisa agir como tal, sem disparar a autenticação quando a pessoa só deseja revisar o texto que digitou.

Preserve o conteúdo e a continuidade do preenchimento

Ao alternar a visibilidade, a pessoa deve conseguir continuar a tarefa sem refazer o que já escreveu. Combine com desenvolvimento o comportamento esperado para foco, seleção e posição de digitação. Descreva o percurso em vez de entregar somente duas imagens estáticas. A mudança pode acontecer durante uma correção no meio da senha ou depois do preenchimento completo. Esses cenários ajudam a revelar problemas que uma demonstração com um campo vazio não mostra.

Faça uma verificação proposta com uma credencial fictícia, criada apenas para o ambiente de teste. Digite parte do conteúdo, alterne a visibilidade, faça uma correção e continue. Repita o percurso por teclado e com toque. Observe se o botão muda de tamanho, se o campo desloca elementos próximos ou se a pessoa perde a referência do que estava fazendo. Registre o comportamento encontrado no produto real. O protótipo visual não confirma sozinho como o navegador tratará essas interações.

Trabalhe a relação entre rótulo e ajuda

Mantenha o nome do campo disponível enquanto a pessoa digita. Se houver instruções necessárias para criar uma senha, apresente-as em um local associado ao campo e com uma linguagem que permita agir. No acesso a uma conta existente, evite misturar regras de criação com a tarefa de entrar. São momentos diferentes. Um formulário de login precisa ajudar a reconhecer o dado esperado e oferecer um caminho de recuperação, sem acrescentar instruções que não se aplicam àquela etapa.

O artigo sobre UX writing em formulários ajuda a revisar o conjunto de rótulo, orientação e erro. Leia a tela em voz alta como uma sequência de tarefa. E-mail, senha, mostrar senha, entrar e recuperar acesso devem formar um percurso reconhecível. Se a página precisa de um parágrafo para explicar cada botão, investigue se a estrutura está complicando uma ação que poderia ser apresentada de maneira mais direta.

Apoie o preenchimento sem impor memorização

A explicação do W3C sobre autenticação acessível, critério 3.3.8, de nível AA, apresenta exemplos com gerenciadores de senhas, identificação adequada dos campos e possibilidade de colar credenciais. Essa referência ajuda a planejar o formulário como parte de um percurso acessível. Não bloqueie recursos de preenchimento por uma preferência estética. Confirme com a equipe responsável como a implementação reconhecerá o propósito dos campos e permitirá que a pessoa utilize suas ferramentas de apoio.

Mostrar a senha é uma ajuda de conferência, mas não resolve todas as barreiras do acesso. Observe também o caminho de recuperação, as instruções e as etapas adicionais previstas pelo serviço. Evite declarar que o formulário está acessível apenas porque possui um ícone de visibilidade. A avaliação precisa considerar o percurso completo e as condições reais de uso. Registre o que foi examinado e o que ainda depende de verificação, sem transformar uma melhoria isolada em uma conclusão sobre toda a experiência.

Desenhe os estados sem esconder a informação

Prepare campo vazio, preenchido, com foco, com erro e com conteúdo visível. Confira se o controle permanece legível em cada situação. Se a mensagem de erro aparece abaixo do campo, a relação precisa ser clara sem pressionar o botão de envio para fora de uma região previsível da tela. Em dispositivos menores, observe se a ação de mostrar compete com o texto ou se sua área de toque fica muito próxima de outro controle.

A indicação de foco também precisa ser visível sobre o fundo real. O guia sobre foco na navegação por teclado amplia esse ponto de revisão. A pessoa pode navegar do campo para o controle de visibilidade e depois para o envio. Cada posição deve ser reconhecível, com uma ordem coerente. Um destaque que existe apenas no arquivo de design não basta; a verificação deve ocorrer com os estilos e o comportamento efetivos do formulário implementado.

Planeje mensagens de erro com a equipe responsável

Quando o acesso falha, a interface precisa orientar a continuidade sem inventar o que aconteceu. Combine o texto com o funcionamento real da autenticação e com as decisões da equipe técnica. O designer deve saber quais condições podem ser comunicadas e quais caminhos estão disponíveis. Uma mensagem genérica demais pode deixar a pessoa sem ação; uma explicação incompatível com a resposta do sistema pode induzi-la a corrigir o dado errado ou repetir tentativas sem necessidade.

Se a pessoa optar por mostrar o conteúdo para revisá-lo depois da falha, o controle deve continuar disponível conforme a regra do projeto. Verifique o que acontece com os campos após o envio e registre a decisão. Não coloque informações sensíveis em capturas de tela, comentários ou relatórios de teste. Utilize dados fictícios para documentar o comportamento. A qualidade da revisão depende de reproduzir a interação necessária, sem expor credenciais de pessoas que utilizam o serviço.

Considere o ambiente, além da largura da tela

Um formulário pode ser usado com ampliação, teclado virtual e orientação horizontal. Examine a relação entre campo, ação e mensagens nessas condições. A interface deve continuar permitindo reconhecer o que está sendo mostrado e como ocultar novamente. Se houver um painel fixo ou uma mensagem sobreposta, confira se ele não cobre o controle. Pequenos componentes se tornam difíceis quando a composição da página restringe seu uso ou quebra a relação entre a ação e o campo correspondente.

Faça também uma revisão do vocabulário com pessoas que conhecem o público do serviço. Termos familiares à equipe podem não ser igualmente claros para os clientes. A pergunta principal é se a pessoa entende a ação e seu alcance antes de utilizá-la. Não é necessário provar isso com uma estatística inventada. Observe o percurso, registre dúvidas concretas e use essas evidências para ajustar texto, posição e comportamento na rodada seguinte de projeto.

Entregue um comportamento verificável

A especificação deve reunir estado inicial, rótulos, relação entre ação e campo, navegação por teclado e regras após o envio. Inclua exemplos de erro e orientações para preenchimento com recursos do navegador ou gerenciadores, conforme a implementação prevista. O controle de mostrar senha funciona quando oferece autonomia para conferir e continuar. Sua qualidade aparece na clareza do conjunto: a pessoa reconhece o campo, escolhe a visibilidade e entende o próximo passo sem precisar interpretar um símbolo isolado ou reconstruir o que acabou de digitar.