Verificador de cabeçalho WCAG

O que é um verificador de cabeçalhos WCAG?

Um verificador de cabeçalhos WCAG valida que os elementos de cabeçalho em uma página web (h1, h2, h3, h4, h5, h6) formam uma hierarquia lógica que leitores de tela e outras tecnologias assistivas podem navegar. Cabeçalhos são como usuários cegos e com baixa visão navegam por uma página: eles usam um atalho do leitor de tela para pular de cabeçalho em cabeçalho, construindo um índice mental em segundos. Se os cabeçalhos estiverem faltando, fora de ordem ou usados decorativamente, essa navegação desaba. O Critério de Sucesso WCAG 2.2 1.3.1 (Informação e Relacionamentos) e 2.4.6 (Cabeçalhos e Rótulos) exigem que os cabeçalhos transmitam a estrutura corretamente.

As regras são simples de declarar e fáceis de violar. Deve haver exatamente um h1 por página (o título da página). Cada cabeçalho subsequente deve ser no máximo um nível mais profundo que seu pai (um h2 pode ser seguido por outro h2 ou por um h3, mas não diretamente por um h4). Cabeçalhos não devem estar vazios. Os níveis de cabeçalho devem descrever a estrutura do documento, não o tamanho visual (não use h4 apenas porque voce quer texto menor). A maioria das auditorias de acessibilidade sinaliza problemas de hierarquia de cabeçalho como a primeira coisa a corrigir porque eles são comuns, fáceis de verificar e de alto impacto para usuários de leitores de tela.

Esta ferramenta analisa o HTML que voce cola (sem upload, sem viagem de ida e volta ao servidor), percorre os elementos de cabeçalho em ordem de documento e relata os problemas: h1 faltando, múltiplos h1, níveis pulados, cabeçalhos vazios e um esboço da estrutura da página. A saída é texto simples descrevendo cada problema. Execute em qualquer página durante o desenvolvimento, antes do lançamento, ou como parte de um ciclo regular de auditoria de acessibilidade. A saída está em linguagem simples, não uma pontuação numérica; o objetivo é dar a voce problemas específicos para corrigir, não uma nota de aprovação para perseguir.

O que há dentro da ferramenta

O topo da página é uma área de texto onde voce cola seu HTML. Voce pode colar um documento completo (DOCTYPE, html, head, body) ou um fragmento (apenas o conteúdo do body). A ferramenta extrai todos os elementos h1 a h6 em ordem de documento usando um DOMParser padrão do navegador, então a análise corresponde ao que um navegador real faria. A área de texto lida com entrada de qualquer tamanho; documentos muito grandes (dezenas de milhares de linhas) funcionam mas levam uma fração de segundo a mais para analisar.

Clique em Verificar Cabeçalhos e os resultados aparecem abaixo. A primeira seção é o esboço de cabeçalhos: cada cabeçalho em ordem, recuado por nível, então voce pode ler a estrutura como um índice. A segunda seção é a lista de problemas: cada problema com sua localização específica, o que está errado e uma breve explicação de por que importa. Os problemas são categorizados por severidade: erros (devem ser corrigidos para conformidade WCAG) e avisos (melhor prática mas não falhas estritas).

A saída permanece no navegador; nada é enviado. Voce pode colar o mesmo HTML muitas vezes com edições entre eles para iterar nas correções. A ferramenta intencionalmente não verifica nada fora da estrutura de cabeçalhos (ela não verifica texto alt, contraste, ordem de foco, ARIA ou qualquer outro critério WCAG). Para esses, use esta ferramenta ao lado de uma ferramenta de auditoria abrangente como axe DevTools, Lighthouse ou WAVE.

História e contexto

Cabeçalhos HTML desde o início (1991)

Tim Berners-Lee introduziu HTML em 1991 com elementos h1 a h6 como parte das 18 tags originais. A intenção semantica original sempre foi a estrutura do documento, não estilo visual. A hierarquia de cabeçalhos da Web vem de uma tradição muito mais antiga: documentos impressos (livros, artigos, relatórios governamentais) usaram níveis de seção numerados por séculos para transmitir estrutura. HTML herdou esse modelo diretamente. Apesar de 35 anos de semantica estável, o uso indevido de cabeçalhos é um dos bugs de acessibilidade mais comuns na web moderna porque designers frequentemente estilizam por tamanho visual primeiro e verificam a estrutura depois.

