Práticas recomendadas para formulários de login

Use recursos de navegador multiplataforma para criar formulários de login seguros, acessíveis e fáceis de usar.

Se os usuários precisarem fazer login no seu site, um bom design de formulário de login é fundamental. Isso é especialmente verdadeiro para pessoas com conexões ruins, em dispositivos móveis, com pressa ou sob estresse. Formulários de login mal projetados têm altas taxas de rejeição. Cada rejeição pode significar um usuário perdido e insatisfeito, não apenas uma oportunidade de login perdida.

Veja um exemplo de um formulário de login simples que demonstra todas as práticas recomendadas:

Lista de verificação

Use um HTML significativo

Use elementos criados para o trabalho: <form>, <label> e <button>. Eles ativam a funcionalidade integrada do navegador, melhoram a acessibilidade e dão significado à marcação.

Usar <form>

Pode ser tentador envolver as entradas em um <div> e processar o envio de dados de entrada puramente com JavaScript. Em geral, é melhor usar um elemento <form> comum. Isso torna seu site acessível a leitores de tela e outros dispositivos assistivos, ativa uma variedade de recursos integrados do navegador, simplifica a criação de um login funcional básico para navegadores mais antigos e ainda pode funcionar mesmo que o JavaScript falhe.

Usar <label>

Para rotular uma entrada, use um <label>.

<label for="email">Email</label>
<input id="email" …>

Dois motivos:

  • Um toque ou clique em um rótulo move o foco para a entrada dele. Associe um rótulo a uma entrada usando o atributo for do rótulo com o name ou o id da entrada.
  • Os leitores de tela anunciam o texto do marcador quando o marcador ou a entrada dele recebe foco.

Não use marcadores de posição como rótulos de entrada. As pessoas podem esquecer para que serve a entrada depois que começam a digitar o texto, especialmente se forem distraídas ("Eu estava digitando um endereço de e-mail, um número de telefone ou um ID de conta?"). Há muitos outros problemas em potencial com marcadores de posição: consulte Don't Use The Placeholder Attribute e Placeholders in Form Fields Are Harmful se você não estiver convencido.

É melhor colocar os rótulos acima das entradas. Isso permite um design consistente em dispositivos móveis e computadores e, de acordo com a pesquisa de IA do Google, permite uma leitura mais rápida pelos usuários. Você recebe rótulos e entradas de largura total e não precisa ajustar a largura do rótulo e da entrada para que o texto do rótulo caiba.

Captura de tela mostrando a posição do rótulo de entrada do formulário em dispositivos móveis: ao lado e acima da entrada.
A largura do rótulo e da entrada é limitada quando ambos estão na mesma linha.

Abra a demonstração de label-position em um dispositivo móvel para conferir.

Usar <button>

Use <button> para botões. Os elementos de botão oferecem comportamento acessível e funcionalidade integrada de envio de formulários, além de serem fáceis de estilizar. Não faz sentido usar um <div> ou outro elemento fingindo ser um botão.

Verifique se o botão de envio diz o que faz. Por exemplo, Criar conta ou Fazer login, não Enviar ou Iniciar.

Garantir o envio do formulário

Ajude os gerenciadores de senhas a entender que um formulário foi enviado. Há duas maneiras de fazer isso:

  • Navegue para outra página.
  • Emule a navegação com History.pushState() ou History.replaceState() e remova o formulário de senha.

Com uma solicitação XMLHttpRequest ou fetch, verifique se o login foi informado na resposta e processado removendo o formulário do DOM e indicando o sucesso ao usuário.

Considere desativar o botão Fazer login depois que o usuário tocar ou clicar nele. Muitos usuários clicam em botões várias vezes, mesmo em sites rápidos e responsivos. Isso atrasa as interações e aumenta a carga do servidor.

