WCAG 3.3.2: Rótulos ou Instruções

O que Esta Regra Significa

O Critério de Sucesso 3.3.2 das WCAG — Rótulos ou Instruções (Nível A) afirma: "Rótulos ou instruções são fornecidos quando o conteúdo requer entrada do usuário." Em termos práticos, todo campo de formulário, controle de entrada, área de texto e elemento select que pede ao usuário para inserir ou selecionar informações deve ter um rótulo visível e significativo ou um conjunto de instruções que torne o propósito do campo claro antes de o usuário interagir com ele.

O critério é deliberadamente amplo em escopo. Ele abrange qualquer mecanismo por meio do qual um usuário fornece dados: elementos <input> de todos os tipos (text, email, password, number, date, checkbox, radio, file upload), elementos <textarea> para texto em várias linhas e dropdowns <select>. Também se aplica a controles interativos personalizados construídos com papéis ARIA, como role='combobox' ou role='listbox'.

Um rótulo pode ser fornecido de várias maneiras que satisfazem este critério. A mais robusta é um elemento <label> associado programaticamente, que está visualmente presente e vinculado ao controle por meio de um par correspondente for/id. Alternativamente, um texto de rótulo visível pode ser associado usando aria-labelledby apontando para um elemento existente, ou instruções suplementares podem ser conectadas com aria-describedby. O requisito principal é que o rótulo ou instrução seja fornecido — ele deve existir em alguma forma que o usuário possa perceber. O texto de placeholder sozinho não satisfaz este critério porque desaparece assim que o usuário começa a digitar e não é transmitido de forma confiável por todas as tecnologias assistivas como um rótulo persistente.

Uma aprovação exige que cada entrada tenha um rótulo que seja visível (ou no mínimo determinável programaticamente), presente antes de o usuário se comprometer a preencher o campo e descritivo o suficiente para transmitir quais dados são esperados. Uma falha ocorre quando um campo não tem rótulo algum, quando o único rótulo é um atributo placeholder, quando o rótulo está visualmente presente mas não está associado programaticamente ou quando instruções sobre o formato exigido (por exemplo, "Insira a data como DD/MM/AAAA") estão totalmente ausentes.

As WCAG observam uma exceção estreita: quando um formulário contém um único campo óbvio — como uma barra de pesquisa em todo o site com um botão de envio claramente rotulado diretamente ao lado — o próprio contexto pode fornecer instrução suficiente. No entanto, essa exceção é limitada e não deve ser usada como justificativa geral para omitir rótulos em formulários com vários campos.

Por Que Isso Importa

Rótulos de formulário são o recurso de acessibilidade de maior impacto para um amplo espectro de usuários. Sua ausência cria barreiras que podem tornar impossível para muitas pessoas concluir transações, registrar-se para serviços ou contatar uma organização.

Para usuários cegos e com baixa visão que dependem de leitores de tela, um campo sem rótulo é anunciado simplesmente como "edit text" ou "blank", sem contexto. O usuário não tem como saber se deve inserir seu nome, seu endereço de email ou seu número de cartão de crédito. De acordo com a Organização Mundial da Saúde, aproximadamente 2,2 bilhões de pessoas no mundo têm algum tipo de deficiência visual, e milhões delas usam leitores de tela como seu principal meio de interação com a web.

Para usuários com deficiências cognitivas e de aprendizagem — incluindo dislexia, TDAH e condições relacionadas à memória — o texto de placeholder é especialmente prejudicial. Como os placeholders desaparecem ao receber foco ou entrada, um usuário que faz uma pausa no meio do formulário não tem referência sobre o que era esperado em um campo que já começou a preencher. Isso o obriga a limpar o campo para reler a instrução, introduzindo confusão e frustração. Rótulos visíveis e persistentes eliminam completamente essa carga cognitiva.

Para usuários com deficiência motora que navegam por teclado, dispositivo de varredura ou controle por voz, os rótulos desempenham uma função adicional: eles fornecem as palavras faladas usadas para ativar um campo por meio de softwares de controle por voz, como o Dragon NaturallySpeaking. Se o texto do rótulo visível não corresponder ao nome acessível programático, o comando de voz falha silenciosamente.

Considere um cenário concreto do mundo real: uma pessoa com baixa visão está se candidatando a um benefício governamental no portal de uma instituição pública turca. O formulário usa texto de placeholder em vez de rótulos. À medida que o usuário amplia para 200% para ler a tela, os placeholders desaparecem antes que possam ser lidos. O usuário preenche os campos por tentativa e erro e envia um formulário com erros, apenas para receber uma mensagem de erro genérica sem indicação de quais campos estão incorretos. Esse cenário resulta em exclusão de um serviço público crítico — e é totalmente evitável.