Leitores de tela aprendem a navegar por cabeçalho (a partir de 1996)

JAWS (Job Access With Speech) foi lançado pela Henter-Joyce em 1989 e adicionou navegação de cabeçalho de página da web conforme a Web se tornava popular no final dos anos 1990. Pressionar a tecla H no JAWS pula para o próximo cabeçalho; teclas numeradas 1 a 6 pulam para esse nível de cabeçalho específico. Todo grande leitor de tela desde então (NVDA em 2006, VoiceOver em 2005, TalkBack no Android) copiou esse atalho. A Pesquisa Anual de Usuários de Leitores de Tela da WebAIM consistentemente encontra que 67 a 70 por cento dos usuários de leitores de tela navegam por cabeçalhos como seu método principal para entender uma página. A hierarquia de cabeçalhos quebrada não é, portanto, um problema cosmético.

WCAG 1.0 e a ascensão dos padrões de acessibilidade (1999)

As Diretrizes de Acessibilidade para Conteúdo da Web 1.0 foram publicadas pelo W3C em maio de 1999, o primeiro padrão internacional para acessibilidade Web. WCAG 1.0 exigia explicitamente que cabeçalhos fossem usados para estrutura de documento (Ponto de Verificação 3.5). WCAG 2.0 (2008) refinou isso em Critério de Sucesso 1.3.1 (Informação e Relacionamentos, Nível A) e 2.4.6 (Cabeçalhos e Rótulos, Nível AA). WCAG 2.1 (2018) e 2.2 (2023) mantiveram esses critérios inalterados porque o requisito subjacente é sólido. A maioria das leis de acessibilidade ao redor do mundo (ADA nos EUA, EAA na Europa, AODA em Ontário) agora citam WCAG 2.1 AA como a linha de base legal.

Seccionamento HTML5 e o esboço do documento (2014)

HTML5 (Recomendação W3C 2014) introduziu elementos de seccionamento (article, section, nav, aside) e um algoritmo de esboço que deveria derivar a hierarquia de cabeçalhos da profundidade de aninhamento. O algoritmo nunca foi implementado em nenhum navegador ou leitor de tela e foi formalmente depreciado em 2022. A orientação prática é: use níveis de cabeçalho explícitos (h1 a h6) e trate elementos de seccionamento como agrupamento semantico, não como substituto para profundidade de cabeçalho. O HTML Living Standard agora afirma claramente que os níveis de cabeçalho devem ser definidos explicitamente.

Papéis ARIA e aria-level (a partir de 2014)

WAI-ARIA 1.1 (Recomendação W3C 2017) fornece role="heading" com aria-level="N" como uma forma alternativa de marcar cabeçalhos, útil quando voce não pode usar os elementos nativos h1-h6 (por exemplo, em um componente de framework que precisa renderizar diferentes níveis de cabeçalho em contextos diferentes). Leitores de tela tratam role="heading" identicamente ao elemento nativo. A melhor prática é usar elementos nativos quando possível; use ARIA apenas quando a semantica nativa não estiver disponível. Esta ferramenta verifica tanto elementos de cabeçalho nativos quanto elementos com role="heading".

Processos de acessibilidade e o caso de negócios (a partir de 2017)

Domino's Pizza vs. Robles (Suprema Corte dos EUA 2019) estabeleceu que a Lei dos Americanos com Deficiencias (ADA, 1990) se aplica a sites comerciais. Centenas de processos similares se seguiram a cada ano (mais de 4.000 processos ADA na web ajuizados apenas em 2024). A Lei Europeia de Acessibilidade (EAA, em vigor em junho de 2025) torna a acessibilidade equivalente ao WCAG um requisito legal para a maioria dos sites voltados ao consumidor em toda a UE. Estrutura de cabeçalhos com falha é um dos problemas mais fáceis para os queixosos identificarem e documentarem, o que torna verificações básicas de cabeçalho uma etapa de conformidade de alto impacto.

Fluxos de trabalho práticos

Verificação pré-lançamento em novas páginas e modelos

