Comment valider le xhtml ?

Comment valider XHTML, c’est vérifier qu’un document respecte deux couches de règles : la syntaxe XML et sa DTD ou schéma déclaré. XHTML 1.0 est une reformulation de HTML 4.01 en XML, donc un document peut être bien formé mais invalide, comme lorsque <a target="_blank"> apparaît dans XHTML 1.0 Strict.

Valider XHTML, c’est vérifier qu’un document respecte simultanément deux couches de règles :

1. Règles de syntaxe XML : balises correctement imbriquées, attributs entre guillemets, fermeture obligatoire de tous les éléments (y compris les vides comme <br />), un seul élément racine, un encodage déclaré cohérent, etc.
2. Règles DTD ou schéma déclaré : quels éléments et attributs existent, dans quel contexte ils peuvent apparaître et quelles valeurs sont autorisées. Voici les DTD classiques de XHTML 1.0 (Strict, Transitional, Frameset), XHTML 1.1, XHTML Basic et XHTML Modularization.

Un document peut être du XML bien formé et néanmoins invalide : par exemple, si vous utilisez <a target="_blank"> dans XHTML 1.0 Strict, la syntaxe est impeccable mais l’attribut target n’existe pas dans cette DTD. Cette distinction entre bien formé et valide est la première cause de confusion lorsque quelqu’un voit une erreur et ne comprend pas pourquoi.

Il convient également de rappeler que XHTML 1.0 est une reformulation du HTML 4.01 en XML, défini par le W3C. Aujourd’hui, sa valeur pratique est double : il sert pour les projets existants qui sont toujours utilisés comme application/xhtml+xml ou text/html, et il sert de discipline mentale pour écrire un balisage propre. Si vous souhaitez connaître le contexte normatif complet sur la manière de valider XHTML, la spécification de XHTML 1.0 du W3C est la source principale.

Les validateurs qui valent la peine (et quand utiliser chacun d’eux)

Il n’existe pas un seul validateur « correct ». Le choix dépend si vous validez un fragment, une page de production, un site entier ou un document déjà XHTML5.

Outils	Ce qu’il valide	Idéal pour	Limitation principale
Service de validation du balisage W3C (validator.w3.org)	XHTML 1.0/1.1, HTML4, HTML5	Validation ponctuelle par URL, fichier ou saisie directe	Le “Nouveau Html Checker” donne la priorité à HTML5 ; les anciennes DTD nécessitent une sélection manuelle
Nu Html Checker (vnu)	HTML5 et XHTML5	Nouveaux projets, validation locale et en CI	Ne valide pas les DTD classiques de XHTML 1.x
Validateurs locaux (vnu.jar, tidy)	Selon la configuration	Automatisation, pré-engagement, pipelines	Nécessite d’installer Java ou les binaires ; configuration initiale
xmllint	XML de bonne formation et validation par rapport à DTD/XSD	Vérifier la couche XML pure	Ne connaît pas les règles spécifiques au HTML au-delà du schéma
Extensions de navigateur / IDE	Balisage en direct	Retour immédiat pendant l’écriture	Utilisent souvent des moteurs obsolètes ou incomplets

Le Service de validation du balisage du W3C

Cela reste le point de départ pour ceux qui se demandent comment valider XHTML. Il prend en charge trois modes : Valider par URI, Valider par téléchargement de fichier et Valider par entrée directe. Pour le XHTML classique, l’astuce est dans la liste déroulante Type de document : si votre document déclare sa propre DTD via le DOCTYPE, le validateur la respecte ; sinon, vous devez le forcer manuellement.

Connexes : UserWay — Widget d'accessibilité avec plan gratuit pour gagner aujourd'hui.

Un détail que beaucoup ignorent : le validateur W3C moderne s’appuie sur le Nu Html Checker, qui comprend HTML5 et XHTML5 mais traite les anciennes DTD avec moins de priorité. Pour XHTML 1.0 Strict cela fonctionne toujours, mais il est conseillé de vérifier que le résultat reflète la DTD que vous attendez et non une interprétation laxiste.

Vérificateur HTML Nu (vnu)

Il s’agit du validateur que le W3C lui-même utilise en interne. Il existe en tant que service Web, en tant qu’exécutable JAR et en tant qu’image Docker. Son gros avantage est que vous pouvez l’exécuter localement et en intégration continue, ce qui est essentiel si vous maintenez un grand site. Pour XHTML servi comme application/xhtml+xml, vnu détecte les erreurs d’imbrication et d’attribut qu’un validateur HTML tolérant laisserait passer.

xmllint

Si votre préoccupation concerne la couche XML pure — par exemple, parce que vous générez du XHTML à partir de modèles XSLT — alors xmllint est irremplaçable. Avec --noout --valid documento.xhtml, il vérifie la bonne forme et la validité par rapport à la DTD référencée. C’est rapide, scriptable et ne dépend pas du réseau.

Ça vaut le coup d'oeil : AudioEye — Accessibilité gérée : automatisation combinée avec révision humaine.

Validation dans l’éditeur

