WCAG 2.4.6: Títulos e Rótulos

O que Esta Regra Significa

WCAG 2.4.6 afirma: "Headings and labels describe topic or purpose." Em essência, este critério exige que qualquer heading (<h1> até <h6>) ou label (<label>, aria-label, aria-labelledby) que apareça em uma página seja descritivo o suficiente para comunicar o assunto do conteúdo que introduz ou o propósito do controle que identifica.

Este critério não exige que headings ou labels estejam presentes — essa obrigação é coberta por outros critérios de sucesso, como 1.3.1 (Info and Relationships) e 2.4.2 (Page Titled). O que 2.4.6 rege é a qualidade dos headings e labels que já existem: quando você os tem, eles precisam ser significativos. Um heading que diz "Section 1" ou um label que diz "Field" não diz nada de útil aos usuários sobre o conteúdo que se segue ou sobre a entrada que descreve. Compare isso com "Your Shipping Address" ou "Monthly Budget Summary", que orientam os usuários imediatamente.

Labels neste contexto incluem não apenas o elemento HTML <label> associado a controles de formulário, mas também qualquer mecanismo de rotulagem programática: aria-label, aria-labelledby, o atributo title quando usado como nome acessível, e o elemento legend para fieldsets. Qualquer um desses que seja exposto a tecnologias assistivas deve descrever claramente o propósito do controle associado.

Ocorre falha quando um heading ou label é tão genérico, ambíguo ou pouco informativo que o usuário não consegue determinar sobre o que é a seção ou o controle sem ler o contexto ao redor. Por exemplo, um formulário com três campos de entrada todos rotulados "Enter here" falha neste critério, assim como uma página que usa headings repetidos como "More Info" para cada subseção. Da mesma forma, um heading que está tecnicamente presente no DOM, mas engana completamente o usuário — como rotular uma seção de formulário de contato com um heading que diz "News and Updates" — também é uma falha.

Há uma exceção oficial importante: WCAG 2.4.6 só se aplica quando headings e labels são usados. Se uma página legitimamente não tiver headings (por exemplo, um documento muito curto com um único tópico) ou um controle de formulário que não tenha label visível ou programático (o que seria capturado pelo 1.3.1), o próprio 2.4.6 não se aplica. O escopo do critério diz respeito estritamente à descritividade, não à presença.

Por Que Isso Importa

Headings e labels descritivos beneficiam um público notavelmente amplo, mas o impacto é mais agudo para pessoas com deficiência que dependem de estrutura para navegar.

Usuários de leitores de tela — principalmente pessoas cegas ou com baixa visão severa — rotineiramente navegam pelas páginas pulando de heading em heading usando teclas de atalho (H no NVDA/JAWS, o Rotor no VoiceOver). Se os headings forem vagos ou enganosos, essa estratégia de navegação deixa de funcionar completamente. Uma pessoa cega que acessa um portal de serviços governamentais que usa "Section A", "Section B" e "Section C" como headings precisa ler cada palavra de cada seção sequencialmente para encontrar o que precisa, eliminando a vantagem de eficiência que os headings deveriam proporcionar. 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, o que torna este um público global substancial.

Pessoas com deficiências cognitivas, incluindo aquelas com transtornos de déficit de atenção, comprometimentos de memória ou dificuldades de aprendizagem, dependem fortemente de labels e headings claros e previsíveis para reduzir a carga cognitiva. Quando um campo de formulário é rotulado apenas como "Name" em uma página que coleta tanto o nome da empresa quanto o nome da pessoa de contato, uma pessoa com deficiência cognitiva pode não conseguir resolver a ambiguidade apenas pelo contexto, levando a erros e frustração.

Usuários com deficiências motoras que dependem de acesso por varredura, software de rastreamento ocular ou controle por voz (como Dragon NaturallySpeaking) se beneficiam de labels descritivos porque podem ativar um campo de formulário específico falando o nome do label. Se vários campos compartilham o mesmo texto de label, o software de controle por voz não consegue desambiguar entre eles, forçando o usuário a etapas adicionais que são fisicamente exaustivas.

Considere um cenário do mundo real: uma pessoa usando um leitor de tela visita uma página de checkout de e-commerce. A página contém três seções de endereço — cobrança, envio e endereço de presente — mas cada seção usa o mesmo heading genérico "Address" e cada conjunto de campos usa os mesmos labels: "Street", "City", "Postal Code". Sem headings e labels exclusivos e descritivos, o usuário de leitor de tela não consegue determinar qual grupo de campos está preenchendo, aumentando drasticamente o risco de erros de pedido e a probabilidade de abandonar a compra completamente.

