Formulários acessíveis: etiquetas, dicas e mensagens de erro

Seis critérios de sucesso para formulários

As WCAG 2.2 são a recomendação atual do W3C para conteúdos web acessíveis. Para os textos de um formulário, seis dos seus critérios de sucesso são os mais importantes:

• 1.3.1 Informações e relações (nível A): o que o layout mostra, como a etiqueta que pertence a cada campo, também está disponível no código ou em texto.
• 1.3.5 Identificar a finalidade da entrada (nível AA): os campos que pedem informações sobre o utilizador, como o nome ou o e-mail, indicam a sua finalidade no código.
• 3.3.1 Identificação de erros (nível A): se um erro de entrada for detetado automaticamente, o campo é identificado e o erro é descrito em texto.
• 3.3.2 Etiquetas ou instruções (nível A): há etiquetas ou instruções quando o conteúdo exige uma entrada do utilizador.
• 3.3.3 Sugestão de erro (nível AA): se um erro for detetado e se conhecer uma correção, esta é sugerida, a menos que isso ponha em risco a segurança ou a finalidade do conteúdo.
• 4.1.2 Nome, função, valor (nível A): cada controlo tem um nome e uma função que o software consegue ler.

Cada campo precisa de uma etiqueta visível

Uma etiqueta diz o que deve ir no campo e continua visível enquanto o utilizador escreve. Em HTML, liga o elemento label ao campo: o atributo for da etiqueta tem exatamente o mesmo valor que o id do campo. Os leitores de ecrã leem então a etiqueta com o campo, e um clique na etiqueta coloca o cursor no campo. Um botão recebe a etiqueta do seu texto, e 'Enviar mensagem' diz mais do que 'Submeter'. As etiquetas ficam normalmente à direita dos botões de opção e das caixas de verificação e à esquerda ou por cima dos outros campos; as etiquetas por cima dos campos ocupam menos espaço em largura.

Um placeholder não é uma etiqueta

O texto cinzento dentro de um campo vazio parece uma etiqueta, mas não é. O W3C aponta os problemas:

• Desaparece assim que alguém escreve, o que torna mais difícil verificar o que se introduziu antes de enviar.
• Os navegadores mostram-no muitas vezes numa cor clara, com contraste insuficiente.
• Os leitores de ecrã não o tratam como etiqueta, e o suporte varia.

Usa um placeholder, no máximo, para um exemplo e põe tudo o que é importante na etiqueta ou numa dica.

Dicas e campos obrigatórios

• Põe as regras numa dica: o formato da data, o comprimento de um número de cliente, o que uma palavra-passe precisa de ter. Em HTML podes ligar a dica com aria-describedby, para que os leitores de ecrã a leiam depois da etiqueta.
• Indica que campos são obrigatórios e quais são opcionais. Se usares um asterisco, explica-o uma vez no início do formulário.
• Põe as instruções para todo o formulário antes do formulário, por exemplo sobre um limite de tempo.
• Mantém as dicas curtas. Demasiadas instruções tornam um formulário mais difícil, não mais fácil.

Agrupar campos relacionados

Os botões de opção e as caixas de verificação que pertencem ao mesmo conjunto agrupam-se com o elemento fieldset, e o elemento legend dá nome ao grupo, por exemplo 'Como devemos contactar-te?'. O W3C diz que os grupos de botões de opção devem ser sempre agrupados desta forma. Mantém a legenda curta, porque alguns leitores de ecrã leem-na com cada campo. Os grupos também ajudam em campos com a mesma etiqueta, como a rua numa morada de entrega e numa morada de faturação.

autocomplete: deixa o navegador ajudar

Para os campos que pedem informações sobre o utilizador, o 1.3.5 exige que a sua finalidade possa ser determinada no código. As WCAG 2.2 têm uma lista destas finalidades, baseada na secção de preenchimento automático da especificação HTML, como name, given-name, family-name, email, tel, street-address e postal-code. Em HTML defines estas finalidades com o atributo autocomplete, por exemplo autocomplete="email". Os navegadores podem então preencher valores guardados, o que poupa escrita. Os campos que não dizem respeito ao utilizador não precisam de finalidade.

Mensagens de erro que ajudam

Uma mensagem de erro tem três tarefas: identificar o campo, dizer o que está errado e dizer como corrigir. O 3.3.1 exige as duas primeiras, em texto, por isso um contorno vermelho ou um ícone sozinhos não chegam. O 3.3.3 exige a correção, quando é conhecida.

• Mostra a mensagem junto ao campo e liga-a com aria-describedby, para que os leitores de ecrã a leiam com o campo.
• Depois do envio, mostra no topo, antes do formulário, uma lista de todos os erros sob um título claro. Cada entrada identifica o campo, o problema e a correção, e tem uma ligação para o campo.
• Atualiza também o título da página, por exemplo '2 erros – Formulário de contacto', e move o foco para o primeiro campo com erro.
• Mantém o que o utilizador já introduziu. Isto é um conselho nosso, não uma regra das WCAG: voltar a escrever tudo depois de um só erro faz as pessoas desistir.

Verifica o teu formulário com o Do4U

A ferramenta Textos de formulários verifica os textos de um formulário web. Colas o HTML do formulário ou indicas o endereço da página, e podes acrescentar as mensagens de erro que o teu formulário mostra. O código lê cada campo: a etiqueta e de onde ela vem, dicas, placeholders, campos obrigatórios, valores de autocomplete e grupos de botões de opção ou caixas de verificação. Encontra problemas como um campo sem etiqueta, um placeholder como única etiqueta, campos obrigatórios que o texto não menciona, valores de autocomplete em falta e mensagens de erro vagas, cada um com o respetivo critério de sucesso. A IA sugere uma etiqueta clara, uma dica curta e uma mensagem de erro que identifica o campo e diz como corrigir a entrada. O código verifica cada sugestão e cria um rascunho de HTML melhorado a partir do teu formulário.

O Do4U encontra pistas e cria um rascunho; tu verificas e decides. A ferramenta verifica a marcação, não os teus estilos, scripts ou a utilização com teclado, e não te diz se o teu formulário é acessível. Testa o formulário melhorado com um teclado e um leitor de ecrã.