Como validar xhtml?

Saber como validar XHTML significa verificar se um documento está em conformidade com duas camadas de regras: a sintaxe XML e seu DTD ou esquema declarado. O XHTML 1.0 é uma reformulação do HTML 4.01 em XML, portanto, um documento pode ser bem formado, mas inválido, como quando <a target="_blank"> aparece no XHTML 1.0 Strict.

Validar XHTML é verificar se um documento obedece simultaneamente a duas camadas de regras:

1. Regras de Sintaxe XML: tags aninhadas corretamente, atributos entre aspas, fechamento obrigatório de todos os elementos (incluindo os vazios como <br />), um único elemento raiz, uma codificação declarada consistente, etc.
2. Regras de DTD ou esquema declarado: quais elementos e atributos existem, em que contexto podem aparecer e quais valores são permitidos. Aqui estão os DTDs clássicos do XHTML 1.0 (Strict, Transitional, Frameset), XHTML 1.1, XHTML Basic e XHTML Modularization.

Um documento pode ser um XML bem formado e ainda assim ser inválido: por exemplo, se você usar <a target="_blank"> em XHTML 1.0 Strict, a sintaxe é impecável, mas o atributo target não existe nesse DTD. Esta distinção entre bem formado e válido é a causa número um de confusão quando alguém vê um erro e não entende o porquê.

É conveniente lembrar também que o XHTML 1.0 é uma reformulação do HTML 4.01 em XML, definido pelo W3C. Hoje, seu valor prático é duplo: serve para projetos legados que ainda são servidos como application/xhtml+xml ou text/html, e serve como uma disciplina mental para escrever marcações limpas. Se você deseja o contexto normativo completo sobre como validar XHTML, a especificação de XHTML 1.0 do W3C é a fonte primária.

Os validadores que valem a pena (e quando usar cada um)

Não existe um único validador “correto”. A escolha depende se você está validando um fragmento, uma página de produção, um site inteiro ou um documento que já é XHTML5.

Ferramenta	O que valida	Ideal para	Limitação principal
W3C Markup Validation Service (validator.w3.org)	XHTML 1.0/1.1, HTML4, HTML5	Validação pontual por URL, arquivo ou colagem direta	O “Nu Html Checker” moderno prioriza HTML5; os DTDs antigos requerem seleção manual
Nu Html Checker (vnu)	HTML5 e XHTML5	Projetos novos, validação local e em CI	Não valida DTDs clássicos de XHTML 1.x
Validadores locais (vnu.jar, tidy)	Conforme configuração	Automatização, pre-commit, pipelines	Requer instalação de Java ou binários; configuração inicial
xmllint	Well-formedness XML e validação contra DTD/XSD	Comprovar a camada XML pura	Não conhece regras específicas de HTML além do esquema
Extensões de navegador / IDE	Marcação em tempo real	Feedback imediato enquanto escreve	Costumam usar motores desatualizados ou incompletos

O W3C Markup Validation Service

Continua sendo o ponto de partida para aqueles que se perguntam como validar XHTML. Ele suporta três modos: Validate by URI, Validate by File Upload e Validate by Direct Input. Para XHTML clássico, o truque está no menu suspenso Document Type: se o seu documento declarar seu próprio DTD através do DOCTYPE, o validador o respeitará; caso contrário, você terá que forçá-lo manualmente.

Relacionado: UserWay — Widget de acessibilidade com plano gratuito para começar hoje mesmo.

Um detalhe que muitos desconhecem: o validador W3C moderno baseia-se no Nu Html Checker, que entende HTML5 e XHTML5, mas trata DTDs antigos com menos prioridade. Para XHTML 1.0 Strict ainda funciona, mas é aconselhável verificar se o resultado reflete o DTD que você espera e não uma interpretação permissiva.

Nu Html Checker (vnu)

Este é o validador que o próprio W3C utiliza internamente. Ele existe como um serviço web, como um executável JAR e como uma imagem Docker. Sua grande vantagem é que você pode executá-lo localmente e em integração contínua, algo essencial se você mantém um site grande. Para XHTML servido como application/xhtml+xml, o vnu detecta erros de aninhamento e atributos que um validador HTML tolerante deixaria passar.

xmllint

Se a sua preocupação é a camada XML pura — por exemplo, porque você gera XHTML a partir de templates XSLT — então o xmllint é insubstituível. Com --noout --valid documento.xhtml, ele verifica a boa formação (well-formedness) e a validade em relação ao DTD referenciado. É rápido, programável e não depende da rede.

Vale a pena dar uma olhada: AudioEye — Acessibilidade gerenciada: automatização combinada com revisão humana.

Validação no editor