Antes de qualquer nova página ou modelo ser enviado, execute o HTML através deste verificador. Problemas de estrutura de cabeçalho são os bugs de acessibilidade mais fáceis de introduzir (especialmente em conteúdo gerenciado por CMS onde editores escolhem níveis de cabeçalho com base no tamanho visual) e os mais fáceis de corrigir. Pegá-los antes do lançamento é muito mais barato do que depois, quando as correções exigem coordenação com os proprietários do conteúdo. Para agencias, integre essa verificação na lista de verificação de QA; para equipes internas, execute como parte da revisão de código ou antes da mesclagem ao main.

Auditoria de um site existente para conformidade de acessibilidade

Para uma auditoria de acessibilidade (pré-litígio, conformidade EAA, requisito contratual), percorra as páginas mais visitadas e execute o HTML de cada uma através deste verificador. Documente as descobertas: quais páginas tem problemas de cabeçalho, qual tipo, como corrigir. Combine com axe DevTools ou Lighthouse para os outros critérios WCAG. As descobertas de estrutura de cabeçalho são geralmente as mais fáceis de remediar e formam uma seção sólida de ganhos rápidos do relatório de auditoria.

Treinamento de editor CMS e modelagem

Conteúdo gerenciado por CMS (WordPress, Drupal, Contentful, Sanity) frequentemente dá aos editores um menu suspenso de cabeçalho com opções H1 a H6. Editores que não conhecem as regras escolhem níveis por tamanho visual. Demonstre este verificador aos editores para que eles possam ver o que suas escolhas de cabeçalho produzem. Para modelos, execute a saída renderizada através do verificador após cada mudança de design para confirmar que as escolhas de cabeçalho do editor ainda produzem hierarquia válida. Muitos plugins CMS existem que avisam editores em tempo de escrita; esta ferramenta serve à etapa de verificação.

Validar modelos de e-mail e boletins HTML

E-mails HTML lidos por leitores de tela devem seguir a mesma hierarquia de cabeçalho que páginas da web. Execute o HTML do seu modelo de e-mail através deste verificador antes de enviar para uma grande lista. Problemas comuns de modelo de e-mail: múltiplos h1 (quando cada seção tem sua própria manchete), h1 faltando (quando o layout começa diretamente com h2) e h4 decorativos usados puramente para cabeçalhos pequenos. Corrija isso antes de enviar; usuários de tecnologia assistiva em sua lista notarão.

Validar conversões PDF para HTML

Quando voce converte PDFs para HTML para acessibilidade (para que possam ser lidos por leitores de tela com navegação de cabeçalho), o conversor tem que mapear tags de estrutura PDF para níveis de cabeçalho HTML. O resultado é frequentemente quebrado: PDFs sem etiquetagem adequada produzem HTML plano sem cabeçalhos, e até mesmo PDFs etiquetados às vezes produzem saída todo-h1 ou todo-h2. Execute o HTML convertido através deste verificador para detectar o problema antes de publicar a página convertida.

Integração de novos desenvolvedores e designers

Desenvolvedores front-end juniores e designers se beneficiam de ver exemplos concretos de hierarquia de cabeçalhos quebrada e a experiencia de leitor de tela resultante. Combine esta ferramenta com uma demonstração de leitor de tela (NVDA no Windows é gratuito, VoiceOver no Mac é integrado) para mostrar como cabeçalhos direcionam a navegação do leitor de tela. A conexão entre regras abstratas de cabeçalho e experiencia concreta do usuário é frequentemente o que faz a lição grudar.

Armadilhas comuns

Escolhendo nível de cabeçalho por tamanho visual

O erro mais comum: usar um h4 porque voce quer texto menor, ou pular de h2 para h4 porque não há h3 dimensionado corretamente no design. Níveis de cabeçalho são estruturais, não visuais; use CSS para controlar o tamanho e use o nível que corresponde à hierarquia do documento. Se seu sistema de design não tiver um estilo visual para cada nível necessário, adicione um (ou substitua com nomes de classe) em vez de escolher o nível errado.

Múltiplos h1 por página

Uma página deve ter exatamente um h1 representando o título da página. Bugs comuns: um logo do site envolvido em h1 mais um título de artigo também em h1 (dois h1), uma página inicial com cada seção hero usando h1 (múltiplos h1), ou nenhum h1 porque o layout começa com h2. A correção é estrutural: escolha o conteúdo mais importante na página como o único h1 e rebaixe tudo mais para h2 ou abaixo. Ferramentas como axe e Lighthouse avisam sobre múltiplos h1 por esta razão.

