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!
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 aoid
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á!
Top comments (0)