Extensões para VS Code, plugins de IDE e ferramentas de linha de comando oferecem feedback instantâneo. São convenientes, mas tendem a ficar defasados em relação aos padrões. Use-os como primeira linha de defesa, nunca como a única verificação.

Como validar XHTML passo a passo

1. Declare corretamente o DOCTYPE e a codificação

O DOCTYPE determina contra quais regras o documento será validado. Para XHTML 1.0 Strict:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
  "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="es" lang="es">
<head>
  <meta http-equiv="Content-Type"
        content="application/xhtml+xml; charset=UTF-8" />
  <title>Exemplo válido</title>
</head>

Dois erros clássicos aqui: esquecer o atributo xmlns (obrigatório em XHTML) e declarar uma codificação no meta que não coincide com o arquivo real. O validador detecta ambos, mas o segundo às vezes só aparece como caracteres corrompidos.

2. Verifique a well-formedness antes da validade

Antes de lutar com o DTD, certifique-se de que o XML esteja bem formado. xmllint --noout arquivo.xhtml informará em segundos. Se falhar aqui, nenhum validador DTD irá ajudá-lo: primeiro feche as tags, corrija o aninhamento e escape as entidades (&, <, >).

3. Valide contra o DTD

Com o documento bem formado, passe-o pelo Validador W3C ou vnu. Revise não apenas quantos erros existem, mas de que tipo. Um único erro de aninhamento pode gerar uma cascata de erros secundários que desaparecem após a correção do primeiro.

4. Valide o site completo, não apenas a home

Um erro comum é validar a página principal e presumir que o resto está correto. Templates, componentes e páginas geradas dinamicamente costumam introduzir marcações inválidas. Automatize: percorra as URLs principais com um script e execute o vnu em cada resposta.

Relacionado: IAAP CPACC / WAS Certification — A certificação profissional que acredita sua experiência e acessibilidade.

5. Integre a validação em seu fluxo

A validação manual não escala. Adicione uma etapa de validação em seu pipeline (pre-commit hook, tarefa de build ou job de CI) que falhe se um novo erro aparecer. Dessa forma, a marcação inválida nunca chega à produção.

Interpretar os erros: os que você verá repetidamente

• “end tag for X omitted, but OMITTED end tags are not allowed”: típico de <li>, <p> ou <td> sem fechamento. Em XHTML, tudo deve ser fechado.
• “there is no attribute X”: o atributo não existe no seu DTD. Casos usuais: target, name em alguns elementos, atributos data-* em XHTML 1.0 (não presentes no DTD clássico).
• “element X undefined”: usa um elemento que seu DTD não reconhece, frequentemente ao copiar marcação HTML5 para um documento XHTML 1.0.
• “character data is not allowed here”: conteúdo de texto onde o DTD espera apenas elementos, ou um & sem escape.
• “reference to entity X for which no system identifier could be generated”: entidades HTML nomeadas que não são definidas em XML (por exemplo,   sem declaração). Em XHTML puro, use   ou declare a entidade.

A regra de ouro para saber como validar XHTML: corrigir de cima para baixo. O primeiro erro geralmente é a causa; os seguintes são a consequência.

XHTML5: a nuance que muda as regras

Se você serve XHTML5 — XHTML serializado de acordo com a sintaxe HTML5 —, as regras mudam. Não existe mais um DTD: a conformidade é definida na especificação HTML do WHATWG e nas especificações do W3C sobre HTML. O validador correto é o Nu Html Checker, não o validador DTD clássico.

Se você estiver comprando: accessiBe — Superposição de IA que promete cumprimento WCAG em 48 horas.

Diferenças práticas a serem observadas sobre como validar XHTML:

• Os atributos data-* são válidos em XHTML5, não em XHTML 1.0.
• O DOCTYPE é simplificado para <!DOCTYPE html>.
• A validação é feita contra o conformance checker do HTML5, que é mais permissivo em alguns pontos e mais rigoroso em outros (por exemplo, no uso de certos elementos obsoletos).

Escolher entre XHTML 1.0 e XHTML5 não é apenas técnico: se o seu projeto é novo, XHTML5 com validação vnu é o caminho sensato. Se você mantém um sistema legado com DTD, permaneça no XHTML 1.0 e valide contra seu DTD.

Validação e acessibilidade: duas camadas distintas

Um erro comum é acreditar que um documento válido é automaticamente acessível. Não é. A validação verifica a conformidade de sintaxe e esquema; a acessibilidade é avaliada contra as WCAG do W3C, que cobrem percepção, operabilidade e compatibilidade com tecnologias assistivas.

