O formulário que você cria é para pessoas. As pessoas usam dispositivos diferentes. Alguns usam um mouse, outros, um dispositivo sensível ao toque, outros, o teclado, outros, um dispositivo controlado por movimentos oculares. Alguns usam um leitor de tela, outros usam uma tela pequena e outros usam um software de ampliação de texto. Todos querem usar seu formulário. Saiba como tornar seu formulário acessível e utilizável para todos.
Garantir que os usuários entendam a finalidade de um campo de formulário
Existem muitos controles de formulário para você escolher.
O que todos eles têm em comum?
Cada controle de formulário precisa ter um elemento <label> associado.
O elemento <label> descreve a finalidade de um controle de formulário.
O texto <label> é visualmente associado ao controle do formulário e lido por leitores de tela.
Além disso, tocar ou clicar no <label> foca o controle do formulário associado,
para torná-lo um alvo maior.
Use HTML significativo para acessar os recursos integrados do navegador
Teoricamente, você poderia criar um formulário usando apenas elementos <div>.
É possível até mesmo fazer com que ele pareça um <form> nativo.
Qual é o problema de usar
elementos não semânticos?
Os elementos de formulário integrados oferecem vários recursos integrados. Vamos conferir um exemplo.
Visualmente, a <input> (a primeira no exemplo) e a <div> têm a mesma aparência.
Você pode até mesmo inserir texto para ambos, já que a <div> tem uma
contenteditable.
No entanto, há muitas diferenças entre usar um elemento <input> apropriado e um <div>
que parece um <input>.
Um usuário de leitor de tela não reconhece <div> como um elemento de entrada.
e não consegue preencher o formulário.
Tudo que o usuário do leitor de tela ouve é "Nome",
sem indicação de que o elemento é um controle de formulário para adição de texto.
Clicar em <div>Name</div> não foca o <div>, enquanto <label> e
<input> são conectados usando os atributos for e id.
Após o envio do formulário, os dados inseridos no <div> não são incluídos na solicitação.
Embora seja possível anexar os dados com JavaScript,
um <input> faz isso por padrão.
Os elementos de formulário integrados têm outros recursos.
Por exemplo, com elementos de formulário adequados e a inputmode ou type correta,
um teclado na tela mostra os caracteres adequados. Como usar o atributo inputmode em uma <div>
não pode fazer isso.
Garantir que os usuários estejam cientes do formato de dados esperado
Você pode definir várias regras de validação para um controle de formulário.
Por exemplo, digamos que um campo de formulário sempre tenha pelo menos oito caracteres.
Use o atributo minlength, indicando a regra de validação para os navegadores.
Como garantir que os usuários também saibam sobre a regra de validação? Conte a eles.
Adicione informações sobre o formato esperado logo abaixo do controle de formulário.
Para deixar claro
para dispositivos assistivos,
use o atributo aria-describedby no controle de formulário
e um id na mensagem de erro com o mesmo valor, para conectar os dois.
Ajudar os usuários a encontrar a mensagem de erro de um controle de formulário
Em um módulo anterior sobre validação, e aprendeu a mostrar mensagens de erro em caso de entrada de dados inválida.
<label for="name">Name</label>
<input type="text" name="name" id="name" required>
Por exemplo, se um campo tiver um atributo required e dados inválidos forem inseridos, o navegador vai mostrar
uma mensagem de erro ao lado do controle de formulário quando o formulário é enviado. Os leitores de tela também anunciam a mensagem de erro.
Você também pode definir sua própria mensagem de erro:
Este exemplo precisa de mais alterações para conectar a mensagem de erro ao controle de formulário.
Uma abordagem simples é usar o aria-describedby
no controle de formulário que corresponde ao id no elemento da mensagem de erro.
Depois, use aria-live="assertive" para a mensagem de erro.
As regiões ativas ARIA anunciam um erro para os usuários do leitor de tela assim que ele é mostrado.
O problema dessa abordagem para formulários com vários campos,
é que o aria-live geralmente anuncia apenas o primeiro erro caso ocorram vários.
Conforme explicado neste artigo sobre vários avisos aria-live na mesma ação, você pode criar uma única mensagem concatenando todos os erros. Outra abordagem seria anunciar que há erros e os erros individuais quando o campo estiver focado.
Garantir que os usuários reconheçam os erros
Às vezes, os designers colocam
o estado inválido em vermelho,
usando a pseudoclasse :invalid.
No entanto, para comunicar um erro ou sucesso,
você nunca deve confiar apenas na cor.
Para pessoas com daltonismo vermelho-verde,
uma borda verde e uma vermelha parecem quase a mesma coisa.
É impossível verificar se a mensagem está relacionada a um erro.
Além da cor, use um ícone ou prefixe suas mensagens de erro com o tipo de erro.
<span class="error">
<strong>Error:</strong>Please use at least eight characters.
</span>
Ajudar os usuários a navegar pelo formulário
É possível alterar a ordem visual dos controles de formulário com CSS. Uma desconexão entre a ordem visual e a navegação por teclado (ordem DOM) é problemático para usuários de leitores de tela e teclado.
Saiba mais sobre como garantir a ordem visual na página segue a ordem do DOM.
Ajudar os usuários a identificar o controle de formulário em foco no momento
Use o teclado para navegar
este formulário.
Você sabia que o estilo dos controles do formulário mudou quando eles ficaram ativos?
Esse é o estilo de foco padrão.
É possível substituí-lo pelo
Pseudoclasse :focus CSS.
Qualquer que seja o estilo usado no :focus,
Certifique-se de que a diferença visual entre o estado padrão e o estado de foco seja reconhecível.
Saiba mais sobre elaboração de indicadores de foco.
Verifique se o formulário pode ser usado
Preencha seu formulário em dispositivos diferentes para identificar diversos problemas comuns. Use apenas o teclado, um leitor de tela (como NVDA no Windows ou VoiceOver no Mac), ou aplicar zoom à página em 200%. Sempre teste os formulários em diferentes plataformas, especialmente dispositivos ou configurações que você não usa todos os dias. Você conhece alguém que usa um leitor de tela ou alguém que usa um software de ampliação de texto? Peça para ele preencher o formulário. As avaliações de acessibilidade são ótimas, e testar com usuários reais é ainda melhor.
Saiba mais sobre como fazer uma avaliação de acessibilidade e como testar com usuários reais.