Além da acessibilidade, formulários rotulados melhoram o SEO porque rastreadores de mecanismos de busca podem entender melhor o propósito do formulário, e melhoram a usabilidade para todos os usuários, incluindo aqueles em dispositivos móveis, onde pequenos alvos de toque se beneficiam de áreas de rótulo tocáveis que expandem a zona de ativação da entrada associada.

Regras Relacionadas do Axe-core

• label — Esta regra verifica se todo elemento <input> (exceto aqueles com type='hidden', type='image', type='button', type='submit' e type='reset'), todo <textarea> e todo <select> tem um nome acessível. A regra sinaliza elementos que não têm um <label> associado, um atributo aria-label, uma referência aria-labelledby ou um atributo title. Este é o principal sinal automatizado para violações do 3.3.2 em controles de formulário padrão.
• select-name — Esta regra tem como alvo específico elementos dropdown <select> e verifica se eles têm um nome acessível não vazio. Desenvolvedores às vezes presumem que as opções de um dropdown tornam seu propósito autoevidente, mas sem um rótulo, usuários de leitores de tela ouvem apenas o valor da opção atualmente selecionada — que pode ser um padrão genérico como "Select one" — sem indicação de qual categoria estão escolhendo. O Axe sinaliza elementos <select> que não possuem nenhum dos mecanismos de rotulagem padrão.
• textarea-label — Esta regra verifica elementos <textarea> em busca de um nome acessível. Áreas de texto de várias linhas são frequentemente usadas para comentários, mensagens ou entradas detalhadas, mas muitas vezes ficam sem rótulo sob a suposição equivocada de que o contexto ao redor é suficiente. O Axe sinaliza qualquer <textarea> que não possa ser associado programaticamente a um rótulo por meio de <label for>, aria-label, aria-labelledby ou title.

É importante entender os limites dos testes automatizados para este critério. O axe-core pode detectar a ausência de um rótulo programático, mas não pode determinar se um rótulo presente é realmente significativo ou preciso. Um campo rotulado como "Field 1" ou um rótulo que simplesmente exibe "*" passará nas verificações automatizadas enquanto falha completamente para os usuários. A revisão manual é sempre necessária para confirmar que os rótulos descrevem claramente a entrada esperada, que instruções de formato estão presentes quando necessário (por exemplo, formatos de data, requisitos de senha) e que campos obrigatórios são identificados — idealmente tanto visual quanto programaticamente.

Como Testar

1. Varredura automatizada com axe DevTools ou Lighthouse: Abra a página que contém o formulário no Chrome ou Firefox. Execute a extensão de navegador axe DevTools e filtre os resultados pelas regras label, select-name e textarea-label. Anote cada elemento sinalizado. Execute o Google Lighthouse (auditoria de Acessibilidade) como verificação secundária. Exporte ou faça capturas de tela de todas as violações. Lembre-se de que um relatório automatizado limpo não garante conformidade — prossiga com as etapas manuais.
2. Inspeção visual: Sem usar qualquer tecnologia assistiva, revise cada campo de formulário na página. Confirme que cada campo tem um rótulo visível e estático — não apenas um placeholder — posicionado claramente próximo ao campo (tipicamente acima ou à esquerda). Confirme que requisitos de formato (por exemplo, "A senha deve ter pelo menos 8 caracteres") são exibidos antes ou no momento da entrada, não apenas após um envio com falha. Confirme que campos obrigatórios são identificados por mais do que apenas cor.
3. Teste de navegação por teclado: Use a tecla Tab para percorrer cada campo do formulário. Certifique-se de que, à medida que cada campo recebe foco, seu propósito fique imediatamente claro a partir do rótulo visível. Nenhum campo deve ser alcançável por teclado sem que um rótulo adjacente e persistente esteja visível naquele momento.
4. Teste com leitor de tela usando NVDA e Firefox: Abra o formulário com o NVDA em execução. Pressione Tab para mover-se por cada controle interativo. O NVDA deve anunciar o rótulo, o papel (por exemplo, "edit", "combo box") e qualquer estado (por exemplo, "required"). Se o NVDA anunciar apenas o papel e o estado, sem rótulo, o campo falha. Use o modo de formulário do NVDA (acionado automaticamente em elementos interativos) para simular uma navegação realista do usuário.
5. Teste com leitor de tela usando VoiceOver e Safari (macOS/iOS): Ative o VoiceOver (Command + F5 no Mac). Use Tab ou gestos de deslizar para navegar até cada campo do formulário. O VoiceOver deve anunciar o rótulo antes do papel. No iOS, toque em cada campo e confirme que o rótulo é lido em voz alta antes de o teclado aparecer. Campos com apenas placeholder normalmente serão lidos como o placeholder no primeiro foco, mas ficarão silenciosos assim que o texto for inserido.
6. Teste com leitor de tela usando JAWS e Chrome: Abra o JAWS e navegue pelo formulário usando Tab. Use o Forms Mode do JAWS. Confirme que o nome anunciado de cada campo corresponde exatamente ao seu rótulo visível. Use Insert + F1 (ajuda de campo) do JAWS para verificar descrições adicionais via aria-describedby.
7. Teste de controle por voz com Dragon NaturallySpeaking: Ative o Dragon e tente interagir com cada campo falando seu rótulo visível. Se o rótulo falado não corresponder ao nome acessível programático, o campo não responderá ao comando de voz, indicando uma incompatibilidade que falha tanto no 3.3.2 quanto em critérios relacionados.