Além da acessibilidade, headings descritivos fornecem valor substancial de SEO. Mecanismos de busca usam a estrutura de headings como um sinal forte para entender o conteúdo da página e associá-lo a consultas de usuários. Headings significativos ajudam os mecanismos de busca a indexar páginas com mais precisão e podem melhorar as taxas de clique em resultados de busca, onde os headings frequentemente aparecem como texto de pré-visualização. Isso alinha diretamente os incentivos de negócio com os requisitos de acessibilidade.

Regras Relacionadas do Axe-core

WCAG 2.4.6 exige testes manuais porque nenhuma ferramenta automatizada pode determinar de forma confiável se um heading ou label é descritivo. Descritividade é um julgamento semântico e contextual — um heading que diz "Products" pode ser perfeitamente descritivo em uma página e completamente ambíguo em outra. Scanners automatizados podem detectar a presença ou ausência de headings e labels, mas não conseguem avaliar se o texto desses headings e labels é significativo sem interpretação humana.

• Revisão manual do texto dos headings: Axe-core sinalizará headings ausentes ou aninhamento incorreto (por meio de regras como heading-order), mas não pode sinalizar um heading que diz "Click Here" ou "Untitled Section" como uma violação de 2.4.6. Um testador humano deve ler cada heading isoladamente — como um usuário de leitor de tela o encontraria ao navegar por headings — e avaliar se ele comunica o tópico do conteúdo abaixo.
• Revisão manual do texto dos labels de formulário: A regra label do axe-core verifica se cada campo de formulário tem um label associado, mas não avalia se o texto desse label é descritivo. Um elemento label que contém apenas um caractere de placeholder, um caractere de ícone ou uma palavra genérica como "Input" passará nas verificações automatizadas, mas ainda assim falhará em 2.4.6. A revisão manual exige ler cada label e confirmar se ele descreve com precisão o propósito do controle associado.
• Revisão manual dos valores de aria-label e aria-labelledby: Da mesma forma, a família de regras aria-label-is-accessible do axe-core confirma que labels ARIA são sintaticamente válidos e que elementos referenciados existem, mas não avalia se o texto do label é semanticamente significativo ou descritivo do propósito do controle.
• Detecção de labels duplicados: Embora algumas ferramentas possam sinalizar texto de label duplicado em uma página, elas não conseguem determinar se a duplicação é intencional e apropriada (dois campos com o mesmo propósito em linhas diferentes de uma tabela) ou uma falha genuína de descritividade em que vários controles distintos compartilham um label ambíguo. A revisão manual é necessária para fazer essa distinção.

Como Testar

1. Execute primeiro uma varredura automatizada: Use axe DevTools (extensão de navegador) ou Lighthouse no Chrome DevTools para identificar quaisquer problemas estruturais de heading ou label que ferramentas automatizadas possam detectar, como labels ausentes, níveis de heading pulados ou elementos de heading vazios. Embora estes não sejam violações diretas de 2.4.6, indicam áreas a serem examinadas com mais cuidado durante a revisão manual. Anote todos os headings e controles rotulados sinalizados ou identificados no relatório.
2. Extraia a lista de headings: Use uma extensão de navegador como a extensão HeadingsMap (disponível para Firefox e Chrome) ou a ferramenta WAVE para gerar uma lista plana de todos os headings na página, sem o conteúdo ao redor. Leia essa lista como se fosse um índice. Pergunte: um usuário conseguiria entender a estrutura e os principais tópicos desta página apenas pelos headings, sem ler o texto do corpo? Se algum heading for ambíguo ou pouco informativo em isolamento, trata-se de uma falha de 2.4.6.
3. Teste com NVDA e Firefox: Abra a página e pressione H para navegar de heading em heading. Ouça o anúncio de cada heading e avalie se ele descreve o conteúdo que se segue. Em seguida, pressione F para percorrer os campos de formulário e ouça o label anunciado para cada campo. Registre qualquer heading ou label que não descreva claramente seu tópico ou propósito.
4. Teste com VoiceOver e Safari (macOS/iOS): Use o Web Rotor (VO+U) para abrir a lista de Headings e a lista de Form Controls. Navegue por cada lista e avalie a descritividade de cada item independentemente do contexto da página. No iOS, use um gesto de deslizar com três dedos para navegar por headings no Rotor.
5. Teste com JAWS e Chrome: Pressione H para navegar pelos headings e use o Forms Mode (F) para se mover entre os controles de formulário. Use a caixa de diálogo List of Headings do JAWS (Insert+F6) para ver todos os headings em uma lista plana, o que reproduz como um usuário de leitor de tela examinaria a estrutura da página.
6. Avalie labels de formulário em isolamento: Para cada controle de formulário, cubra ou ignore todo o contexto ao redor e leia apenas o label programático (texto visível do label, aria-label ou alvo de aria-labelledby). Confirme se apenas o label é suficiente para entender que informação deve ser inserida ou que ação o controle executa.
7. Verifique texto duplicado em headings ou labels: Pesquise na página por texto de heading repetido (por exemplo, vários headings "Read More" ou várias seções "Learn More"). Se o mesmo texto for usado para headings ou labels que se referem a tópicos ou controles diferentes, isso é uma falha de 2.4.6.

