Formulários Acessíveis

O que é?

Conjunto de boas práticas para criar formulários acessíveis. Inclui regras para rótulos, instruções, mensagens de erro e agrupamento de campos.

Formulários acessíveis devem ser totalmente operáveis por teclado (Tab / Shift + Tab / Enter / Espaço / ESC). Por isso, devem apresentar:

rótulos (labels) visíveis e associados aos campos, não só textos dentro do campo (placeholders);
instruções sobre formato e obrigatoriedade dos dados;
mensagens de erro claras e próximas ao campo correspondente;
agrupamento de campos (fieldset/legend) para informações relacionadas;
ordem lógica de navegação pelo teclado (tabulação).

Por que é importante?

Formulários inacessíveis bloqueiam inscrições e avaliações.

Grande parte das interações (inscrição, cadastro, avaliação, feedback) ocorre por formulários. Sem labels, instruções e mensagens de erro adequadas, pessoas com deficiência visual, motora ou cognitiva ficam excluídas. Boas práticas aumentam a taxa de conclusão, reduzem retrabalho e atendem às exigências normativas.

Quando utilizar?

Sempre que houver campos para preenchimento.

As diretrizes devem ser aplicadas em todos os casos que envolvam campos de entrada de dados, como em ambientes virtuais de aprendizagem (AVA), conteúdos em HTML (como páginas web e interfaces digitais), PDFs, cadastros, pesquisas e processos administrativos.

Como aplicar?

Usar labels (rótulos), instruções claras, erros perceptíveis e navegação por teclado.

Rótulos (labels): associe cada campo a um <label for>, não apenas a placeholder (texto dentro do campo). Use labels , instruções claras, erros perceptíveis e navegação por teclado.
Obrigatoriedade: indique em texto (“Campo obrigatório”), não apenas por cor ou asterisco.
Mensagens de erro: claras, próximas ao campo com problema e associadas ao foco (ex.: uso de aria-describedby para tecnologias assistivas).
Agrupamento de campos: use <fieldset> e <legend> para campos relacionados (exemplo: dados pessoais).
Formato de dados: forneça exemplos (ex.: “dd/mm/aaaa”).
Botões: use textos descritivos (ex.: “Enviar inscrição”).
Navegação por teclado: ordem de Tab lógica e foco sempre visível.
Apoio à compreensão: use Linguagem Simples, etapas claras e feedback imediato (resposta após ação do usuário).
Orientação geral: quando possível, informe no início o passo a passo, canais de ajuda e opção de salvar e continuar depois.

Método de verificação

Testar a navegação por teclado, leitores de tela e clareza das mensagens.

Teclado: percorra todo o formulário por Tab / Shift + Tab; verifique foco visível e ordem lógica.
Leitor de tela (NVDA / JAWS / VoiceOver): confirme leitura do label, instruções e erro do campo.
Teste de erro: preencha propositalmente errado; verifique se a mensagem explica o que corrigir.
Automação (Axe / WAVE / Lighthouse): use-o como auxílio, mas não deixe de aplicar um teste humano.

Exemplos

Aplique label associado juntamente com mensagem erro claro. Não aplique placeholder como label juntamente com mensagem de erro só por cor.

Corretos:

Campo “E-mail” com label visível + instrução “Use nome@dominio.com”; Mensagem de erro clara: “Formato inválido. Exemplo: nome@dominio.com”;
Conjunto “Endereço” com <fieldset>/<legend>;
Botão com rótulo descritivo, como “Enviar inscrição”, indicando claramente a ação.

Incorretos:

Placeholder (texto dentro do campo, por exemplo “Digite aqui”) usado como único rótulo;
Mensagem de erro só por cor (exemplo: vermelho), sem texto explicativo;
Campo obrigatório indicado apenas por asterisco, sem texto complementar.

O que não fazer?

Não utilize placeholder como substituto de label, indicação de erro apenas por cor e ordem de tabulação incorreta ou interrompida.

Não esqueça o <label>, pois sua ausência dificulta identificar e preencher o campo.
Não indicar obrigatoriedade só por cor ou asterisco, pois nem todos percebem esses sinais.
Não use mensagens genéricas (exemplo: "erro no formulário"), pois não indicam o que deve ser corrigido.
Não use label sem instrução de formato (exemplo: data/CPF), pois o usuário pode ficar em dúvida como preencher.
Não aplique tabindex positivo, pois quebra a ordem natural de navegação.
Não use botões com mensagens vagas (exemplo: “OK”), pois o texto deve indicar a ação do botão.

Normas de referência

WCAG 1.3.1; WCAG 2.4.6; WCAG 3.3.1–3.3.4; WCAG 4.1.2; NBR 17225; eMAG

WCAG 1.3.1 (Informação e relações): assegura ligação semântica entre labels e campos.
WCAG 2.4.6 (Cabeçalhos e rótulos): descreve claramente o propósito de cabeçalhos e rótulos.
WCAG 3.3.1 (Identificação de erro): informa erros detectados ao usuário.
WCAG 3.3.2 (Rótulos e instruções): fornece orientação clara para o preenchimento.
WCAG 3.3.3 (Sugestão de correção): sugere como corrigir erros identificados.
WCAG 3.3.4 (Prevenção de erro): permite revisão ou confirmação antes do envio.
WCAG 4.1.2 (Nome, função, valor): expõe corretamente nome, função e valor dos componentes.
NBR 17225 (Norma brasileira convergente às diretrizes internacionais) e eMAG (Guia de acessibilidade para governo eletrônico) alinham esses requisitos ao contexto brasileiro e governamental.

Outras normas relacionadas:

WCAG 2.4.3 (Ordem do foco): garante tabulação coerente entre campos.
WCAG 2.4.7 (Foco visível): foco sempre perceptível ao navegar.
Conectar com WCAG 1.4.3 (Contraste) para legibilidade dos rótulos e mensagens.

Saiba mais

Tutoriais W3C/WebAIM; docs Moodle/Word/PDF

W3C – Tutorial para Formulários Acessíveis (em inglês): https://www.w3.org/WAI/tutorials/forms/;
WebAIM – Formulários acessíveis, páginas 1, 2 e 3 (em inglês): https://webaim.org/techniques/forms/;
Documentação de acessibilidade do Moodle: https://moodle.com/pt-br/acessibilidade/
Adobe – Campos e tags em PDF:
- PDF: https://helpx.adobe.com/br/acrobat/using/pdf-form-field-basics.html
- Tags: https://helpx.adobe.com/br/sign/using/text-tag.html.
Para mensagens de erro, ver também padrões de Design System governamentais: https://www.gov.br/ds/home.

Índice