Como Corrigir

Rótulo ausente em uma entrada de texto — Incorreto

<!-- No label provided; placeholder is the only hint -->
<input type='text' name='email' placeholder='Email address' />

Rótulo ausente em uma entrada de texto — Correto

<!-- Visible <label> associated via matching for/id attributes.
     Placeholder may still be used as supplementary hint,
     but the label is the primary, persistent identifier. -->
<label for='email'>Email address</label>
<input type='text' id='email' name='email' placeholder='[email protected]' />

Dropdown select sem rótulo — Incorreto

<!-- No label; screen readers will only announce the selected option value -->
<select name='city'>
  <option value=''>Select a city</option>
  <option value='istanbul'>Istanbul</option>
  <option value='ankara'>Ankara</option>
</select>

Dropdown select sem rótulo — Correto

<!-- Programmatically associated label makes the field's purpose clear
     before the user opens the dropdown. -->
<label for='city'>City</label>
<select id='city' name='city'>
  <option value=''>Select a city</option>
  <option value='istanbul'>Istanbul</option>
  <option value='ankara'>Ankara</option>
</select>

Textarea sem rótulo — Incorreto

<!-- The textarea has no label; surrounding paragraph text is not
     programmatically associated and will not be read by screen readers
     as the field's label. -->
<p>Please describe your issue:</p>
<textarea name='message' rows='5'></textarea>

Textarea sem rótulo — Correto

<!-- Using aria-labelledby to associate the existing visible heading
     with the textarea, or alternatively wrapping with a <label> element. -->
<label for='message'>Please describe your issue</label>
<textarea id='message' name='message' rows='5'></textarea>

Instruções de formato ausentes para um campo de data — Incorreto

<!-- Label present but no instruction about expected date format;
     users must guess whether to enter 01/06/2025 or 2025-06-01. -->
<label for='dob'>Date of birth</label>
<input type='text' id='dob' name='dob' />

Instruções de formato presentes para um campo de data — Correto

<!-- Format instruction is visible and linked via aria-describedby
     so screen readers announce it when the field receives focus. -->
<label for='dob'>Date of birth</label>
<span id='dob-hint'>Enter as DD/MM/YYYY, e.g. 15/06/1990</span>
<input type='text' id='dob' name='dob' aria-describedby='dob-hint' />

Erros Comuns