Por outro lado, não desative o envio de formulários enquanto aguarda a entrada do usuário. Por exemplo, não desative o botão Fazer login se os usuários não tiverem inserido o PIN do cliente. Os usuários podem deixar de preencher algo no formulário e, em seguida, tocar repetidamente no botão Fazer login (desativado) e achar que ele não está funcionando. No mínimo, se você precisar desativar o envio de formulários, explique ao usuário o que está faltando quando ele clicar no botão desativado.

Não duplique as entradas

Alguns sites forçam os usuários a inserir e-mails ou senhas duas vezes. Isso pode reduzir os erros para alguns usuários, mas causa trabalho extra para todos os usuários e aumenta as taxas de abandono. Pedir duas vezes também não faz sentido quando os navegadores preenchem automaticamente os endereços de e-mail ou sugerem senhas fortes. É melhor permitir que os usuários confirmem o endereço de e-mail (você precisará fazer isso de qualquer maneira) e facilitar a redefinição da senha, se necessário.

Aproveite ao máximo os atributos de elementos

É aqui que a mágica realmente acontece. Os navegadores têm vários recursos integrados úteis que usam atributos de elementos de entrada.

Manter as senhas privadas, mas permitir que os usuários as vejam se quiserem

As entradas de senha precisam ter type="password" para ocultar o texto da senha e ajudar o navegador a entender que a entrada é para senhas. Os navegadores usam várias técnicas para entender as funções de entrada e decidir se vão oferecer ou não a opção de salvar senhas.

Adicione uma opção Mostrar senha para que os usuários possam verificar o texto que inseriram e não se esqueça de adicionar um link Esqueci a senha. Consulte Ativar a exibição de senha.

Formulário de login do Google mostrando o ícone &quot;Mostrar senha&quot;.
Entrada de senha do formulário de login do Google: com o ícone Mostrar senha e o link Esqueceu a senha.

Ofereça o teclado certo aos usuários de dispositivos móveis

Use <input type="email"> para oferecer aos usuários de dispositivos móveis um teclado adequado e ativar a validação básica de endereço de e-mail integrada pelo navegador, sem precisar de JavaScript.

Se você precisar usar um número de telefone em vez de um endereço de e-mail, o <input type="tel"> ativa um teclado de telefone no dispositivo móvel. Também é possível usar o atributo inputmode quando necessário: inputmode="numeric" é ideal para números de PIN. Tudo o que você sempre quis saber sobre inputmode tem mais detalhes.

Impedir que o teclado do dispositivo móvel obstrua o botão Fazer login

Infelizmente, se você não tomar cuidado, os teclados de dispositivos móveis podem cobrir o formulário ou, pior, obstruir parcialmente o botão Fazer login. Os usuários podem desistir antes de perceber o que aconteceu.

Duas capturas de tela de um formulário de login em um smartphone Android: uma mostrando como o botão &quot;Enviar&quot; é ocultado pelo teclado do smartphone.
O botão Fazer login: agora você vê, agora não vê mais.

Sempre que possível, evite isso exibindo apenas as entradas de e-mail (ou telefone) e senha e o botão Fazer login na parte de cima da página de login. Coloque outro conteúdo abaixo.

Um formulário de login em um smartphone Android: o botão de login não está oculto pelo teclado do smartphone.
O teclado não obstrui o botão Fazer login.

Testar em vários dispositivos

Você precisará testar em uma variedade de dispositivos para seu público-alvo e ajustar conforme necessário. O BrowserStack permite testes sem custo financeiro para projetos de código aberto em uma variedade de dispositivos e navegadores reais.

Capturas de tela de um formulário de login no iPhone 7, 8 e 11. No iPhone 7 e 8, o botão de login fica oculto pelo teclado do smartphone, mas não no iPhone 11
O botão Fazer login: oculto no iPhone 7 e 8, mas não no iPhone 11.

Considere usar duas páginas

Alguns sites (incluindo Amazon e eBay) evitam o problema solicitando e-mail (ou telefone) e senha em duas páginas. Essa abordagem também simplifica a experiência: o usuário só precisa fazer uma coisa de cada vez.

