¿Cómo validar xhtml?

Cómo validar XHTML significa comprobar que un documento cumple con dos capas de reglas: la sintaxis XML y su DTD o esquema declarado. XHTML 1.0 es una reformulación de HTML 4.01 en XML, por lo que un documento puede estar bien formado pero ser inválido, como cuando aparece <a target="_blank"> en XHTML 1.0 Strict.

Validar XHTML es comprobar que un documento cumple simultáneamente con dos capas de reglas:

1. Reglas de sintaxis XML: etiquetas correctamente anidadas, atributos entre comillas, cierre obligatorio de todos los elementos (incluidos los vacíos como <br />), un único elemento raíz, una codificación declarada coherente, etc.
2. Reglas de la DTD o esquema declarado: qué elementos y atributos existen, en qué contexto pueden aparecer y qué valores se permiten. Aquí están las DTD clásicas de XHTML 1.0 (Strict, Transitional, Frameset), XHTML 1.1, XHTML Basic y XHTML Modularization.

Un documento puede estar bien formado en XML y seguir siendo inválido: por ejemplo, si usas <a target="_blank"> en XHTML 1.0 Strict, la sintaxis es impecable pero el atributo target no existe en esa DTD. Esta distinción entre bien formado y válido es la causa número uno de confusión cuando alguien ve un error y no entiende por qué.

También conviene recordar que XHTML 1.0 es una reformulación de HTML 4.01 en XML, definida por el W3C. Hoy, su valor práctico es doble: sirve para proyectos heredados que todavía se sirven como application/xhtml+xml o text/html, y sirve como disciplina mental para escribir marcado limpio. Si quieres el contexto normativo completo sobre cómo validar XHTML, la especificación de XHTML 1.0 del W3C es la fuente primaria.

Los validadores que merecen la pena (y cuándo usar cada uno)

No existe un único validador “correcto”. La elección depende de si estás validando un fragmento, una página en producción, un sitio completo o un documento que ya es XHTML5.

Herramienta	Qué valida	Ideal para	Limitación principal
W3C Markup Validation Service (validator.w3.org)	XHTML 1.0/1.1, HTML4, HTML5	Validación puntual por URL, archivo o pegado directo	El “Nu Html Checker” moderno prioriza HTML5; las DTD antiguas requieren selección manual
Nu Html Checker (vnu)	HTML5 y XHTML5	Proyectos nuevos, validación local y en CI	No valida DTD clásicas de XHTML 1.x
Validadores locales (vnu.jar, tidy)	Según configuración	Automatización, pre-commit, pipelines	Requiere instalar Java o binarios; configuración inicial
xmllint	Well-formedness XML y validación contra DTD/XSD	Comprobar la capa XML pura	No conoce reglas específicas de HTML más allá del esquema
Extensiones de navegador / IDE	Marcado en vivo	Feedback inmediato mientras escribes	Suelen usar motores desactualizados o incompletos

El W3C Markup Validation Service

Sigue siendo el punto de partida para quienes se preguntan cómo validar XHTML. Admite tres modos: Validate by URI, Validate by File Upload y Validate by Direct Input. Para XHTML clásico, el truco está en el desplegable Document Type: si tu documento declara su propia DTD mediante el DOCTYPE, el validador la respeta; si no, hay que forzarla manualmente.

Relacionado: UserWay — Widget de accesibilidad con plan gratuito para empezar hoy mismo.

Un detalle que muchos desconocen: el validador moderno del W3C se apoya en el Nu Html Checker, que entiende HTML5 y XHTML5 pero trata las DTD antiguas con menos prioridad. Para XHTML 1.0 Strict todavía funciona, pero conviene verificar que el resultado refleja la DTD que esperas y no una interpretación laxa.

Nu Html Checker (vnu)

Es el validador que el propio W3C usa internamente. Existe como servicio web, como ejecutable JAR y como imagen Docker. Su gran ventaja es que puedes ejecutarlo localmente y en integración continua, algo esencial si mantienes un sitio grande. Para XHTML servido como application/xhtml+xml, vnu detecta errores de anidamiento y de atributos que un validador HTML tolerante dejaría pasar.

xmllint

Si tu preocupación es la capa XML pura —por ejemplo, porque generas XHTML a partir de plantillas XSLT—, entonces xmllint es irreemplazable. Con --noout --valid documento.xhtml comprueba la well-formedness y la validez contra la DTD referenciada. Es rápido, scriptable y no depende de la red.

