Uma das minhas dificuldades como iniciante era estruturar um formulário funcional.

O que um formulário precisa ter?

Nesse artigo vou mostrar o básico pra se montar um formulário completo apenas com funcionalidades nativas.

Antes de começar, o melhor conteúdo pra iniciantes sobre formulários que já encontrei é o guia do MDN. A maioria das páginas já está disponível em português!

Formulários da Web - Trabalhando com dados do usuário - Aprendendo desenvolvimento web | MDN

Este guia tem uma série de artigos que vão ajudar você a ficar craque em HTML forms. HTML forms são ferramentas poderosas para interagir com usuários; contudo, por razões técnicas e históricas, nem sempre é óbvio como usá-los em seu pleno potencial. Neste guia, vamos cobrir todos os aspectos dos HTML forms, da estrutura ao estilo, do manuseio de dados à widgets personalizados. Você vai aprender a desfrutar do grande poder que elas lhes oferecem!

developer.mozilla.org

O que um formulário precisa ?

• Ser capaz de enviar suas informações apenas com o teclado via Enter ou clicando no botão de enviar
• Ser operável apenas pelo teclado, se necessário
• Todos os campos que recebem ou enviam informação precisam ter uma label identificando que tipo de informação ele recebe
• As labels precisam ter seu atributo for associado ao id do seu input
• placeholder apenas quando mais contexto visual complementar é necessário. Se esse contexto for crucial para o uso, ele deve estar em um elemento de texto associado ao formulário

Pra encapsular os campos de input e label, podemos utilizar qualquer elemento de bloco, como <p> ou <div> e até a própria label. Elementos inline como <span> só podem ser utilizados se receberem apenas elementos do tipo inline.

💡 Não sabe identificar o que são elementos inline? Nesse artigo do MDN (em inglês) tem a explicação e uma lista completa desses elementos.

O atributo for associado à um input faz com que ao acessar o campo leitores de tela anunciem o texto da label, mas também possibilitam que o campo ganhe foco ao clicar na área da label.

Esse último é muito importante pra campos do tipo radio ou checkbox pois todos os elementos interativos precisam ter no mínimo 44px de altura e largura de área clicável pra serem acessíveis. Uma pessoa com baixa visão ou baixa destreza terá dificuldade de operar controles menores, ter a label clicável acrescenta nessa área.

Se quiser saber mais dos a respeito dos tamanhos indicados pras superfícies clicáveis (botões, inputs, links), recomendo a explicação do critério de sucesso de acessibilidade 2.5.5 da WCAG.

Propriedades de restrição dos formulários

Caso o formulário possua algum requisito ou restrição, isso deve ser comunicado, é um anti-padrão e um problema de acessibilidade comunicar a um usuário o que fazer apenas pelo erro.
No caso abaixo, usamos aria-describledby pra associar a descrição de um campo a ele.

Além de desabilitados, inputs podem receber o atributo redonly que os define como "somente leitura" isso faz com que eles estejam desabilitados pra edição mas seu atributo value ainda seja lido.

O required define campos obrigatórios, mas é interessante que esse estado seja demonstrado não só no estilo do formulário, mas como na label. Demonstrar apenas por intermédio da cor pode ser inacessível pra pessoas que tem deficiências visuais como daltonismo, e apenas por meio de um erro (ex: Campo x é obrigatório) é uma experiência de uso frustrante.

Agrupamento de campos com Fieldset

Podemos agrupar os campos de formulário que estão dentro do mesmo contexto com <fieldset>, usando o elemento <legend> pra definir um título pra esse grupo. O uso do fieldset não elimina a necessidade de um label.

Uma das vantagens desse elemento é que ao aplicar disabled a ele, todos os elementos filhos também são desabilitados, facilitando a desativação de vários campos dentro do mesmo contexto.

Essa é apenas a camada mais superficial de um formulário, mas estritamente necessária. Além desses tópicos temos validação e eventos que pertencem à API nativa de formulário, além da estilização dos campos utilizando pseudo-classes específicas de formulário, como :readonly.

Esqueci de alguma coisa? (pode ser que sim, então comenta ai!)

Próximos artigos da série vou falar sobre:

• Envio de formulário e o objeto FormData
• API de validação nativa com Constraint Validation API
• Estilização de formulários com CSS

Vejo vocês lá!