Les extensions pour VS Code, les plugins IDE et les outils de ligne de commande offrent un retour instantané. Ils sont pratiques, mais ont tendance à être en retard par rapport aux normes. Utilisez-les comme première ligne de défense, jamais comme seule vérification.

Comment valider XHTML étape par étape

1. Déclarez correctement le DOCTYPE et la codification

Le DOCTYPE détermine par rapport quelles règles il est validé. Pour 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>Exemple valide</title>
</head>

Deux erreurs classiques ici : oublier l’attribut xmlns (obligatoire en XHTML) et déclarer un codage dans la meta qui ne coïncide pas avec le fichier réel. Le validateur détecte les deux, mais le second n’apparaît parfois que sous forme de caractères corrompus.

2. Vérifiez la bonne formation avant de la valider

Avant de vous battre avec la DTD, assurez-vous que le XML est bien formé. xmllint --noout archivo.xhtml vous le dira en quelques secondes. Si cela échoue ici, aucun validateur DTD ne vous aidera : fermez d’abord les balises, corrigez l’imbrication et les entités d’échappement (&, <, >).

3. Valider contre la DTD

Avec le document bien formé, transmettez-le via le W3C Validator ou vnu. Examinez non seulement combien d’erreurs il y a, mais de quel type. Une seule erreur d’imbrication peut générer une cascade d’erreurs secondaires qui disparaissent une fois la première corrigée.

4. Validez le site complet, pas seulement la page d’accueil

Une erreur courante consiste à valider la page principale et à supposer que le reste est bon. Les modèles, composants et pages générées dynamiquement introduisent souvent un balisage non valide. Automatiser : parcourez les URL principales avec un script et exécutez vnu sur chaque réponse.

Connexes : IAAP CPACC / WAS Certification — La certification professionnelle qui accrédite votre expérience en accessibilité.

5. Intégrez la validation à votre flux

La validation manuelle n’est pas évolutive. Ajoutez une étape de validation dans votre pipeline (hook de pré-commit, tâche de build ou tâche CI) qui échoue si une nouvelle erreur apparaît. De cette façon, les balises non valides n’atteignent jamais la production.

Interpréter les erreurs : ceux que vous verrez encore et encore

• “balise de fin pour X omise, mais les balises de fin OMITÉES ne sont pas autorisées” : typique de <li>, <p> ou <td> sans fermeture. En XHTML, tout doit être fermé.
• “il n’y a pas d’attribut X” : l’attribut n’existe pas dans votre DTD. Cas habituels : target, name dans certains éléments, attributs data-* dans XHTML 1.0 (pas dans la DTD classique).
• “élément X non défini” : utilise un élément que votre DTD ne prend pas en compte, souvent issu de la copie d’un balisage HTML5 dans un document XHTML 1.0.
• “les données de caractères ne sont pas autorisées ici” : contenu texte où la DTD n’attend que des éléments, ou un & sans échappement.
• “référence à l’entité X pour laquelle aucun identifiant système n’a pu être généré” : entités HTML nommées qui ne sont pas définies en XML (par exemple   sans déclarer). En XHTML pur, utilisez   ou déclarez l’entité.

La règle d’or pour valider le xhtml : corriger de haut en bas. La première erreur en est généralement la cause ; voici sa conséquence.

XHTML5 : la nuance qui change les règles

Si vous diffusez du XHTML5 —XHTML sérialisé selon la syntaxe HTML5—, les règles changent. Il n’y a plus de DTD : la conformité est définie dans la spécification HTML WHATWG et les spécifications W3C sur HTML. Le validateur correct est Nu Html Checker, pas le validateur DTD classique.

Si vous faites du shopping : accessiBe — Superposición de IA qui promet d’obtenir les WCAG dans 48 heures.

Différences pratiques à prendre en compte concernant la façon de valider xhtml :

• Les attributs data-* sont valides en XHTML5, pas en XHTML 1.0.
• Le DOCTYPE est simplifié en <!DOCTYPE html>.
• La validation se fait par rapport au vérificateur de conformité de HTML5, qui est plus autorisé sur certains points et plus strict sur d’autres (par exemple, dans l’utilisation de certains éléments obsolètes).

Choisir entre XHTML 1.0 et XHTML5 n’est pas seulement technique : si votre projet est nouveau, XHTML5 avec validation vnu est la voie raisonnable. Si vous conservez un système existant avec DTD, restez dans XHTML 1.0 et validez par rapport à sa DTD.

Validation et accessibilité : deux couches distinctes

Une erreur courante consiste à croire qu’un document valide est automatiquement accessible. Ce n’est pas. La validation vérifie la syntaxe et la conformité du schéma ; l’accessibilité est évaluée par rapport aux WCAG del W3C, qui couvrent les perceptions, l’opérabilité et la compatibilité avec les technologies d’assistance.

Cela dit, il existe un véritable chevauchement : un balisage invalide implique généralement une structure déficiente (titres mal imbriqués, listes brisées, formulaires sans étiquettes correctes), ce qui affecte l’accessibilité. La stratégie judicieuse pour valider XHTML et d’autres documents consiste à valider d’abord (éliminer le bruit structurel) et à vérifier l’accessibilité après avec des outils comme Axe, Lighthouse ou des révisions manuelles. La validation est une condition nécessaire mais pas suffisante.