Vale la pena echarle un vistazo: AudioEye — Accesibilidad gestionada: automatización combinada con revisión humana.

Validación en el editor

Las extensiones para VS Code, los plugins de IDE y las herramientas de línea de comandos ofrecen feedback instantáneo. Son cómodas, pero tienden a quedarse atrás respecto a los estándares. Úsalas como primera línea de defensa, nunca como única verificación.

Cómo validar XHTML paso a paso

1. Declara correctamente el DOCTYPE y la codificación

El DOCTYPE determina contra qué reglas se valida. 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>Ejemplo válido</title>
</head>

Dos errores clásicos aquí: olvidar el atributo xmlns (obligatorio en XHTML) y declarar en el meta una codificación que no coincide con la del archivo real. El validador detecta ambos, pero el segundo a veces solo se manifiesta como caracteres corruptos.

2. Comprueba la well-formedness antes que la validez

Antes de pelearte con la DTD, asegúrate de que el XML está bien formado. xmllint --noout archivo.xhtml te lo dirá en segundos. Si falla aquí, ningún validador de DTD te ayudará: primero cierra etiquetas, corrige el anidamiento y escapa entidades (&, <, >).

3. Valida contra la DTD

Con el documento bien formado, pásalo por el W3C Validator o por vnu. Revisa no solo cuántos errores hay, sino de qué tipo. Un único error de anidamiento puede generar una cascada de errores secundarios que desaparecen al corregir el primero.

4. Valida el sitio completo, no solo la home

Un error común es validar la página principal y asumir que el resto está bien. Las plantillas, los componentes y las páginas generadas dinámicamente suelen introducir marcado inválido. Automatiza: recorre las URLs principales con un script y ejecuta vnu sobre cada respuesta.

Relacionado: IAAP CPACC / WAS Certification — La certificación profesional que acredita tu experiencia en accesibilidad..

5. Integra la validación en tu flujo

La validación manual no escala. Añade un paso de validación en tu pipeline (hook de pre-commit, tarea de build o job de CI) que falle si aparece un nuevo error. Así, el marcado inválido nunca llega a producción.

Interpretar los errores: los que verás una y otra vez

• “end tag for X omitted, but OMITTED end tags are not allowed”: típico de <li>, <p> o <td> sin cerrar. En XHTML, todo debe cerrarse.
• “there is no attribute X”: el atributo no existe en tu DTD. Casos habituales: target, name en algunos elementos, atributos data-* en XHTML 1.0 (no en la DTD clásica).
• “element X undefined”: usas un elemento que tu DTD no contempla, a menudo por copiar marcado HTML5 en un documento XHTML 1.0.
• “character data is not allowed here”: contenido de texto donde la DTD espera solo elementos, o un & sin escapar.
• “reference to entity X for which no system identifier could be generated”: entidades HTML con nombre que no están definidas en XML (por ejemplo   sin declarar). En XHTML puro usa   o declara la entidad.

La regla de oro para cómo validar xhtml: corregir de arriba abajo. El primer error suele ser la causa; los siguientes son su consecuencia.

XHTML5: el matiz que cambia las reglas

Si sirves XHTML5 —XHTML serializado según la sintaxis de HTML5—, las reglas cambian. Ya no hay DTD: la conformidad se define en la especificación HTML del WHATWG y en las especificaciones del W3C sobre HTML. El validador correcto es Nu Html Checker, no el validador clásico de DTD.

Si estás de compras: accessiBe — Superposición de IA que promete cumplimiento WCAG en 48 horas.

Diferencias prácticas que conviene tener en cuenta sobre cómo validar xhtml:

• Los atributos data-* son válidos en XHTML5, no en XHTML 1.0.
• El DOCTYPE se simplifica a <!DOCTYPE html>.
• La validación se hace contra el conformance checker de HTML5, que es más permisivo en algunos puntos y más estricto en otros (por ejemplo, en el uso de ciertos elementos obsoletos).

Elegir entre XHTML 1.0 y XHTML5 no es solo técnico: si tu proyecto es nuevo, XHTML5 con validación vnu es el camino sensato. Si mantienes un sistema heredado con DTD, quédate en XHTML 1.0 y valida contra su DTD.

Validación y accesibilidad: dos capas distintas

Un error común es creer que un documento válido es automáticamente accesible. No lo es. La validación comprueba la sintaxis y la conformidad con el esquema; la accesibilidad se evalúa contra las WCAG del W3C, que cubren percepciones, operabilidad y compatibilidad con tecnologías de asistencia.