Como Corrigir

Headings Genéricos de Seção — Incorreto

<section>
  <h2>Section 1</h2>
  <p>We offer a range of enterprise software solutions tailored for logistics companies.</p>
</section>
<section>
  <h2>Section 2</h2>
  <p>Our pricing is flexible and based on the number of active users.</p>
</section>

Headings Genéricos de Seção — Correto

<!-- Each heading now describes the actual topic of its section,
     enabling screen reader users to jump directly to what they need -->
<section>
  <h2>Enterprise Logistics Software Solutions</h2>
  <p>We offer a range of enterprise software solutions tailored for logistics companies.</p>
</section>
<section>
  <h2>Flexible User-Based Pricing</h2>
  <p>Our pricing is flexible and based on the number of active users.</p>
</section>

Labels Ambíguos em Formulários — Incorreto

<!-- A checkout form with two address blocks, both using identical labels -->
<fieldset>
  <legend>Address</legend>
  <label for='street1'>Street</label>
  <input type='text' id='street1'>
  <label for='city1'>City</label>
  <input type='text' id='city1'>
</fieldset>
<fieldset>
  <legend>Address</legend>
  <label for='street2'>Street</label>
  <input type='text' id='street2'>
  <label for='city2'>City</label>
  <input type='text' id='city2'>
</fieldset>

Labels Ambíguos em Formulários — Correto

<!-- Legends now distinguish the two fieldsets; labels remain short because
     the legend provides the distinguishing context programmatically -->
<fieldset>
  <legend>Billing Address</legend>
  <label for='billing-street'>Street</label>
  <input type='text' id='billing-street'>
  <label for='billing-city'>City</label>
  <input type='text' id='billing-city'>
</fieldset>
<fieldset>
  <legend>Shipping Address</legend>
  <label for='shipping-street'>Street</label>
  <input type='text' id='shipping-street'>
  <label for='shipping-city'>City</label>
  <input type='text' id='shipping-city'>
</fieldset>

ARIA Label Não Descritivo em Botão de Ícone — Incorreto

<!-- aria-label provides a label but it does not describe the button's purpose -->
<button aria-label='button'>
  <svg aria-hidden='true' focusable='false'><!-- search icon --></svg>
</button>

ARIA Label Não Descritivo em Botão de Ícone — Correto

<!-- aria-label now clearly communicates what activating the button will do -->
<button aria-label='Search products'>
  <svg aria-hidden='true' focusable='false'><!-- search icon --></svg>
</button>

Headings ou Links "Read More" Repetidos — Incorreto

<article>
  <h3>Latest News</h3>
  <p>Istanbul metro expands to three new districts...</p>
</article>
<article>
  <h3>Latest News</h3>
  <p>New regulations affect e-commerce platforms...</p>
</article>

Headings ou Links "Read More" Repetidos — Correto

<!-- Each article has a unique, descriptive heading that identifies its topic -->
<article>
  <h3>Istanbul Metro Expands to Three New Districts</h3>
  <p>Istanbul metro expands to three new districts...</p>
</article>
<article>
  <h3>New Regulations Affect E-Commerce Platforms</h3>
  <p>New regulations affect e-commerce platforms...</p>
</article>

Erros Comuns

