Formulários são o ponto em que o seu site para de falar e começa a ouvir: pedidos de contato, compras, cadastros, buscas. Também são o ponto em que a acessibilidade falha com mais frequência. O estudo WebAIM Million, que analisa todo ano a página inicial de um milhão de sites, encontra de forma consistente rótulos de campo ausentes em quase metade deles, o que faz disso uma das falhas de acessibilidade mais comuns da web. A parte frustrante: formulários acessíveis não são difíceis. Um punhado de atributos HTML, usados corretamente, decide se uma pessoa cega consegue lhe enviar uma mensagem ou desiste em silêncio, e se o seu formulário atende à WCAG, que o European Accessibility Act transformou em exigência legal para muitas empresas. Este guia percorre as cinco coisas que importam, com marcação para copiar e colar, e termina com um olhar honesto sobre os plugins de formulário para WordPress.
Por que os formulários são o maior problema de acessibilidade?
Uma pessoa que enxerga e usa o mouse lê o formulário como um todo visual: o texto ao lado de uma caixa obviamente pertence a ela, a borda vermelha obviamente significa erro. A tecnologia assistiva não tem nada desse contexto. Quem usa leitor de tela vai de controle em controle com o teclado e ouve apenas o que a marcação conecta explicitamente a cada campo. Se a conexão não existe, a pessoa ouve caixa de edição, vazio, e precisa adivinhar o que o campo quer. Quem usa controle por voz enfrenta um problema paralelo: dizer clicar em e-mail só funciona se o campo estiver programaticamente nomeado como e-mail.
Esse é o princípio central por trás de toda regra deste guia: toda relação visual em um formulário também precisa existir na marcação. Rótulo com campo, dica com campo, erro com campo, grupo com opções. Os critérios de sucesso relevantes da WCAG (1.3.1 Info and Relationships, 3.3.1 Error Identification, 3.3.2 Labels or Instructions) se reduzem todos a essa mesma ideia.
Como rotular campos de formulário corretamente
A base de todo formulário acessível é o elemento label, conectado ao seu campo pelo atributo for, que aponta para o id do campo:
<label for="email">Endereço de e-mail</label>
<input type="email" id="email" name="email" autocomplete="email">
<!-- Dica adicional, conectada via aria-describedby -->
<label for="password">Senha</label>
<input type="password" id="password" name="password" aria-describedby="password-hint">
<p id="password-hint">Pelo menos doze caracteres.</p>Isso lhe rende três coisas de uma vez: leitores de tela anunciam o rótulo quando o campo recebe foco, clicar no rótulo foca o campo (uma área de toque maior no celular, o que beneficia todo mundo) e o controle por voz consegue endereçar o campo pelo nome. Dicas e instruções de formato vão para um elemento separado referenciado por aria-describedby, para que sejam anunciadas depois do rótulo sem poluí-lo. O atributo autocomplete é um bônus discreto: para campos que coletam dados pessoais, a WCAG 1.3.5 o exige, e ele permite que os navegadores preencham o campo corretamente, o que ajuda principalmente pessoas com limitações motoras e cognitivas. O tutorial de formulários do W3C cobre todas as variações desses padrões.
Por que um placeholder não é um rótulo
O campo de formulário apenas com placeholder é o erro de aparência acessível mais comum da web. Parece limpo, e falha de quatro maneiras ao mesmo tempo:
- O texto some quando se digita. A descrição desaparece exatamente quando a pessoa está trabalhando no campo. Quem já esqueceu o que um campo pela metade estava pedindo sabe bem como é.
- O cinza padrão reprova no contraste. O estilo típico de placeholder não alcança a taxa de contraste de 4,5:1 que a WCAG exige para texto.
- O suporte nas tecnologias assistivas é inconsistente. Algumas combinações de leitor de tela e navegador anunciam placeholders, outras não. Um rótulo é anunciado por todas elas.
- Campos preenchidos parecem vazios, campos vazios parecem preenchidos. Quem passa os olhos para ver o que falta completar entende tudo ao contrário.
Placeholders são bem-vindos como complemento, por exemplo um exemplo de formato como nome@example.com dentro de um campo devidamente rotulado. Como única descrição de um campo, são uma falha de WCAG 3.3.2 com boa tipografia.
Como marcar campos obrigatórios de forma acessível
Dois canais, sempre juntos. O canal da máquina é o atributo HTML required, que faz navegadores e leitores de tela anunciarem o campo como obrigatório e habilita a validação nativa. O canal humano é o texto visível: a palavra obrigatório (ou o oposto, opcional) no rótulo. O popular asterisco vermelho sozinho falha nos dois quesitos: a cor sozinha não pode carregar informação (WCAG 1.4.1) e a convenção do asterisco, se você usá-la mesmo assim, precisa no mínimo ser explicada acima do formulário e incluída no rótulo para que seja anunciada.
<label for="name">Nome (obrigatório)</label>
<input type="text" id="name" name="name" required>Uma inversão pragmática costuma produzir os formulários mais limpos: se quase todo campo é obrigatório, marque apenas os opcionais e diga isso acima do formulário. E o melhor campo obrigatório é aquele que você apaga; todo campo que um formulário não pede é um campo que não pode ser preenchido errado.
Como tornar as mensagens de erro acessíveis
O tratamento de erros é onde os formulários perdem os usuários que ainda não perderam. A WCAG 3.3.1 exige que os erros sejam identificados em texto e descritos para o usuário. O padrão robusto por campo:
<label for="email">Endereço de e-mail (obrigatório)</label>
<input type="email" id="email" name="email" required
aria-invalid="true" aria-describedby="email-error">
<p id="email-error" class="error">
Informe um endereço de e-mail, por exemplo nome@example.com.
</p>As peças: aria-invalid="true" marca o campo como incorreto para que leitores de tela anunciem entrada inválida ao receber foco, a mensagem é texto de verdade (não só uma borda vermelha, não só um ícone) e está amarrada ao campo com aria-describedby, e a redação diz como resolver o problema, não apenas que existe um. Erro, corrija não ajuda ninguém; Informe uma data no formato DD/MM/AAAA ajuda.
Para a validação que roda no envio, mais um passo importa: depois de um envio malsucedido, mova o foco do teclado para o primeiro campo com erro, ou renderize um resumo de erros no topo com role="alert" e links para os campos afetados. Quem usa leitor de tela, envia o formulário e não ouve nada presume que deu certo. Silêncio depois de um envio que falhou é o bug de formulário mais cruel que existe.
Fieldset e legend: agrupando botões de rádio e caixas de seleção
Grupos de botões de rádio e de caixas de seleção têm uma estrutura de dois níveis: o grupo tem uma pergunta, cada opção tem um rótulo. Os dois níveis precisam estar na marcação, e os elementos nativos para o nível do grupo são fieldset e legend:
<fieldset>
<legend>Forma de contato preferida (obrigatório)</legend>
<input type="radio" id="contact-email" name="contact" value="email">
<label for="contact-email">E-mail</label>
<input type="radio" id="contact-phone" name="contact" value="phone">
<label for="contact-phone">Telefone</label>
</fieldset>Sem o fieldset, quem usa leitor de tela e entra no grupo com o teclado ouve apenas E-mail, botão de rádio, um de dois, e não faz ideia de qual pergunta as opções respondem. Com ele, a legend é anunciada primeiro. A mesma estrutura serve para grupos de caixas de seleção e vale a pena mantê-la mesmo quando um design system reestiliza os elementos além do reconhecível; a semântica não custa nada e carrega tudo.
Os plugins de formulário para WordPress são acessíveis?
Em geral podem ser, e nenhum deles garante isso. O retrato honesto plugin a plugin: o Contact Form 7 renderiza o que você escreve no template do formulário, então rótulos, fieldsets e a ligação dos erros estão inteiramente nas suas mãos; a flexibilidade que o tornou popular também facilita colocar no ar formulários sem rótulo. O Gravity Forms refez a marcação com acessibilidade como objetivo explícito alguns anos atrás e produz saída sólida nas versões atuais. O WPForms também investiu em padrões acessíveis. Em todos os casos, três coisas ainda podem estragar um plugin acessível: o estilo do seu tema (contornos de foco removidos, contraste destruído), CAPTCHAs (uma barreira totalmente inacessível; abordagens de honeypot evitam o problema) e tipos de campo personalizados adicionados por cima.
Então teste o resultado renderizado, não a página de marketing. A versão de dois minutos: desconecte o mouse e complete o formulário só com o teclado, conferindo se você consegue ver o foco em cada etapa; depois envie-o vazio e verifique se as mensagens de erro são anunciadas e alcançáveis. Verificadores automáticos como o WAVE pegam a metade estrutural, incluindo rótulos ausentes, em segundos.
Como o InspectWP ajuda a encontrar problemas nos formulários
O relatório do InspectWP examina o seu site WordPress renderizado do jeito que um navegador o vê, e várias verificações dizem respeito diretamente aos formulários. Ele sinaliza formulários cujo action envia para um endereço HTTP inseguro, um problema que os navegadores punem com avisos exatamente no momento em que o visitante está prestes a confiar dados a você. Além disso, o relatório cobre os fundamentos de acessibilidade em torno dos seus formulários: imagens sem atributo alt, a hierarquia de títulos pela qual quem usa leitor de tela navega e erros de console que muitas vezes revelam scripts de validação quebrados. Um relatório gratuito é uma primeira passada rápida pela página em que o seu formulário vive.