Um formulário de login no site da Amazon: e-mail/telefone e senha em duas &quot;páginas&quot; separadas.
Login em duas etapas: e-mail ou telefone e, em seguida, senha.

O ideal é que isso seja implementado com um único <form>. Use JavaScript para exibir inicialmente apenas a entrada de e-mail, depois oculte-a e mostre a entrada de senha. Se você precisar forçar o usuário a navegar para uma nova página entre a inserção do e-mail e da senha, o formulário na segunda página precisará ter um elemento de entrada oculto com o valor do e-mail para ajudar os gerenciadores de senhas a armazenar o valor correto. Estilos de formulário de senha que o Chromium entende fornece um exemplo de código.

Ajudar os usuários a evitar a reinserção de dados

Você pode ajudar os navegadores a armazenar dados corretamente e preencher automaticamente as entradas, para que os usuários não precisem se lembrar de inserir os valores de e-mail e senha. Isso é especialmente importante em dispositivos móveis e crucial para entradas de e-mail, que têm altas taxas de abandono.

Há duas partes:

  1. Os atributos autocomplete, name, id e type ajudam os navegadores a entender o papel das entradas para armazenar dados que podem ser usados posteriormente para preenchimento automático. Para permitir que os dados sejam armazenados para preenchimento automático, os navegadores mais recentes também exigem que as entradas tenham um valor name ou id estável (não gerado aleatoriamente em cada carregamento de página ou implantação de site) e estejam em um <form> com um botão submit.

  2. O atributo autocomplete ajuda os navegadores a preencher automaticamente as entradas usando dados armazenados.

Para entradas de e-mail, use autocomplete="username", já que username é reconhecido por gerenciadores de senhas em navegadores mais recentes, mesmo que você deva usar type="email" e talvez queira usar id="email" e name="email".

Para entradas de senha, use os valores autocomplete e id apropriados para ajudar os navegadores a diferenciar as senhas novas das atuais.

Use autocomplete="new-password" e id="new-password" para uma nova senha

  • Use autocomplete="new-password" e id="new-password" para a entrada de senha em um formulário de inscrição ou a nova senha em um formulário de mudança de senha.

Usar autocomplete="current-password" e id="current-password" para uma senha atual

  • Use autocomplete="current-password" e id="current-password" para a entrada de senha em um formulário de login ou para a entrada da senha antiga do usuário em um formulário de mudança de senha. Isso informa ao navegador que você quer usar a senha atual armazenada para o site.

Para um formulário de inscrição:

<input type="password" autocomplete="new-password" id="new-password" …>

Para fazer login:

<input type="password" autocomplete="current-password" id="current-password" …>

Suporte a gerenciadores de senhas

Cada navegador lida com o preenchimento automático de e-mails e a sugestão de senhas de forma um pouco diferente, mas os efeitos são os mesmos. No Safari 11 e versões mais recentes para computador, por exemplo, o gerenciador de senhas é exibido e, em seguida, a autenticação biométrica (impressão digital ou reconhecimento facial) é usada, se disponível.

Capturas de tela de três etapas do processo de login no Safari para computador: gerenciador de senhas, autenticação biométrica e preenchimento automático.
Login com preenchimento automático: não é necessário digitar texto.

O Chrome para computador mostra sugestões de e-mail, o gerenciador de senhas e preenche a senha automaticamente.

Capturas de tela de quatro etapas do processo de login no Chrome para computador: preenchimento de e-mail, sugestão de e-mail, gerenciador de senhas e preenchimento automático na seleção.
Fluxo de login do preenchimento automático no Chrome 84.

Os sistemas de senha e preenchimento automático do navegador não são simples. Os algoritmos para adivinhar, armazenar e exibir valores não são padronizados e variam de plataforma para plataforma. Por exemplo, como apontado por Hidde de Vries (link em inglês): "O gerenciador de senhas do Firefox complementa as heurísticas com um sistema de receitas" (link em inglês).

Preenchimento automático: o que os desenvolvedores da Web precisam saber, mas não sabem tem muito mais informações sobre o uso de name e autocomplete. A especificação HTML lista todos os 59 valores possíveis.