Dito isso, há uma sobreposição real: a marcação inválida geralmente implica uma estrutura deficiente (títulos mal aninhados, listas quebradas, formulários sem rótulos corretos), e isso afeta a acessibilidade. A estratégia sensata para saber como validar XHTML e outros documentos é validar primeiro (eliminar ruído estrutural) e auditar a acessibilidade depois com ferramentas como axe, Lighthouse ou revisões manuais. A validação é uma condição necessária, mas não suficiente.

Erros frequentes ao validar XHTML

Ao aprender como validar XHTML, evite estes erros comuns:

• Validar apenas a home. A marcação problemática geralmente está em templates internos.
• Ignorar a codificação. Um charset mal declarado produz erros fantasmas.
• Confundir bem formado com válido. São camadas distintas; resolva-as em ordem.
• Usar o validador errado. vnu para XHTML5, DTD para XHTML 1.x.
• Corrigir erros em cascata sem ler o primeiro. Você perde tempo e corrige sintomas.
• Não automatizar. A validação manual não sobrevive ao segundo sprint.
• Assumir que válido = acessível. São padrões diferentes com propósitos diferentes.

Principais Conclusões

• Validar XHTML envolve duas camadas: well-formedness XML e conformidade com o DTD ou esquema declarado.
• O W3C Markup Validation Service e o Nu Html Checker (vnu) são as ferramentas de referência para saber como validar XHTML; o xmllint cobre a camada XML pura.
• Para XHTML 1.0/1.1, use a validação contra DTD; para XHTML5, use o vnu e esqueça os DTDs clássicos.
• Corrija os erros de cima para baixo: o primeiro geralmente causa os seguintes.
• Automatize a validação em seu pipeline; a revisão manual não escala.
• Válido não é sinônimo de acessível: são padrões complementares, não equivalentes.

Fontes e Leituras Adicionais

• XHTML — Wikipedia: Extensible HyperText Markup Language (XHTML) is part of the family of XML markup languages which mirrors or extends versions of the widely used HyperText Markup…
• XHTML Basic — Wikipedia: XHTML Basic is an XML-based markup language designed for simple user agents with limited computing power, such as early mobile phones, PDAs, pagers, and set-top…

Perguntas Frequentes

Qual é a diferença entre XHTML bem formado e XHTML válido?

Um documento bem formado segue as regras sintáticas do XML: tags fechadas, aninhamento correto e atributos entre aspas. Um documento válido, além disso, respeita o DTD ou esquema que declara: utilizando apenas elementos e atributos permitidos em seu contexto. Você pode ter um documento bem formado, mas inválido, por exemplo, se usar um atributo que não existe no XHTML 1.0 Strict.

Ainda faz sentido validar XHTML em 2024?

Sim, por dois motivos. Primeiro, muitos projetos legados continuam servindo XHTML e precisam permanecer válidos para não quebrarem no modo XML. Segundo, a validação é uma disciplina que detecta erros estruturais que afetam a acessibilidade e a manutenção. Se o seu projeto é novo, provavelmente usa HTML5 ou XHTML5, mas o hábito de validar continua sendo valioso.

Qual validador devo usar para XHTML5?

Nu Html Checker (vnu), disponível como serviço web, executável JAR e imagem Docker. É o mesmo motor que o moderno W3C Markup Validation Service utiliza e entende a sintaxe HTML5 e sua serialização XHTML. Não use validadores DTD clássicos para XHTML5: eles não reconhecerão atributos data-* ou outros recursos do HTML5.

Por que o validador do W3C me dá erros que não entendo?

Porque muitos erros são consequência de um anterior. O aninhamento incorreto pode gerar dezenas de mensagens secundárias. A estratégia correta é corrigir o primeiro erro, validar novamente e repetir. Também acontece que o validador aplica o DTD declarado no DOCTYPE; se esse DTD não for o que você esperava, os erros parecerão arbitrários.

Posso validar XHTML pela linha de comando?

Sim. Se você está se perguntando como validar XHTML via CLI, xmllint --noout --valid archivo.xhtml verifica a boa formação e validade em relação ao DTD. Para HTML5/XHTML5, vnu.jar archivo.xhtml faz o mesmo. Ambas as opções são ideais para integração em scripts de build, hooks de pré-commit ou jobs de integração contínua, onde a validação manual não é escalonável.

Um site XHTML válido é automaticamente acessível?

Não. A validação verifica a conformidade sintática e de esquema; a acessibilidade é avaliada em relação às WCAG, que cobrem aspectos como contraste, navegação pelo teclado, texto alternativo ou estrutura semântica. Um documento pode ser perfeitamente válido e ainda assim permanecer inacessível. Valide primeiro e audite a acessibilidade depois: são camadas complementares.