Formulários inclusivos: perguntar sem excluir

Há um padrão que se repete em quase todos os formulários do mundo: pergunta-se demasiado. Pergunta-se obrigatoriamente. Pergunta-se com opções binárias quando a realidade é contínua. E o resultado é que pessoas que não cabem no formulário sentem-se mal antes mesmo de chegar à página seguinte.

A maior parte deste mal pode ser resolvido por design, sem mexer no produto. Este post lista os princípios e padrões que uso para construir formulários mais inclusivos.

A primeira regra: a pergunta é mesmo necessária?

Antes de adicionar qualquer campo, faz a pergunta:

Esta informação é necessária para entregar o serviço, ou é só “bom ter”?

Se a resposta é “bom ter”, fora. Se é “necessária”, então passa para o resto deste post. Mas a maioria dos campos que excluem (género, idade exata, estado civil, nacionalidade) são “bom ter”, e quase nunca são realmente necessários.

A excepção: contextos legais ou clínicos onde a informação é mesmo crítica. Aí muda a régua, mas o pensamento por trás é o mesmo: justifica antes de pedir.

Transparência: porquê estás a perguntar?

Quando perguntas algo sensível, explica:

“Pedimos a tua data de nascimento para verificarmos a idade legal de uso.”

Não tem de ser um parágrafo. Uma linha curta sob o campo, ou um tooltip. Mas tem de existir. A diferença entre “Data de nascimento *” e “Data de nascimento (necessária para verificação de idade legal)” é gigantesca em termos de confiança.

A regra: se o utilizador não percebe porque é que está a dar a informação, vai sair, ou vai dar informação incorreta.

Tornar opcional sempre que puderes

A maior parte dos formulários marca demasiados campos como obrigatórios. Cada asterisco vermelho é um ponto de fricção potencial.

Pergunta-te: este campo, se vier vazio, partiste o sistema? Se não, deveria ser opcional. Email para confirmação, sim obrigatório. Cargo profissional, opcional. Tamanho da empresa, opcional.

Tornar opcional não é desistir da informação. É confiar que quem quiser dar, dá.

”Prefiro não dizer” como opção

Para perguntas sensíveis (género, etnia, orientação, religião, status de imigração), oferecer “prefiro não dizer” não é um nice-to-have. É um requisito de design inclusivo.

A pessoa que prefere não responder não deveria ter de mentir, deixar em branco e correr risco de validação, ou abandonar.

Em práctica:

• Em select dropdowns, “Prefiro não dizer” como opção.
• Em radio buttons, idem.
• Em obrigatórios sensíveis, oferecer um botão “Saltar este campo”.

Self-describe: o input livre que muda tudo

Para género, identidade, etnia, ocupação, orientação, há sempre quem não cabe nas opções pré-definidas. A solução clássica de “Outro” é fraca: o que faço se sou “outro”?

A solução melhor é dar input livre:

Género (opcional):
( ) Mulher
( ) Homem
( ) Não-binário
( ) Outro: _______________
( ) Prefiro não dizer

O campo livre permite à pessoa descrever-se nos seus próprios termos. Se precisas de agregar dados, podes categorizar internamente, mas a pessoa sente-se vista.

O caso especial do nome

Os nomes são surpreendentemente complicados. Há formulários que rejeitam:

• Nomes com apóstrofes (O’Connor)
• Nomes com hífens (Sá-Pinto)
• Nomes muito curtos ou muito longos
• Nomes não-latinos
• Nomes com um único componente (em algumas culturas)
• Nomes com mais de dois componentes (em culturas hispânicas e árabes)

A regra mais segura: um único campo de nome livre. Não “primeiro nome” + “último nome”. Apenas “Nome”. E aceitar caracteres Unicode, qualquer comprimento razoável (entre 1 e 100), com qualquer pontuação.

O género: o caso mais delicado

Se mesmo precisas de perguntar género (e na maior parte dos contextos, não precisas), o padrão recomendado é:

Género (opcional):
( ) Mulher
( ) Homem  
( ) Não-binário
( ) Prefiro descrever: _______________
( ) Prefiro não dizer

E a ordem pode mudar, sem hierarquia implícita. Algumas equipas alfabetizam, outras randomizam, outras começam por “prefiro não dizer” para sinalizar que é opção válida desde o início.

Mensagens de erro

Quando algo dá errado num formulário, a mensagem importa.

Errado: “Erro: dados inválidos.” Melhor: “O email parece não estar correto. Verifica se incluíste @.” Ainda melhor: marcar visualmente o campo, manter o resto do formulário preenchido, dar foco ao campo errado.

E nunca, mas nunca, apagar tudo o que a pessoa já preencheu por causa de um campo errado.

Checklist final

Antes de mandar um formulário para produção, verifica:

1. Cada pergunta é necessária para a tarefa?
2. Os campos sensíveis têm explicação do porquê?
3. Há “prefiro não dizer” onde aplicável?
4. Há self-describe onde categorias se ficam aquém?
5. O campo de nome aceita variações reais?
6. Mensagens de erro são úteis e o estado do formulário preserva-se?
7. O formulário funciona sem rato (teclado)?
8. O leitor de ecrã consegue navegar com sentido?

Mais sobre os princípios por trás disto no guia Inclusão e Diversidade. Sobre linguagem inclusiva nas labels e mensagens, ver Linguagem inclusiva no design. Sobre acessibilidade técnica em formulários (labels, ARIA, leitor de ecrã), ver Acessibilidade para além do contraste.