#TheDevConf 2017 — Trilha Acessibilidade: Desenvolvendo formulários acessíveis

Relato da palestra de Deivid Marques na Trilha Acessibilidade do The Developer’s Conference São Paulo.

Deivid Marques explicando um recurso, apontando para o computador. Crédito da foto: The Developer’s Conference.

Este post faz parte da série de relatos sobre as palestras da Trilha Acessibilidade do TDC-SP 2017.


O Deivid Marques, desenvolvedor na Locaweb, apresentou uma palestra com demonstrações de código para o projeto de formulários acessíveis. Formulários são recursos importantes em páginas web para permitir que as pessoas possam entrar em contato, enviar reclamações/sugestões, realizar cadastros e fazer compras.

Para as pessoas que poderiam não conhecer os recursos básicos para testar acessibilidade de sites, Deivid forneceu uma visão geral sobre leitores de tela, algumas boas práticas, explicações sobre o WAI-ARIA e as seguintes dicas:

  • Implementar acessibilidade desde o início do projeto;
  • Fornecer navegação via teclado;
  • Criar teclas de atalho para funcionalidades principais
  • Se necessário, prover uma página específica com detalhes das teclas de atalho;
  • Evitar o uso de Captcha;
  • Testar em leitores de tela;
  • Testar com usuários reais.

Em seguida, Deivid forneceu exemplos sobre como é possível desenvolver formulários acessíveis de forma simples.

A primeira recomendação é sempre associar um rótulo (<label>) aos controles de formulário para que os campos possam ser lidos adequadamente por leitores de tela. Os campos obrigatórios não devem ser marcados somente com um asterisco (*) no rótulo, pois isto é útil somente a pessoas videntes. Ao associar o atributo required=”true” em um controle de formulário, o leitor de telas irá reconhecer e vocalizar que é um campo obrigatório, conforme exemplo a seguir.

<label for=”campo1">* Nome:</label>
<input id=”campo1" aria-required=”true” type=”text”>

Além do required, é preciso informar claramente quando o campo está com erro e qual é o problema. Visualmente, é sempre recomendável inserir o texto do erro logo abaixo do campo correspondente. Para leitores de tela, pode ser usado os atributos aria-invalid e aria-label para informar que o campo está inválido e qual a mensagem de erro:

<input id=”campo1" aria-required=”true” aria-invalid="true" aria-label="O campo Nome é obrigatório" type=”text”>

As confirmações de envio do formulário ou de aviso de erros devem ser informadas adequadamente a pessoas que usam leitores de tela. Elas precisam ser avisadas de que uma ação precisa ser tomada ou que ocorreu tudo correto com o envio. Isto pode ser feito utilizando a role=”alert” no elemento que contém a mensagem, assim, o elemento irá se comportar para o leitor de tela como uma janela de alerta. Para que ele seja lido de imediato pelo leitor de telas, é importante que seja definido via JavaScript o foco neste elemento:

<div class=”alert-sucess” role=”alert”>
Mensagem enviada com sucesso!
</div>

Outros exemplos fornecidos pelo Deivid para uso de atributos do WAI-ARIA:

  • aria-hidden=”true”: Esconder elementos do leitor de tela;
  • aria-expanded=”true/false”: Usado em collapses (elementos que podem ser expandidos ou recolhidos);
  • role=”menu-item”: Indica que o link faz parte de um menu;
  • aria-invalid=”gramar/spelling/true”
    gramar: erro de gramática, 
    spelling: erro de ortografia
    true: erro de validação;
  • role=”dialog”: Usado em modais.

Por fim, o Deivid fez uma demonstração utilizando o criador de sites da Locaweb e também utilizando um exemplo de formulário acessível que ele desenvolveu.

Slides da palestra Desenvolvendo formulários acessíveis.


A Utilizza é uma empresa de design de interação e experiência do usuário focada em acessibilidade digital. Realiza avaliações de acessibilidade de websites, testes manuais exploratórios em aplicações nativas e web e treinamento de acessibilidade para equipes de desenvolvimento e testes/quality assurance (QA). Entre em contato através dos canais no Facebook, Twitter ou LinkedIn.