Input "email"

Métodos de Interação

O campo usa type="email" e, em dispositivos compatíveis, oferece teclado adequado para e-mail.

Interação com mouse

1. Clicar no campo ou no rótulo associado coloca o foco no campo.
2. Selecionar, editar, copiar e colar segue o comportamento nativo do campo.

Interação com teclado

1. Tab move o foco para o campo; Shift + Tab retorna ao controle anterior.
2. Digitação insere texto; setas, Home, End e comandos de seleção e edição seguem a plataforma.
3. Enter segue a ação de envio definida para o formulário; o campo não cria uma nova linha.

Interação com gestos

1. Tocar no campo ou no rótulo permite editar com o teclado virtual.
2. A seleção e edição de texto seguem os gestos disponíveis na plataforma.

Interação com teclado (ou gestos) + leitor de telas

1. Ao navegar até o campo, o leitor apresenta seu rótulo e tipo, além de estados e instruções associados.
2. Erros são associados ao campo e explicam como corrigir a informação; o valor digitado é preservado.

Gherkin

Metodologia BDD (Behavior-Driven Development ou Desenvolvimento Orientado ao Comportamento) com foco em 3 pilares: Histórias de Usuário, Critérios de Aceite e Sintaxes Gherkin (Dado (Given), Quando (When), Então (Then)).

Cenário: Considerando que estou em uma página que contém Input "email"

Navegação por teclado

1. QUANDO uso a tecla Tab para mover o foco para o campo
2. O foco que VEJO é fortemente indicado visualmente
3. ENTÃO, quando digito, seleciono ou edito o conteúdo com os comandos nativos
4. VEJO que o valor do campo é atualizado
5. E, quando uso Tab ou Shift + Tab, VEJO que o foco segue a ordem da página, sem ficar preso no campo

Leitor de telas para desktop

1. QUANDO uso um leitor de tela no computador (NVDA, JAWS, VoiceOver) e uso a tecla Tab para mover o foco para o campo, acontece o seguinte:
   • OUÇO o rótulo e a finalidade do campo.
   • OUÇO que o componente é um campo de e-mail.
   • OUÇO a obrigatoriedade, as instruções e os erros associados, quando existirem.
2. ENTÃO, quando digito ou edito o conteúdo com os comandos nativos
3. OUÇO ou percebo que posso editar o campo e que seu valor foi atualizado.

Leitor de telas para dispositivos móveis

1. QUANDO uso um leitor de tela no celular (Talkback, VoiceOver) e deslizo o dedo para focar no campo, acontece o seguinte:
   • OUÇO o rótulo e a finalidade do campo.
   • OUÇO que o componente é um campo de e-mail.
   • OUÇO a obrigatoriedade, as instruções e os erros associados, quando existirem.
2. ENTÃO, quando eu toco duas vezes ou uso o gesto adequado para ativar o campo e editar seu conteúdo
3. OUÇO ou percebo que posso editar o campo e que seu valor foi atualizado.

Validação da entrada

1. QUANDO uma entrada é rejeitada por uma regra de validação informada
2. VEJO uma mensagem associada ao campo que explica como corrigir a informação
3. E, quando navego até o campo com leitor de telas, OUÇO a indicação de erro e a orientação associada
4. ENTÃO, quando volto a editar, VEJO que o valor foi preservado para correção

Formato do e-mail

1. QUANDO envio um valor com formato de e-mail inválido
2. VEJO ou OUÇO uma orientação para corrigir o formato
3. A validação de formato não comprova a existência do endereço

Pontos de atenção

1. Usar um rótulo persistente associado ao input. Placeholder é uma dica complementar e não substitui o rótulo.
2. Associar instruções e erros ao campo, por exemplo com aria-describedby, e marcar aria-invalid quando houver erro.
3. Informar a obrigatoriedade e usar required quando necessário. Não comunicar erros apenas por cor.
4. Manter foco visível e garantir contraste e área de interação adequados.
5. A validação de formato não comprova que o endereço existe. Aceitar um endereço por padrão; usar multiple apenas se o contexto pedir vários endereços e explicar como separá-los.

Referências

Documentação do campo

• MDN — input type="email" (link externo, abre em uma nova aba)

Design System

• GOV.UK — Email addresses open_in_new (link externo, abre em uma nova aba) — Padrão específico para e-mail, com type="email", autocomplete e mensagens de erro.
• GOV.UK — Text input open_in_new (link externo, abre em uma nova aba) — Componente de base utilizado pelo padrão de e-mail.
• Bootstrap — Form controls open_in_new (link externo, abre em uma nova aba) — Exemplo de campo type="email".
• Carbon — Text input open_in_new (link externo, abre em uma nova aba) — Orientações gerais de campos de texto, complementares ao tipo e-mail.