Permitir que o navegador sugira uma senha forte

Os navegadores mais recentes usam heurísticas para decidir quando mostrar a interface do gerenciador de senhas e sugerir uma senha forte.

Veja como o Safari faz isso no computador.

Gerenciador de senhas do Firefox no computador.
Fluxo de sugestão de senha no Safari.

A sugestão de senha forte e exclusiva está disponível no Safari desde a versão 12.0.

Os geradores de senhas integrados ao navegador evitam que usuários e desenvolvedores precisem descobrir o que é uma "senha forte". Como os navegadores podem armazenar senhas com segurança e preenchê-las automaticamente conforme necessário, não é preciso que os usuários se lembrem ou digitem senhas. Incentivar os usuários a aproveitar os geradores de senhas integrados ao navegador também significa que eles têm mais chances de usar uma senha exclusiva e forte no seu site e menos chances de reutilizar uma senha que possa ser comprometida em outro lugar.

Evitar que os usuários percam entradas acidentalmente

Adicione o atributo required aos campos de e-mail e senha. Os navegadores mais recentes solicitam e definem automaticamente o foco para dados ausentes. Não é necessário usar JavaScript.

Firefox para computador e Google Chrome para Android mostrando a mensagem &quot;Preencha este campo&quot; para dados ausentes.
Solicitação e foco para dados ausentes no Firefox para computador (versão 76) e no Google Chrome para Android (versão 83).

Design para dedos e polegares

O tamanho padrão do navegador para quase tudo relacionado a elementos de entrada e botões é muito pequeno, especialmente em dispositivos móveis. Isso pode parecer óbvio, mas é um problema comum com formulários de login em muitos sites.

Verifique se as entradas e os botões são grandes o suficiente

O tamanho e o padding padrão para entradas e botões são muito pequenos em computadores e piores ainda em dispositivos móveis.

Formulário sem estilo no Chrome para computador e no Google Chrome para Android.

De acordo com as diretrizes de acessibilidade do Android, o tamanho recomendado para objetos de touch screen é de 7 a 10 mm. As diretrizes de interface da Apple sugerem 48 x 48 px, e o W3C sugere pelo menos 44 x 44 pixels CSS. Com base nisso, adicione (pelo menos) cerca de 15 px de padding aos elementos de entrada e botões para dispositivos móveis e cerca de 10 px para computadores. Teste isso com um dispositivo móvel real e um dedo ou polegar real. Você precisa conseguir tocar em cada uma das entradas e botões sem dificuldade.

A auditoria do Lighthouse As áreas de toque não estão dimensionadas adequadamente pode ajudar a automatizar o processo de detecção de elementos de entrada muito pequenos.

Design para polegares

Pesquise área de toque e você vai encontrar muitas imagens de dedos indicadores. No entanto, no mundo real, muitas pessoas usam os polegares para interagir com os smartphones. Os polegares são maiores que os indicadores, e o controle é menos preciso. Mais um motivo para ter áreas de toque com tamanho adequado.

Aumentar o texto o suficiente

Assim como o tamanho e o padding, o tamanho da fonte padrão do navegador para elementos de entrada e botões é muito pequeno, principalmente em dispositivos móveis.

Formulário sem estilo no Chrome para computador e Android.
Estilo padrão em computadores e dispositivos móveis: o texto de entrada é muito pequeno para ser legível para muitos usuários.

Os navegadores em plataformas diferentes dimensionam as fontes de maneira diferente, então é difícil especificar um tamanho de fonte específico que funcione bem em todos os lugares. Uma pesquisa rápida de sites conhecidos mostra tamanhos de 13 a 16 pixels em computadores. Corresponder a esse tamanho físico é um bom mínimo para texto em dispositivos móveis.