Erreurs fréquentes lors de la validation XHTML

Lorsque vous apprenez à valider XHTML, évitez ces erreurs courantes :

• Valider uniquement la page d’accueil. Le balisage problématique concerne généralement les modèles internes.
• Ignorer l’encodage. Un charset mal déclaré produit des erreurs fantômes.
• Confondre bien formé et valide. Ce sont des couches distinctes ; résolvez-les dans l’ordre.
• Utilisez le mauvais validateur. vnu pour XHTML5, DTD pour XHTML 1.x.
• Corrigez les erreurs en cascade sans lire la première. Vous perdez du temps et corrigez les symptômes.
• Pas d’automatisation. La validation manuelle ne survit pas au deuxième sprint.
• En supposant que valide = accessible. Il s’agit de normes différentes avec des objectifs différents.

Points clés à retenir

• La validation du XHTML implique deux couches : bien formé XML et conformité à la DTD ou au schéma déclaré.
• Le W3C Markup Validation Service et Nu Html Checker (vnu) sont les outils de référence pour savoir comment valider le xhtml ; xmllint couvre la couche XML pure.
• Pour XHTML 1.0/1.1, utilisez la validation par rapport à la DTD ; pour XHTML5, utilisez vnu et oubliez les DTD classiques.
• Corrigez les erreurs de haut en bas : la première provoque généralement ce qui suit.
• Automatisez la validation dans votre pipeline ; la révision manuelle n’est pas mise à l’échelle.
• Valide n’est pas synonyme d’accessible : ce sont des normes complémentaires et non équivalentes.

Sources et lectures complémentaires

• XHTML — Wikipédia : Le langage de balisage hypertexte extensible (XHTML) fait partie de la famille des langages de balisage XML qui reflète ou étend les versions du balisage hypertexte largement utilisé…
• XHTML Basic — Wikipédia : XHTML Basic est un langage de balisage basé sur XML conçu pour les agents utilisateurs simples dotés d’une puissance de calcul limitée, tels que les premiers téléphones mobiles, PDA, pagers et décodeurs…

Questions fréquemment posées

Quelle est la différence entre XHTML bien formé et XHTML valide ?

Un document bien formé suit les règles syntaxiques de XML : balises fermées, imbrication correcte et attributs entre guillemets. De plus, un document valide respecte la DTD ou le schéma qu’il déclare : en utilisant uniquement les éléments et attributs autorisés dans son contexte. Vous pouvez avoir un document bien formé mais invalide, par exemple si vous utilisez un attribut qui n’existe pas en XHTML 1.0 Strict.

Vous avez envie de valider XHTML en 2024 ?

Oui, pour deux raisons. Premièrement, de nombreux projets existants continuent de servir du XHTML et doivent rester valides pour ne pas interrompre le mode XML. Deuxièmement, la validation est une discipline qui détecte les erreurs structurelles qui affectent l’accessibilité et la maintenance. Si votre projet est nouveau, il utilise probablement HTML5 ou XHTML5, mais l’habitude de valider reste toujours précieuse.

¿Qué le validateur doit-il utiliser pour XHTML5 ?

Nu Html Checker (vnu), disponible sous forme de service Web, JAR exécutable et image Docker. Il s’agit du même moteur que celui utilisé par le service de validation de balisage W3C moderne et qui comprend la syntaxe HTML5 et sa sérialisation XHTML. N’utilisez pas les validateurs DTD classiques pour XHTML5 : ils ne reconnaîtront pas les attributs data-* ou d’autres fonctionnalités HTML5.

¿Pourquoi le validateur du W3C m’a-t-il causé des erreurs qui ne sont pas autorisées ?

Car de nombreuses erreurs sont la conséquence d’une précédente. Une imbrication incorrecte peut générer des dizaines de messages secondaires. La bonne stratégie consiste à corriger la première erreur, à valider à nouveau et à répéter. Il arrive aussi que le validateur applique la DTD déclarée dans le DOCTYPE ; si cette DTD ne correspond pas à ce que vous attendiez, les erreurs sembleront arbitraires.

Pouvez-vous valider XHTML à partir de la ligne de commande ?

Oui. Si vous vous demandez comment valider XHTML via CLI, xmllint --noout --valid archivo.xhtml vérifie le bien-formé et la validité par rapport à la DTD. Pour HTML5/XHTML5, vnu.jar archivo.xhtml fait la même chose. Les deux options sont idéales pour l’intégration dans des scripts de build, des hooks de pré-commit ou des tâches d’intégration continue, où la validation manuelle n’est pas viable à grande échelle.

Un site XHTML valide est-il automatiquement accessible ?

Non. La validation vérifie la conformité syntaxique et schématique ; l’accessibilité est évaluée par rapport aux WCAG, qui couvrent des aspects tels que le contraste, la navigation au clavier, le texte alternatif ou la structure sémantique. Un document peut être parfaitement valide tout en restant inaccessible. Validez d’abord et auditez l’accessibilité après : ce sont des couches complémentaires.