Rótulos de formulário

Uma caixa de texto ao lado da palavra "Email" não está rotulada até o elemento label ser ligado a ela; até lá, um leitor de tela pode dizer só "editar texto".

Todo campo precisa de um nome

Quando o foco cai num campo de formulário, um leitor de tela anuncia o rótulo, o tipo e o estado dele: "Email, editar texto, obrigatório". O rótulo vem de um elemento label ligado ao campo. Há dois jeitos de ligá-los. Dê ao input um id e ao label um for correspondente, ou ponha o input dentro do label. De qualquer jeito, clicar no texto do rótulo também leva o foco para o campo, o que deixa caixas de seleção e botões de opção pequenos muito mais fáceis de acertar.

<label for="email">Email</label>
<input id="email" type="email" autocomplete="email">

<label>
  <input type="checkbox" name="news"> Send me the weekly menu
</label>

O critério de sucesso 3.3.2 Rótulos ou Instruções da WCAG 2.2, de nível A, pede rótulos ou instruções sempre que o conteúdo exige entrada do usuário, e o 1.3.1 Informações e Relações pede que a ligação entre rótulo e campo exista no código, não só na tela. Um parágrafo que por acaso fica acima de um input só está perto visualmente; nada diz à tecnologia assistiva que os dois andam juntos.

Placeholders não são rótulos

O atributo placeholder mostra um texto de dica cinza dentro de um campo vazio. Dá vontade de usá-lo no lugar de um rótulo, e muitos formulários de cadastro fazem isso. O problema é que ele some assim que você digita, então não dá para conferir para que servia o campo, e em geral ele é pálido o bastante para falhar nas regras de contraste da unidade anterior. Use um rótulo visível e, se quiser, também um placeholder com um valor de exemplo.

Grupos, propósito e erros

Botões de opção e caixas de seleção relacionadas também precisam de um rótulo de grupo. Envolva-os num fieldset e ponha a pergunta no legend dele, para que um leitor de tela diga "Tamanho, grupo" antes de "Pequeno, botão de opção, 1 de 3". Para dados pessoais, o atributo autocomplete diz ao navegador para que serve um campo, usando nomes do padrão HTML como name, email, tel, new-password e one-time-code. O critério 1.3.5 Identificar o Propósito de Entrada, de nível AA, pede exatamente isso, porque permite que os navegadores preencham os campos e que algumas ferramentas mostrem ícones conhecidos ao lado deles.

Quando algo dá errado, diga isso em palavras. O critério 3.3.1 Identificação do Erro pede que um erro de entrada seja identificado e descrito ao usuário em texto, e não só deixando a borda vermelha. A WCAG 2.2 também acrescentou o 3.3.7 Entrada Redundante: uma informação que a pessoa já digitou no mesmo processo deve ser preenchida de novo para ela ou oferecida para seleção, em vez de ser digitada duas vezes. E o 3.3.8 Autenticação Acessível (Mínimo), de nível AA, diz que uma etapa de login não pode depender de lembrar ou transcrever algo, a menos que haja ajuda disponível; deixar os gerenciadores de senhas preencherem o campo e permitir colar contam como essa ajuda.

Diga o que é preciso antes de a pessoa começar

As instruções vêm antes dos campos que descrevem, e não numa mensagem de erro depois que alguém falhou. Se uma senha precisa ter pelo menos 15 caracteres, diga isso ao lado do rótulo. Marque os campos obrigatórios no texto do rótulo, por exemplo com a palavra "obrigatório", e acrescente o atributo required para que o navegador também o anuncie. Quando uma mensagem de erro aparecer, mantenha-a ao lado do seu campo e ligue os dois com aria-describedby apontando para o id da mensagem; assim o leitor de tela lê a mensagem quando o campo recebe o foco. Por fim, leve o foco para o primeiro campo com problema, ou para um resumo dos erros no topo, para que quem usa teclado não fique no fim de um formulário comprido sem saber o que aconteceu.