Isso significa que você precisa usar um tamanho de pixel maior em dispositivos móveis: 16px no Chrome para computadores é bastante legível, mas, mesmo com uma boa visão, é difícil ler o texto 16px no Google Chrome para Android. É possível definir diferentes tamanhos de pixel de fonte para diferentes tamanhos de janela de visualização usando consultas de mídia. 20px é o tamanho ideal para dispositivos móveis, mas você deve testar isso com amigos ou colegas com baixa visão.

A auditoria do Lighthouse O documento não usa tamanhos de fonte legíveis pode ajudar a automatizar o processo de detecção de textos muito pequenos.

Deixe espaço suficiente entre as entradas

Adicione margem suficiente para que as entradas funcionem bem como áreas de toque. Em outras palavras, deixe uma margem de cerca de um dedo.

Verifique se as entradas estão claramente visíveis

O estilo de borda padrão para entradas dificulta a visualização. Eles são quase invisíveis em algumas plataformas, como o Google Chrome para Android.

Além do padding, adicione uma borda: em um plano de fundo branco, uma boa regra geral é usar #ccc ou mais escuro.

Formulário estilizado no Chrome para Android.
Texto legível, bordas de entrada visíveis, padding e margens adequados.

Usar recursos integrados do navegador para avisar sobre valores de entrada inválidos

Os navegadores têm recursos integrados para fazer a validação básica de formulários para entradas com um atributo type. Os navegadores avisam quando você envia um formulário com um valor inválido e focam na entrada problemática.

Um formulário de login no Chrome para computador mostrando a solicitação do navegador e o foco em um valor de e-mail inválido.
Validação básica integrada pelo navegador.

Use o seletor de CSS :invalid para destacar dados inválidos. Use :not(:placeholder-shown) para evitar a seleção de entradas sem conteúdo.

input[type=email]:not(:placeholder-shown):invalid {
  color: red;
  outline-color: red;
}

Teste diferentes maneiras de destacar entradas com valores inválidos.

Usar JavaScript quando necessário

Alternar exibição de senha

Adicione uma opção Mostrar senha para que os usuários possam verificar o texto inserido. A usabilidade é prejudicada quando os usuários não conseguem ver o texto que inseriram. No momento, não há uma maneira integrada de fazer isso, mas há planos para implementação. Você precisará usar JavaScript.

Formulário de login do Google mostrando o botão &quot;Mostrar senha&quot; e um link &quot;Esqueceu a senha?&quot;.
Formulário de login do Google: com o botão Mostrar senha e o link Esqueceu a senha.

O código a seguir usa um botão de texto para adicionar a funcionalidade Mostrar senha.

HTML:

<section>
  <label for="password">Password</label>
  <button id="toggle-password" type="button" aria-label="Show password as plain text. Warning: this will display your password on the screen.">Show password</button>
  <input id="password" name="password" type="password" autocomplete="current-password" required>
</section>

Este é o CSS para fazer o botão parecer um texto simples:

button#toggle-password {
  background: none;
  border: none;
  cursor: pointer;
  /* Media query isn't shown here. */
  font-size: var(--mobile-font-size);
  font-weight: 300;
  padding: 0;
  /* Display at the top right of the container */
  position: absolute;
  top: 0;
  right: 0;
}

E o JavaScript para mostrar a senha:

const passwordInput = document.getElementById('password');
const togglePasswordButton = document.getElementById('toggle-password');

togglePasswordButton.addEventListener('click', togglePassword);

function togglePassword() {
  if (passwordInput.type === 'password') {
    passwordInput.type = 'text';
    togglePasswordButton.textContent = 'Hide password';
    togglePasswordButton.setAttribute('aria-label',
      'Hide password.');
  } else {
    passwordInput.type = 'password';
    togglePasswordButton.textContent = 'Show password';
    togglePasswordButton.setAttribute('aria-label',
      'Show password as plain text. ' +
      'Warning: this will display your password on the screen.');
  }
}

Este é o resultado final:

Capturas de tela do formulário de login com o &quot;botão&quot; de texto &quot;Mostrar senha&quot; no Safari no Mac e no iPhone 7.
Formulário de login com o "botão" de texto Mostrar senha no Safari no Mac e no iPhone 7.