Níveis de cabeçalho pulados

Ir de h2 diretamente para h4 quebra o esboço do documento. Usuários de leitor de tela movendo-se de cabeçalho para cabeçalho esperam que cada h4 esteja aninhado sob um h3, e o h3 faltando confunde a estrutura. A correção é inserir o nível intermediário faltando ou rebaixar o h4 para h3. A causa mais comum é copiar design de uma maquete onde a hierarquia visual usa tres tamanhos mas o sistema de design usa quatro níveis de cabeçalho; verifique novamente após cada atualização de componente.

Cabeçalhos vazios

Um h2 sem conteúdo de texto (frequentemente porque um widget JavaScript removeu o texto mas manteve o elemento) aparece na lista de cabeçalhos do leitor de tela como um cabeçalho não rotulado, o que é confuso e inútil. Ou preencha o cabeçalho com texto, ou remova o elemento de cabeçalho inteiramente. Isso é comum em aplicativos de página única onde elementos de espaço reservado são renderizados antes que os dados sejam carregados; renderize o cabeçalho apenas quando houver conteúdo para colocar nele.

Cabeçalhos dentro de invólucros não semanticos

Um cabeçalho envolvido em um div com role="presentation" ou aria-hidden="true" é removido da árvore de acessibilidade, o que pode ocultar um cabeçalho de outra forma correto dos leitores de tela. Audite os elementos pais de cada cabeçalho para garantir que não removam o cabeçalho da árvore de acessibilidade. CSS display:none e visibility:hidden também removem o cabeçalho; use apenas intencionalmente e nunca em conteúdo que deva ser visível para o leitor de tela.

Usar ARIA quando HTML nativo seria suficiente

Adicionar role="heading" aria-level="2" a um div em vez de usar um elemento h2 funciona para acessibilidade mas é complexidade desnecessária. Elementos nativos h1-h6 obtem semantica de cabeçalho gratuitamente, renderizam corretamente em estilos padrão de navegador e sobrevivem melhor a bugs de leitor de tela do que substituições ARIA. A primeira regra do ARIA (por práticas de autoria WAI-ARIA) é: não use ARIA quando HTML nativo fornece a mesma semantica. Use elementos de cabeçalho nativos a menos que uma restrição de framework genuinamente force ARIA.

Privacidade e tratamento de dados

O HTML que voce cola permanece em seu navegador durante toda a verificação. O DOMParser que extrai os cabeçalhos é executado em JavaScript na sua máquina; os resultados são renderizados na página abaixo da área de texto. Não há etapa de upload, processamento remoto ou telemetria sobre qual HTML voce colou. Isso importa porque o HTML que voce mais quer verificar (modelos pré-lançamento, sites de clientes sob NDA, páginas de administração internas) é exatamente o que voce não deve colar em um validador SaaS de terceiros.

Uma vez que a página é carregada, a ferramenta funciona offline. Voce pode desconectar da internet, colar HTML, executar a verificação e revisar os resultados sem que sua marcação toque outra máquina. A maioria dos verificadores de acessibilidade em nuvem (PowerMapper, Tenon, Site Improve) exigem o upload do URL da página ou HTML; para páginas confidenciais esse é precisamente o modo de falha a evitar.

Quando não usar esta ferramenta

Para auditorias WCAG completas (use uma ferramenta abrangente)

Estrutura de cabeçalho é um de dezenas de critérios WCAG. Para uma auditoria completa, use axe DevTools (extensão Chrome/Firefox gratuita da Deque), Lighthouse (integrado ao Chrome), WAVE (ferramenta gratuita da WebAIM), ou uma solução paga como Tenon ou PowerMapper. Estes verificam contraste de cor, texto alt, uso de ARIA, rótulos de formulário, ordem de foco e muito mais. Execute esta ferramenta ao lado, não no lugar, das abrangentes.

Para conteúdo dinamico (teste o DOM renderizado)

Se seus cabeçalhos são gerados por JavaScript (React, Vue, Svelte, Angular), a fonte HTML estática não contém os cabeçalhos finais. Voce precisa colar o DOM renderizado após o JavaScript executar. Use as DevTools do navegador: abra a página, abra DevTools, aba Elements, clique com o botão direito no body ou main, Copiar outerHTML, depois cole isso neste verificador. Ou use uma extensão de navegador que percorre o DOM ao vivo diretamente.

