1 em cada 4 adultos americanos vive com alguma forma de deficiência. Se o teu formulário não é acessível, estás a excluir um quarto do teu público potencial antes de chegar ao botão de envio.
Um formulário acessível funciona para todos. Isso inclui utilizadores que só usam o teclado. Pessoas que ouvem através de leitores de ecrã. Utilizadores com visão reduzida. Pessoas com tremores que precisam de mais tempo para preencher os campos. Sem design especial, sem complexidade extra. Apenas um formulário construído para que todas estas pessoas o consigam mesmo usar.
Etiquetas claras. Navegação por teclado. Mensagens de erro que um leitor de ecrã consegue anunciar. Contraste suficiente para que utilizadores com visão reduzida leiam o texto. Não são funcionalidades extra. São o mínimo que a WCAG 2.1 AA e a Americans with Disabilities Act (ADA) exigem a partir de abril de 2026.
O que torna os formulários acessíveis diferentes
Pega em qualquer formulário de contacto e vais encontrar os mesmos erros. Um campo de texto com um texto de exemplo, mas sem etiqueta visível. Uma caixa de seleção sem explicação do que faz. Uma mensagem de erro em texto vermelho que um leitor de ecrã não consegue anunciar.
A maioria dos formulários é construída para utilizadores de rato, e a acessibilidade é acrescentada mais tarde, como um pensamento tardio. Um formulário acessível funciona ao contrário. Assume desde o início que as pessoas o vão usar de formas diferentes. Umas com rato, outras só com teclado. Umas a lê-lo, outras a ouvir um leitor de ecrã.
Isso muda a forma como constróis o formulário. Os textos de exemplo tornam-se inúteis sem etiquetas. Os asteriscos vermelhos tornam-se inúteis sem texto. Uma disposição visual que funciona para quem usa rato pode prender quem usa teclado. Um formulário acessível não é mais difícil de construir. Só exige pensar em padrões de interação para além do rato.
Porque importa
Prazo legal. O Título II da ADA exige a WCAG 2.1 AA até 24 de abril de 2026. O incumprimento já não é um risco. É uma responsabilidade atual.
Impacto no negócio. Os visitantes com deficiência gastam dinheiro a sério. Um formulário acessível aumenta as taxas de conclusão para todos, porque etiquetas claras ajudam todos os utilizadores, não só as pessoas com deficiência. Utilizadores ocupados a percorrer o telemóvel às 6 da manhã. Utilizadores avançados que navegam pelo teclado. Toda a gente.
Benefício para o SEO. Os motores de pesquisa favorecem páginas em que os elementos interativos têm etiquetas e se navegam pelo teclado. Os formulários acessíveis posicionam-se melhor.
O que os formulários acessíveis realmente precisam
Etiquetas visíveis em todos os campos
Cada campo precisa de uma etiqueta. Não um texto de exemplo que desaparece. Não um atributo title. Uma etiqueta a sério, ali na página.
Um leitor de ecrã lê primeiro a etiqueta e depois anuncia o tipo de campo. "Nome, campo de texto." O utilizador sabe o que fazer. Sem etiqueta, ouve-se "campo de texto" e mais nada. O utilizador não faz ideia do que escrever.
Para quem vê, as etiquetas funcionam como no papel. Dizem o que vai em cada espaço em branco. Também aumentam a área clicável. Liga a etiqueta ao campo com o atributo for e os utilizadores podem clicar na etiqueta ou no campo para o selecionar. No telemóvel, esta área de clique maior faz diferença.
Funcionar só com o teclado
Muitas pessoas nunca tocam num rato. Deficiências motoras, visão reduzida, leitores de ecrã. Estes utilizadores navegam inteiramente com o teclado. Se o teu formulário precisa de rato, não é acessível.
Testa. Desliga o rato. Percorre o formulário só com a tecla Tab, as setas e o Enter. Deves conseguir chegar a todos os campos, escolher todas as opções e carregar em enviar sem mexer as mãos.
O contorno de foco tem de estar visível em cada passo. Sem estados de foco invisíveis. Os utilizadores precisam de saber onde estão no formulário. E a ordem do Tab importa. Os campos devem seguir da esquerda para a direita, de cima para baixo, como o formulário se lê. Se a tua disposição salta ou esconde campos, a ordem do Tab quebra-se e os utilizadores de teclado ficam presos.
Mensagens de erro que se anunciam de facto
Texto vermelho no topo do formulário não diz nada a um utilizador de leitor de ecrã. Submete, ouve silêncio e tenta outra vez. Depois desiste.
Liga o erro ao campo específico onde aconteceu. Quando um utilizador de leitor de ecrã chega a esse campo com o Tab, o erro é anunciado. E faz a mensagem de erro dizer o que corrigir, e não apenas "Inválido." Em vez de "Entrada inválida", diz "O email tem de incluir o símbolo @."
Usa atributos ARIA como aria-describedby para ligar a mensagem de erro ao campo. Quando o foco chega ao campo, o leitor de ecrã anuncia o erro automaticamente. Sem adivinhar.
Tornar o texto legível para quem tem visão reduzida
Etiquetas cinzento-claro sobre fundo branco são invisíveis para quem tem visão reduzida. A WCAG 2.1 AA exige um rácio de contraste de 4,5:1 para texto normal. Texto escuro sobre fundo claro, ou texto claro sobre fundo escuro. O contraste tem de ser óbvio.
O texto maior (18 pontos ou mais) pode usar um contraste de 3:1. Tudo o resto precisa de 4,5:1. Uma ferramenta de verificação de contraste demora 5 segundos. Passa cada etiqueta, botão e mensagem de erro por uma antes do lançamento.
Nunca uses só a cor para indicar campos obrigatórios. Um asterisco vermelho não diz nada a um utilizador daltónico. Acrescenta a palavra "obrigatório" junto ao campo. Os leitores de ecrã anunciam-na. Quem vê, lê-a. Toda a gente percebe texto.
Orientações campo a campo para formulários acessíveis
Campos de texto e áreas de texto
Nome, email, telefone, todos precisam de uma etiqueta diretamente por cima ou ao lado. Usa o elemento HTML <label> com um atributo for que corresponda ao id do campo.
Se o campo espera um formato específico, diz qual. "Formato: 555-123-4567" ajuda todos, especialmente quem funciona melhor com instruções explícitas.
As áreas de texto devem parecer aceitar respostas mais longas. Uma caixa de uma linha com a etiqueta "Mensagem" lê-se como uma resposta rápida. Uma caixa mais alta sinaliza "dá-me mais". O tamanho importa.
Listas pendentes e botões de opção
Cada lista pendente precisa de uma etiqueta. "Seleciona uma opção" e "Sim/Não" sem contexto são inúteis. Um utilizador de leitor de ecrã não faz ideia da pergunta que fazes. Torna a etiqueta da lista pendente clara sobre a escolha em causa.
Os botões de opção devem estar num fieldset com uma legenda. A legenda faz a pergunta. As opções respondem. "Qual descreve melhor o teu caso de uso?" com opções como "Comércio eletrónico", "Media", "SaaS". Um leitor de ecrã anuncia a legenda e depois cada opção. O utilizador percebe que está a escolher num grupo e para que serve o grupo.
Caixas de seleção
A etiqueta de uma caixa de seleção deve ler-se naturalmente. "Aceito os termos de serviço" como etiqueta, com a caixa ao lado. Não uma caixa nua, sem texto, que deixa os utilizadores a adivinhar o que faz.
Se há informação de apoio, como uma ligação para os termos completos, põe-na mesmo ao lado da caixa. Não a escondas. Os utilizadores precisam de saber com o que concordam antes de assinalar a caixa.
Os grupos de caixas de seleção funcionam como grupos de botões de opção. Uma legenda dá nome ao grupo e cada opção tem a sua etiqueta.
Botões
O texto do botão deve dizer o que acontece. "Submeter." "Enviar." "OK" serve para confirmações. "Ir" não. Sem etiquetas genéricas.
Se tens vários botões, torna-os distintos. "Cancelar" e "Submeter" são claros. Dois botões que dizem ambos "Seguinte" não são: um utilizador de leitor de ecrã ouve "botão seguinte, botão seguinte" e não faz ideia de qual é qual.
Onde ficam os formulários no teu site
Formulários de contacto em pop-ups. Subscrições de newsletter nos rodapés. Formulários de doação em páginas de missão. Formulários de inquérito no pagamento. Qualquer formulário, em qualquer lado, tem de ser acessível.
Os formulários em pop-up criam uma armadilha de foco se não os geres. Quando uma janela modal abre, o foco salta para dentro dela. Quando fecha, o foco volta ao botão que a abriu. Sem isto, os utilizadores de teclado ficam presos a percorrer a página de fundo.
Em páginas longas com formulários mais abaixo, acrescenta uma ligação para saltar. Os utilizadores de teclado não devem ter de percorrer 50 itens de navegação com o Tab para chegar ao teu formulário.
Erros comuns
Depender de texto de exemplo em vez de etiquetas
Um texto de exemplo que diz "Escreve o teu email" desaparece no momento em que alguém começa a escrever. Agora o utilizador não faz ideia para que servia o campo. Os leitores de ecrã nunca chegam a vê-lo.
Usa uma etiqueta a sério. Se quiseres um texto de exemplo para dicas de formato, tudo bem. Mas nunca o uses como a própria etiqueta.
Usar só a cor nos campos obrigatórios
Um asterisco vermelho é invisível para utilizadores daltónicos. Um ícone é invisível para leitores de ecrã. Usa a palavra "obrigatório" em texto. Toda a gente percebe texto.
Saltar os testes manuais
A estrutura HTML certa no papel não significa que o teu formulário funciona na realidade. As etiquetas podem estar demasiado longe dos campos. Os contornos de foco podem estar invisíveis. As mensagens de erro podem ser anunciadas mas não mover o foco para o campo.
Testa com um teclado. Testa com um leitor de ecrã. Há leitores de ecrã gratuitos, outros que são o padrão do setor e um integrado no iOS, se testares no iOS. Os verificadores automáticos apanham os problemas óbvios. Os testes reais apanham o resto.
Acrescentar limites de tempo
Um utilizador com tremores escreve devagar. Um utilizador de leitor de ecrã precisa de tempo para ouvir todas as etiquetas e instruções. Um limite de 5 minutos prende utilizadores que precisam de 10.
Remove os limites de tempo, se puderes. Se tiveres mesmo de os ter, deixa os utilizadores prolongar o tempo duas vezes antes de a sessão terminar.
Como o WEMASY cria formulários acessíveis
Os formulários do WEMASY são criados acessíveis desde o início, e não como um pensamento tardio. Cada modelo inclui etiquetas adequadas. O foco é gerido automaticamente. Os erros são anunciados aos leitores de ecrã. O contraste de cor cumpre a WCAG 2.1 AA por defeito.
Personaliza sem quebrar a acessibilidade. Acrescenta campos, muda etiquetas, reorganiza a disposição. A estrutura de base mantém-se acessível. A validação incorporada anuncia os erros aos leitores de ecrã.
Sabe mais no nosso guia completo sobre formulários, ou vê o que está incluído em cada plano WEMASY.