• Usar placeholder como único rótulo: O texto de placeholder desaparece na entrada, não é anunciado de forma confiável como rótulo por todos os leitores de tela e falha com usuários com deficiências cognitivas que precisam de texto de referência persistente. Sempre forneça um <label> visível além de qualquer placeholder.
• Posicionar visualmente um rótulo próximo a um campo sem associação programática: Um <p> ou <span> colocado visualmente acima de uma entrada parece um rótulo para usuários videntes, mas é ignorado por leitores de tela. Use <label for='id'>, aria-labelledby ou envolva a entrada dentro de um elemento <label>.
• Usar aria-label com texto que não corresponde ao rótulo visível: Quando o nome acessível programático difere do texto visível, usuários de controle por voz não conseguem ativar o campo falando o que leem na tela, violando o SC 2.5.3 (Label in Name), além de criar confusão para usuários de leitores de tela.
• Rotular um grupo de botões de opção, mas omitir a legenda do grupo: Botões de opção individuais podem ser rotulados com seu texto de opção, mas se a pergunta abrangente (por exemplo, "Payment method") não for fornecida por meio de um <fieldset> e <legend>, usuários que navegam por teclado ouvem cada opção isoladamente, sem entender entre o que estão escolhendo.
• Identificar campos obrigatórios apenas por cor ou asterisco, sem explicação: Um asterisco (*) ao lado de um rótulo não transmite nada a usuários de leitores de tela, a menos que seu significado seja explicado (por exemplo, uma nota no topo do formulário afirmando "Campos marcados com * são obrigatórios") e que campos obrigatórios também tenham o atributo required ou aria-required='true'.
• Omitir instruções de formato até depois de um envio com falha: Exibir regras de senha ou requisitos de formato de data apenas em mensagens de erro pós-envio força os usuários a cometer um erro antes de poderem aprender o que é esperado. As instruções devem estar presentes antes ou no momento em que o usuário interage com o campo.
• Ocultar rótulos usando display:none ou visibility:hidden: Essas propriedades CSS removem os rótulos inteiramente da árvore de acessibilidade. Se um rótulo precisar ser visualmente oculto (por exemplo, para um design minimalista), use uma classe CSS de "visualmente oculto" que mantenha o elemento na árvore de acessibilidade enquanto o move para fora da tela.
• Usar o atributo title como único rótulo e presumir que é suficiente: Embora o axe-core possa não sinalizar um rótulo apenas em title, o atributo title aparece apenas como um tooltip ao passar o mouse e é inacessível a usuários que usam apenas teclado e a usuários móveis. Ele deve ser usado como descrição suplementar, não como rótulo principal.
• Aplicar um único aria-label a um <div> contêiner e esperar que ele rotule entradas filhas: Rótulos ARIA em elementos contêiner não são herdados por seus controles de formulário filhos. Cada controle interativo deve ser rotulado individualmente.
• Deixar de reassociar rótulos após atualizações dinâmicas de conteúdo: Quando campos de formulário são inseridos dinamicamente via JavaScript (por exemplo, adicionando uma linha de endereço), entradas recém-inseridas frequentemente não têm rótulos associados porque o desenvolvedor apenas adicionou o texto de rótulo visível como um elemento irmão, sem a vinculação adequada for/id.

Relação com os Regulamentos de Acessibilidade da Turquia

O Decreto Presidencial 2025/10 da Turquia, publicado no Diário Oficial nº 32933 em 21 de junho de 2025, estabelece requisitos obrigatórios de acessibilidade na web alinhados com as WCAG 2.2. O Critério de Sucesso 3.3.2 das WCAG — Rótulos ou Instruções — é um requisito de Nível A, o que significa que está na base da conformidade e está entre as disposições mais rigorosamente aplicadas pelo decreto.

O decreto abrange uma ampla gama de tipos de entidades, e os prazos de conformidade diferem por setor. Instituições públicas — incluindo ministérios, municípios, agências estatais e organizações financiadas com recursos públicos — devem alcançar conformidade total de Nível A dentro de um ano a partir da publicação do decreto. Entidades do setor privado dentro do escopo devem cumprir em até dois anos. As entidades do setor privado explicitamente abrangidas incluem plataformas de e-commerce, bancos e instituições financeiras, hospitais e prestadores de serviços de saúde privados, empresas de telecomunicações com 200.000 ou mais assinantes, agências de viagem, empresas de transporte privado e escolas privadas autorizadas pelo Ministério da Educação Nacional (MoNE).

Para todas essas entidades, a falha em rotular campos de formulário não é apenas uma deficiência de usabilidade — constitui uma não conformidade regulatória direta. Formulários são onipresentes em todos os serviços digitais abrangidos: cidadãos enviam solicitações em portais governamentais, pacientes marcam consultas em sites de hospitais, clientes concluem compras em plataformas de e-commerce e estudantes se matriculam por meio de portais escolares. Cada uma dessas jornadas depende de formulários, e cada campo sem rótulo nesses formulários é uma violação demonstrável do WCAG 3.3.2 que auditores podem documentar e relatar.

Organizações sujeitas ao decreto devem tratar a conformidade com o SC 3.3.2 como pré-requisito para qualquer processo de auditoria ou certificação de acessibilidade. Como este é um critério de Nível A, ele não pode ser dispensado ou adiado — declarações de conformidade parcial que excluem itens de Nível A não são reconhecidas. Entidades que não conseguem demonstrar entradas rotuladas em todos os seus formulários voltados ao público correm o risco de constatações regulatórias, divulgação pública de não conformidade e danos à reputação em um mercado em que a confiança digital está cada vez mais ligada ao design inclusivo.

Do ponto de vista prático, alcançar a conformidade com o 3.3.2 está entre as etapas de menor esforço e maior impacto que uma organização pode tomar. Associar rótulos a controles de formulário existentes normalmente exige apenas pequenas alterações em HTML e não afeta o design visual quando implementado corretamente. Para organizações que usam o SDK de overlay da Accsible, a detecção automatizada de rótulos ausentes pode evidenciar essas violações durante varreduras de rotina, fornecendo às equipes de desenvolvimento orientações de correção acionáveis antes que os prazos regulatórios cheguem.