Para pipelines CI/CD automatizados (use uma biblioteca Node)

Se voce quer que verificações de cabeçalho sejam executadas automaticamente em cada commit ou pull request, integre axe-core, Pa11y ou jest-axe em sua suíte de testes. Eles executam verificações de cabeçalho (e muitas outras verificações WCAG) sem cabeça no CI. Esta ferramenta de navegador é para uso interativo durante desenvolvimento e revisão, não para automação. Ambas tem seu lugar; use a ferramenta de navegador para auditorias pontuais e a biblioteca CI para validação contínua.

Para acessibilidade de documentos PDF ou Word

PDFs e documentos Word tem seus próprios sistemas de marcação de acessibilidade (PDF/UA, os estilos de cabeçalho Word). Eles não usam cabeçalhos HTML, então esta ferramenta não se aplica. Para acessibilidade PDF, use o Verificador de Acessibilidade do Adobe Acrobat Pro ou PAC 2024 (gratuito, focado em PDF/UA). Para Word, use o Verificador de Acessibilidade integrado (aba Revisar). Converta para HTML primeiro se voce quiser usar esta ferramenta, mas a conversão em si pode introduzir problemas de cabeçalho.

Mais perguntas

Alguma vez está OK pular um nível de cabeçalho?

Não em conteúdo de documento direto. WCAG 2.2 SC 1.3.1 implica que cabeçalhos devem formar uma sequencia hierárquica. O caso comum onde parece um salto é o esboço da página começando em h1 depois h2 dentro da área de conteúdo principal, enquanto uma barra lateral ou navegação também tem h2; isso está bem porque ambos são irmãos sob o h1 da página. A regra real é: não pule níveis dentro de um fluxo de conteúdo contíguo. O verificador sinaliza apenas saltos verdadeiros.

E se meu framework só suportar um nível de cabeçalho?

Algumas bibliotecas de componentes renderizam cabeçalhos em um nível fixo (sempre h2, independentemente do aninhamento). A correção é expor uma prop de nível no componente de cabeçalho (h2, h3, etc.) e fazer com que os pais passem o valor apropriado. Frameworks como React frequentemente fazem isso; se o seu não, adicione um aria-level no componente e use role="heading" como uma solução temporária até que voce possa refatorar. A longo prazo, todo componente de cabeçalho reutilizável deve aceitar uma prop de nível.

A ferramenta verifica papéis ARIA como role="heading"?

Sim. Qualquer elemento com role="heading" e um atributo aria-level válido (1 a 6) é tratado como um cabeçalho no nível indicado. Elementos nativos h1-h6 são sempre preferidos, mas cabeçalhos marcados com ARIA são igualmente válidos para leitores de tela e são verificados ao lado dos nativos.

Quão importante é a hierarquia de cabeçalhos comparada com outros critérios WCAG?

Muito. A Pesquisa Anual de Usuários de Leitores de Tela da WebAIM consistentemente encontra que 67-70% dos usuários de leitores de tela navegam por cabeçalhos como sua forma primária de entender uma página. Cabeçalhos ruins efetivamente bloqueiam um dos principais métodos de navegação de acessibilidade. Na análise anual WebAIM Million da WebAIM, problemas de cabeçalho estão entre as cinco falhas de acessibilidade mais comuns em toda a web. A combinação de alto impacto no usuário e detecção fácil os torna uma prioridade principal.

Toda página deve ter um h1?

Sim, com raras exceções. Todo documento HTML completo deve ter exatamente um h1 que representa o título da página. A exceção são fragmentos que são explicitamente inseridos em uma página maior (uma assinatura de e-mail, um widget incorporado em outra página); a página hospedeira fornece o h1 e o fragmento começa em h2 ou inferior. Para páginas autonomas, h1 faltando é uma falha clara de acessibilidade.

Posso confiar nesta ferramenta para auditorias de conformidade legal?

Para estrutura de cabeçalhos especificamente, sim: as regras são precisas e a ferramenta as implementa com precisão. Para conformidade geral WCAG, nenhuma ferramenta automatizada por si só é suficiente; testes manuais com tecnologia assistiva, revisão de especialistas e testes de usuário com usuários com deficiencia são necessários para auditorias de grau legal. Use esta ferramenta como uma das várias entradas em sua auditoria, não como a única fonte de verdade para conformidade.