Formulários acessíveis: rótulos, mensagens de erro e autocomplete

Objetivo

Formulários que uma pessoa usando teclado, leitor de tela, entrada por voz ou preenchimento automático do navegador consiga preencher e, quando algo estiver errado, corrigir sem ter de adivinhar.

Pré-requisitos

Controles nativos (input, select, textarea, button type="submit") em vez de elementos div estilizados, e uma lista escrita dos campos com suas regras de validação e a indicação de quais são obrigatórios.

Passos

1. Associe um rótulo explícito a cada controle: <label for="email">, cujo for corresponda ao id do controle (a associação preferida no tutorial da WAI). Use aria-label ou aria-labelledby apenas quando um rótulo visível não for possível; texto de placeholder não é um rótulo.
2. Agrupe controles relacionados com fieldset e legend (grupos de radio buttons, blocos de endereço), para que o nome do grupo seja anunciado junto com cada opção.
3. Indique a obrigatoriedade no texto do rótulo ("Nome (obrigatório)") e adicione o atributo required, para que navegadores e tecnologias assistivas também a reconheçam.
4. Adicione tokens autocomplete aos campos que se referem ao usuário: name, given-name, family-name, email, username, new-password, current-password, one-time-code, postal-code. A MDN observa que tokens válidos atendem ao critério de sucesso 1.3.5 (Identify Input Purpose) da WCAG 2.2 e que valores inválidos ou inventados, usados para impedir o preenchimento automático, também não atendem a esse critério, pois a finalidade deixa de ser legível por máquina.
5. Valide no envio, mantenha os valores digitados e descreva como corrigir cada problema ("Informe a data no formato DD/MM/AAAA"), em vez de apenas dizer que o valor é inválido.
6. Em caso de falha, exiba no topo um resumo de erros com um link para cada campo, marque cada campo com aria-invalid="true" e conecte a respectiva mensagem com aria-describedby; mova o foco para o resumo ou para o primeiro campo inválido.
7. Quando a validação ocorrer sem recarregar a página, anuncie o resultado em uma região live (role="alert"), para que os leitores de tela o falem.
8. Confirme o sucesso também por texto, e não só por cor, e peça confirmação antes de envios destrutivos.
9. Teste usando apenas o teclado, com um leitor de tela e com o preenchimento automático do navegador ativado.

Resultado esperado

Cada campo tem um nome acessível e uma finalidade legível por máquina; cada erro pode ser alcançado pelo teclado, é lido pelas tecnologias assistivas e diz ao usuário o que deve mudar; o preenchimento automático preenche os campos corretos.

Limites e base de verificação

Segue os tutoriais da WAI e a referência da MDN citados. Verificadores automáticos encontram rótulos ausentes, mas não mensagens pouco úteis; widgets personalizados exigem padrões ARIA completos, fora do escopo deste artigo. Nenhuma medição é afirmada.