Tornar as entradas de senha acessíveis

Use aria-describedby para definir as regras de senha, fornecendo o ID do elemento que descreve as restrições. Os leitores de tela fornecem o texto do rótulo, o tipo de entrada (senha) e a descrição.

<input type="password" aria-describedby="password-constraints" …>
<div id="password-constraints">Eight or more characters with a mix of letters, numbers and symbols.</div>

Ao adicionar a funcionalidade Mostrar senha, inclua um aria-label para avisar que a senha será exibida. Caso contrário, os usuários podem revelar senhas sem querer.

<button id="toggle-password"
        aria-label="Show password as plain text.
                    Warning: this will display your password on the screen.">
  Show password
</button>

Confira os dois recursos ARIA em ação na seguinte demonstração:

A página Como criar formulários acessíveis tem mais dicas para ajudar a tornar os formulários acessíveis.

Valide em tempo real e antes do envio

Os elementos e atributos de formulários HTML têm recursos integrados para validação básica, mas você também deve usar o JavaScript para fazer uma validação mais robusta enquanto os usuários inserem dados e quando tentam enviar o formulário.

A etapa 5 do codelab do formulário de login usa a API Constraint Validation (que é amplamente compatível) para adicionar validação personalizada usando a interface integrada do navegador para definir o foco e exibir solicitações.

Saiba mais: Usar JavaScript para validação em tempo real mais complexa.

Análise e RUM

"O que não é medido não pode ser melhorado" é uma frase que se aplica especialmente aos formulários de inscrição e login. Você precisa definir metas, medir o sucesso, melhorar seu site e repetir.

O teste de usabilidade com desconto pode ser útil para testar mudanças, mas você vai precisar de dados reais para realmente entender como os usuários interagem com os formulários de inscrição e login:

  • Análise de páginas: visualizações de páginas de inscrição e login, taxas de rejeição e saídas.
  • Análise de interações: funis de meta (onde os usuários abandonam o fluxo de login?) e eventos (quais ações os usuários realizam ao interagir com seus formulários?)
  • Desempenho do site: métricas centradas no usuário (os formulários de inscrição e login estão lentos por algum motivo? Se sim, qual é a causa?).

Também é recomendável implementar testes A/B para testar diferentes abordagens de inscrição e login, além de lançamentos graduais para validar as mudanças em um subconjunto de usuários antes de lançá-las para todos.

Diretrizes gerais

Uma UI e uma UX bem projetadas podem reduzir o abandono do formulário de login:

  • Não faça os usuários procurarem o login. Coloque um link para o formulário de login na parte de cima da página, usando palavras fáceis de entender, como Fazer login, Criar conta ou Registrar.
  • Mantenha o foco. Os formulários de inscrição não são o lugar para distrair as pessoas com ofertas e outros recursos do site.
  • Minimize a complexidade da inscrição. Colete outros dados do usuário (como endereços ou detalhes do cartão de crédito) somente quando os usuários perceberem um benefício claro ao fornecer esses dados.
  • Antes de os usuários começarem a preencher o formulário de inscrição, deixe claro qual é a proposta de valor. Como eles se beneficiam ao fazer login? Ofereça aos usuários incentivos concretos para concluir a inscrição.
  • Se possível, permita que os usuários se identifiquem com um número de celular em vez de um endereço de e-mail, já que alguns usuários podem não usar e-mail.
  • Facilite a redefinição de senha para os usuários e deixe o link Esqueceu sua senha? em destaque.
  • Inclua um link para os Termos de Serviço e a Política de Privacidade: deixe claro para os usuários desde o início como você protege os dados deles.
  • Inclua o logotipo e o nome da sua empresa ou organização nas páginas de inscrição e login e verifique se o idioma, as fontes e os estilos correspondem ao restante do site. Alguns formulários não parecem pertencer ao mesmo site que o restante do conteúdo, especialmente se tiverem um URL significativamente diferente.

Continue aprendendo