Dicho esto, hay solapamiento real: el marcado inválido suele implicar una estructura deficiente (encabezados mal anidados, listas rotas, formularios sin etiquetas correctas), y eso sí afecta a la accesibilidad. La estrategia sensata para cómo validar XHTML y otros documentos es validar primero (eliminar el ruido estructural) y auditar la accesibilidad después con herramientas como axe, Lighthouse o revisiones manuales. La validación es una condición necesaria, pero no suficiente.

Errores frecuentes al validar XHTML

Cuando aprendes cómo validar XHTML, evita estos errores comunes:

• Validar solo la home. El marcado problemático suele estar en las plantillas internas.
• Ignorar la codificación. Un charset mal declarado produce errores fantasma.
• Confundir bien formado con válido. Son capas distintas; resuélvelas en orden.
• Usar el validador equivocado. vnu para XHTML5, DTD para XHTML 1.x.
• Corregir errores en cascada sin leer el primero. Pierdes tiempo y arreglas síntomas.
• No automatizar. La validación manual no sobrevive al segundo sprint.
• Asumir que válido = accesible. Son estándares diferentes con propósitos diferentes.

Key Takeaways

• Validar XHTML implica dos capas: well-formedness XML y cumplimiento de la DTD o esquema declarado.
• El W3C Markup Validation Service y Nu Html Checker (vnu) son las herramientas de referencia para cómo validar xhtml; xmllint cubre la capa XML pura.
• Para XHTML 1.0/1.1, usa validación contra DTD; para XHTML5, usa vnu y olvídate de las DTD clásicas.
• Corrige los errores de arriba abajo: el primero suele causar los siguientes.
• Automatiza la validación en tu pipeline; la revisión manual no escala.
• Válido no es sinónimo de accesible: son estándares complementarios, no equivalentes.

Sources & Further Reading

• 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…

Frequently Asked Questions

¿Cuál es la diferencia entre XHTML bien formado y XHTML válido?

Un documento bien formado sigue las reglas sintácticas de XML: etiquetas cerradas, anidamiento correcto y atributos entre comillas. Un documento válido, además, respeta la DTD o el esquema que declara: solo usa elementos y atributos permitidos en su contexto. Puedes tener un documento bien formado pero inválido, por ejemplo si usas un atributo que no existe en XHTML 1.0 Strict.

¿Sigue teniendo sentido validar XHTML en 2024?

Sí, por dos razones. Primero, muchos proyectos heredados siguen sirviendo XHTML y necesitan mantenerse válidos para no romperse en modo XML. Segundo, la validación es una disciplina que detecta errores estructurales que afectan a la accesibilidad y al mantenimiento. Si tu proyecto es nuevo, probablemente use HTML5 o XHTML5, pero el hábito de validar sigue siendo valioso.

¿Qué validador debo usar para XHTML5?

Nu Html Checker (vnu), disponible como servicio web, ejecutable JAR e imagen Docker. Es el mismo motor que usa el moderno W3C Markup Validation Service y entiende la sintaxis HTML5 y su serialización XHTML. No uses validadores clásicos de DTD para XHTML5: no reconocerán los atributos data-* ni otras características de HTML5.

¿Por qué el validador del W3C me da errores que no entiendo?

Porque muchos errores son consecuencia de uno anterior. Un anidamiento incorrecto puede generar decenas de mensajes secundarios. La estrategia correcta es corregir el primer error, validar de nuevo y repetir. También ocurre que el validador aplica la DTD declarada en el DOCTYPE; si esa DTD no es la que esperabas, los errores parecerán arbitrarios.

¿Puedo validar XHTML desde la línea de comandos?

Sí. Si se pregunta cómo validar XHTML a través de CLI, xmllint --noout --valid archivo.xhtml verifica el buen formato y la validez con la DTD. Para HTML5/XHTML5, vnu.jar archivo.xhtml hace lo mismo. Ambas opciones son ideales para la integración en scripts de compilación, hooks de pre-commit o trabajos de integración continua, donde la validación manual no escala.

¿Un sitio XHTML válido es automáticamente accesible?

No. La validación verifica la conformidad sintáctica y de esquema; la accesibilidad se evalúa según las WCAG, que cubren aspectos como el contraste, la navegación por teclado, el texto alternativo o la estructura semántica. Un documento puede ser perfectamente válido y seguir siendo inaccesible. Validar primero y auditar la accesibilidad después: son capas complementarias.