• Usar headings posicionais ou ordinais como "Step 1", "Step 2", "Section A" sem qualquer texto descritivo: esses headings dizem ao usuário apenas onde ele está em uma sequência, não sobre o que a seção trata. Sempre combine indicadores de sequência com uma frase nominal descritiva, por exemplo, "Step 2: Verify Your Email Address."
• Dar a todos os cards ou componentes de artigo em uma página de listagem o mesmo texto de heading (por exemplo, cada card de produto tem um <h3> que diz apenas "Product"): cada heading de card deve identificar de forma única aquele produto, post de blog ou item específico.
• Usar texto de placeholder como label acessível para um campo de formulário (confiando no atributo placeholder em vez de um elemento <label> ou aria-label): placeholders desaparecem quando se começa a digitar e não são anunciados de forma confiável por todos os leitores de tela como nomes acessíveis. Mesmo quando existe um placeholder, é necessário um label descritivo separado.
• Escrever um aria-label que apenas repete o tipo de elemento em vez de seu propósito, como aria-label='input' em um campo de texto ou aria-label='button' em um botão: o label deve descrever o que o controle faz ou que valor coleta, não que tipo de elemento ele é.
• Usar texto de tooltip ou atributos title como único label para um controle de formulário e presumir que isso satisfaz 2.4.6: labels baseados em title muitas vezes são inacessíveis para usuários apenas de teclado e não são anunciados de forma consistente por leitores de tela. Em vez disso, confie em elementos <label> visíveis ou em aria-label.
• Rotular campos de busca apenas com "Search" em uma página onde existem múltiplos escopos de busca (por exemplo, busca em todo o site e uma busca dentro de uma tabela de dados): quando dois controles executam buscas diferentes, cada label deve especificar o escopo, como "Search all products" e "Search within order history."
• Aplicar o mesmo texto de heading ao heading de uma janela modal e ao heading principal da página: headings de modais devem descrever a tarefa específica ou o conteúdo da janela (por exemplo, "Confirm Your Cancellation") em vez de herdar o título da página, o que seria confuso para usuários de leitores de tela navegando dentro do modal.
• Omitir um <legend> descritivo para grupos de botões de opção (radio) ou caixas de seleção enquanto fornece labels para as opções individuais: o <legend> fornece contexto essencial que torna cada label individual significativo. "Yes" e "No" como labels de opção isolados são pouco informativos sem um legend como "Do you agree to the terms and conditions?"
• Truncar texto de heading no DOM por razões de design visual (por exemplo, um heading que contém apenas um ícone ou uma única palavra porque o texto completo está em elementos visuais adjacentes): o heading programático deve ser totalmente descritivo porque usuários de leitores de tela o ouvem sem ver o layout visual ao redor.
• Presumir que, porque um label é visível para usuários videntes, ele é descritivo o suficiente para todos os usuários: um label que depende de posição espacial (por exemplo, um cabeçalho de coluna em um grid customizado em que o significado do label depende de ver sua relação com células ao redor) pode ser visualmente claro, mas não transmitir a mesma informação de forma programática. Sempre verifique se o nome acessível por si só é suficiente.

Relação com os Regulamentos de Acessibilidade da Turquia

A Circular Presidencial 2025/10 da Turquia, publicada no Diário Oficial nº 32933 em 21 de junho de 2025, estabelece obrigações obrigatórias de acessibilidade digital para uma ampla gama de entidades públicas e privadas que operam na Turquia. A Circular faz referência explícita às WCAG 2.1 Nível AA como padrão técnico para conformidade, e os requisitos de Nível AA sob WCAG 2.2 — que é retrocompatível com WCAG 2.1 no nível AA — são fortemente incentivados e exigidos para entidades que buscam o Accessibility Logo (Erişilebilirlik Logosu) oficial emitido pelo Ministério da Família e Serviços Sociais (Aile ve Sosyal Hizmetler Bakanlığı).

WCAG 2.4.6 é um critério de Nível AA, o que significa que se enquadra diretamente no escopo do que as entidades cobertas devem abordar para alcançar conformidade total. Os seguintes tipos de entidades são cobertos pela Circular Presidencial: instituições públicas e órgãos governamentais; plataformas de e-commerce; bancos e instituições financeiras; hospitais e prestadores de serviços de saúde; operadoras de telecomunicações com 200.000 ou mais assinantes; agências de viagens; empresas de transporte privado; e escolas privadas autorizadas pelo Ministério da Educação Nacional (Millî Eğitim Bakanlığı).

Para essas entidades, deixar de fornecer headings e labels descritivos acarreta risco regulatório concreto. Um portal governamental com headings de seção vagos impede que cidadãos com deficiência acessem serviços públicos, o que entra em conflito direto com o objetivo declarado da Circular de garantir igualdade de acesso. Um site de e-commerce com labels ambíguos em formulários no fluxo de checkout pode impedir que usuários com deficiências visuais ou cognitivas concluam compras, constituindo uma barreira à participação econômica que a Circular foi concebida para eliminar.

Entidades que buscam o Erişilebilirlik Logosu devem demonstrar conformidade por meio de uma auditoria de acessibilidade, e 2.4.6 está entre os critérios que os auditores avaliarão manualmente. Como este critério exige julgamento humano — ferramentas automatizadas não conseguem avaliar descritividade — as organizações devem incluir uma revisão manual estruturada de todos os headings e labels de formulário como parte padrão de seu processo de auditoria de acessibilidade. Incorporar essa revisão em fluxos de trabalho de gestão de conteúdo e em design systems, em vez de tratá-la como uma tarefa de auditoria pontual, é a estratégia mais eficaz para manter a conformidade contínua à medida que o conteúdo muda ao longo do tempo.