Acessibilidade

O formulário que você cria é para pessoas. As pessoas usam dispositivos diferentes. Alguns usam mouse, outro dispositivo de toque, um teclado ou um dispositivo controlado por movimentos oculares. Alguns usam um leitor de tela, outros usam uma tela pequena e outros usam 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.

Verifique se os usuários entendem a finalidade de um campo de formulário

Há muitos controles de formulários disponíveis. O que todos eles têm em comum? Todo 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 de formulários e é lido por leitores de tela.

Além disso, ao tocar ou clicar no <label>, o controle de formulário associado é concentrado, o que o torna um alvo maior.

Use HTML significativo para acessar recursos integrados do navegador

Em teoria, você poderia criar um formulário usando apenas elementos <div>. Você pode até mesmo fazer com que pareça um <form> nativo. Qual é o problema de usar elementos não semânticos?

Os elementos de formulário integrados oferecem muitos recursos integrados. Vamos conferir um exemplo.

Visualmente, a <input> (o primeiro do exemplo) e a <div> têm a mesma aparência. Você pode até mesmo inserir texto para ambas, já que o <div> tem um atributo contenteditable. No entanto, há muitas diferenças entre usar um elemento <input> adequado e um <div> semelhante a uma <input>.

Um usuário de leitor de tela não reconhece o <div> como um elemento de entrada e não consegue preencher o formulário. Tudo o que o usuário do leitor de tela ouve é "Nome", sem indicação de que o elemento é um controle de formulário para adicionar texto.

Clicar em <div>Name</div> não foca o <div> que o acompanha, enquanto <label> e <input> são conectados usando os atributos for e id.

Depois de enviar o 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. O uso do atributo inputmode em um <div> não pode fazer isso.

Garantir que os usuários estejam cientes do formato de dados esperado

É possível 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 você pode garantir que os usuários também conheçam a regra de validação? Conte.

Adicione informações sobre o formato esperado diretamente abaixo do controle do formulário. Para deixar isso 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, você aprendeu a mostrar mensagens de erro no 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 ele for enviado. Os leitores de tela também anunciam a mensagem de erro.

Também é possível definir sua própria mensagem de erro:

Este exemplo precisa de mais mudanças para conectar a mensagem de erro ao controle de formulário.

Uma abordagem simples é usar o atributo aria-describedby no controle de formulário que corresponde ao id no elemento da mensagem de erro. Em seguida, use aria-live="assertive" para a mensagem de erro. As regiões ativas ARIA anunciam um erro aos usuários do leitor de tela no momento em que ele aparece.

O problema com essa abordagem para formulários com vários campos é que o aria-live geralmente anuncia somente o primeiro em caso de vários erros. Como explicado neste artigo sobre vários avisos do aria-live na mesma ação, é possível criar uma única mensagem concatenando todos os erros. Outra abordagem seria anunciar que há erros e, em seguida, anunciar erros individuais quando o campo estiver em foco.

Garantir que os usuários reconheçam os erros

Às vezes, os designers colorem o estado inválido de 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 vermelha parecem quase o mesmo. É impossível ver se a mensagem está relacionada a um erro.

Além da cor, use um ícone ou o tipo de erro nas mensagens.

<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ários com CSS. Uma desconexão entre a ordem visual e a navegação pelo teclado (ordem DOM) é problemática para usuários de leitores de tela e teclados.

Saiba mais sobre como garantir que a ordem visual na página siga a ordem do DOM.

Ajudar os usuários a identificar o controle de formulário em foco no momento

Use o teclado para navegar deste formulário. Você reconheceu que o estilo dos controles do formulário mudou quando eles ficaram ativos? Esse é o estilo de foco padrão. Você pode substituí-la pela pseudoclasse CSS :focus. Independentemente do estilo usado em :focus, sempre verifique se a diferença visual entre o estado padrão e o estado de foco é reconhecível.

Saiba mais sobre como criar indicadores de foco.

Verificar se o formulário pode ser usado

Você pode identificar muitos problemas comuns preenchendo o formulário em diferentes dispositivos. Use apenas o teclado, use um leitor de tela (como o NVDA no Windows ou o VoiceOver no Mac) ou aumente o zoom da página para 200%. Sempre teste seus 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 um software de ampliação de texto? Peça para preencherem o formulário. As avaliações de acessibilidade são ótimas, e os testes com usuários reais são ainda melhores.

Saiba mais sobre como fazer uma análise de acessibilidade e como testar com usuários reais.

Recursos