Standards du Web : comprendre HTML, CSS et la validation
Les standards du Web sont des spécifications partagées qui permettent aux navigateurs, aux outils et aux technologies d’assistance d’interpréter les mêmes documents. Aujourd’hui, HTML décrit la structure et le sens du contenu, tandis que CSS en gère la présentation. Un validateur repère des écarts aux spécifications, mais un résultat sans erreur ne prouve ni l’accessibilité, ni la rapidité, ni la qualité d’usage.
Sommaire
Pour vérifier une page, contrôlez son HTML avec Nu Html Checker, son CSS avec le validateur CSS du W3C, puis complétez le contrôle par une lecture au clavier et un essai de zoom. Cette séparation évite de demander à un seul outil une réponse qu’il ne peut pas fournir.
Ce que recouvrent les standards du Web
Un standard est une règle publiée pour que des logiciels différents puissent traiter un même document de façon prévisible. Le HTML organise les titres, les paragraphes, les liens, les formulaires et le sens des blocs. Le CSS décrit l’apparence, les dimensions et la disposition. HTTP transporte la ressource, et les URL permettent de la retrouver. Les règles d’accessibilité, notamment les WCAG, ajoutent des exigences sur la perception, l’utilisation et la compréhension du contenu.
Ces domaines se répondent sans se confondre. Une URL stable ne rend pas un formulaire compréhensible. Une feuille CSS valide ne garantit pas un contraste suffisant. Un HTML bien structuré aide une technologie d’assistance, mais il faut encore vérifier le texte, le clavier et le comportement réel de l’interface.
Le HTML courant est le HTML Living Standard maintenu par WHATWG. Le W3C publie et maintient de son côté des spécifications CSS, des recommandations d’accessibilité et d’autres standards. Les organismes et les documents changent, mais le besoin reste le même : réduire les interprétations propres à un navigateur ou à un fournisseur.
Un standard commun réduit les interprétations propres à un navigateur ou à un fournisseur, mais il n’élimine pas le besoin de tester le résultat.
Pourquoi XHTML et les badges "valide" comptaient en 2005
XHTML 1.0 reformulait HTML 4 en XML 1.0. Le document devait être bien formé : balises fermées, noms en minuscules et attributs entre guillemets. Cette discipline rendait visibles des erreurs que les navigateurs toléraient parfois. La recommandation XHTML 1.0 du W3C est aujourd’hui superseded, c’est-à-dire remplacée pour les nouveaux développements par les spécifications HTML actuelles.
L’ancien CyberSDF déclarait XHTML 1.0 Strict et CSS2 dans son pied de page, avec deux badges liés aux validateurs. Ces images témoignaient d’une pratique de l’époque, elles ne constituaient pas un certificat permanent du site. Une validation correspond toujours à une spécification, une version et un document précis.
Le billet du 25 mars 2005, signé Laurent, critiquait les agences qui reproduisaient sur le Web les méthodes de la mise en page papier : tableaux utilisés comme cadres, images décoratives placées au pixel près et optimisations pour un navigateur ou une résolution unique. Son idée utile aujourd’hui tient dans la séparation entre la structure et la présentation, qui facilite l’évolution d’une interface. Elle ne transforme pas XHTML 1.0 en choix actuel.
Le standard HTML vivant décrit aussi une syntaxe XML, mais la section The XML syntax ne la recommande pas pour commencer de nouveaux documents HTML. Le choix actuel est donc plus simple : écrire du HTML conforme à la spécification courante, puis vérifier le résultat dans les environnements qui comptent.
XHTML 1.0 aide à comprendre l’histoire de la conformité, mais ce n’est plus le choix recommandé pour commencer un site HTML.
Ce que signifie vraiment un HTML ou un CSS valide
Un validateur compare un document aux exigences déterministes d’une spécification et signale les écarts qu’il sait reconnaître. Il peut repérer un identifiant utilisé deux fois, une image sans attribut alt ou une valeur CSS inconnue. Il ne peut pas comprendre seul si le texte de l’alternative décrit correctement l’image, si le contraste reste lisible ou si un parcours est clair.
Le validateur CSS sépare les erreurs des avertissements. Une erreur signifie que la déclaration ne respecte pas la grammaire ou les valeurs attendues. Un avertissement attire l’attention sur un cas qui mérite une vérification, sans être nécessairement une invalidité. Cette différence compte dans un cahier des charges : demandez le rapport complet et le traitement des erreurs, pas seulement une image verte.
La validité répond à la question "le code respecte-t-il les règles vérifiables de la spécification ?", pas à la question "le site est-il bon pour tous ses utilisateurs ?".
Vérifier une page avec les outils actuels
Les deux validateurs acceptent généralement une URL publique, un fichier chargé ou du code collé. Une URL mesure la ressource servie, tandis qu’un fichier permet d’isoler une modification. Un collage est pratique pour un fragment. Dans les deux derniers cas, retirez les données privées : le contenu envoyé à un service en ligne quitte votre machine.
Le 16 septembre 2026, quatre fichiers courts ont été contrôlés par requête HTTP directe, sans navigateur ni extension. Le HTML a été envoyé à https://validator.w3.org/nu/?out=json avec l’en-tête Content-Type: text/html; charset=utf-8. Le CSS a été envoyé à https://jigsaw.w3.org/css-validator/validator avec output=json. Les fichiers valides et leurs variantes fautives ont suivi les mêmes appels.
curl -H 'Content-Type: text/html; charset=utf-8' \
--data-binary @test-html-valide.html \
'https://validator.w3.org/nu/?out=json'
curl --get --data-urlencode text@test-css-valide.css \
--data 'output=json' \
'https://jigsaw.w3.org/css-validator/validator'Le fichier HTML avec un attribut lang, un titre, un H1 et une image avec alternative a produit 0 message avec Nu Html Checker, version retournée 26.9.16. Sa variante avec une image sans alt et deux fois id="contenu" a produit 2 erreurs et 1 information : l’alternative absente, l’identifiant dupliqué et l’emplacement de la première occurrence.
La feuille CSS contenant color: #222 et background-color: #fff a été déclarée valide, avec 0 erreur et 0 avertissement, sur le profil retourné css3. La variante contenant color: not-a-color a produit 1 erreur et 0 avertissement. Ces quatre résultats décrivent le comportement observé sur ces entrées, pas un score de qualité de site.
Corrigez d’abord la première erreur qui désorganise le document, puis relancez le contrôle. Une balise mal fermée peut provoquer une série de messages secondaires ; les traiter dans l’ordre d’apparition évite de corriger des symptômes.
Un test utile conserve l’entrée exacte, la version du service et le résultat, afin que la correction puisse être rejouée.
Lire le résultat sans confondre conformité et accessibilité
Nu Html Checker détecte l’absence de l’attribut alt, mais il ne juge pas si une alternative comme "image" transmet l’information utile. Le validateur CSS détecte une valeur impossible, mais il ne juge pas seul le contraste, le reflow à 200 %, le focus clavier ou la compréhension d’une interface.
Le W3C rappelle dans son aperçu de l’évaluation de l’accessibilité qu’aucun outil seul ne détermine la conformité complète d’un site. Un ordre de contrôle raisonnable commence par le code, continue avec le clavier et le zoom, vérifie les alternatives textuelles, puis observe la lecture avec une technologie d’assistance lorsque le besoin le justifie.
La validation automatisée élimine des erreurs déterministes ; l’accessibilité exige aussi une évaluation humaine compétente.
Ce qu’un cahier des charges doit demander à une agence
Demandez d’abord la spécification visée : HTML courant, profil CSS, version d’un composant ou exigence interne clairement nommée. Ajoutez ensuite un contrôle reproductible, l’entrée contrôlée, les erreurs attendues et la façon dont elles seront corrigées. Une capture de badge ne remplace pas ces éléments.
Le cahier des charges peut aussi exiger une structure HTML sémantique, une présentation CSS maintenable et des URL stables ou redirigées proprement. Précisez les navigateurs et appareils effectivement vérifiés, les conditions de maintenance et la responsabilité de correction après livraison. Pour l’accessibilité, demandez des tests au clavier, au zoom et avec les technologies utiles, sans réduire la demande à un score automatique.
Le billet de Laurent en 2005 reste pertinent sur un point : une interface dépendante d’une seule résolution ou d’un seul navigateur vieillit mal. Les techniques ont changé, mais le critère se vérifie encore en demandant des environnements nommés et un résultat observable.
Pour replacer ces exigences dans une décision plus large, consultez les critères pour choisir un logiciel avec des critères vérifiables. Et pour relier la validation à l’entretien d’un ensemble de ressources, retrouvez les logiciels utiles à comprendre et à choisir.
Une promesse de conformité n’est vérifiable que si le prestataire nomme la spécification, l’outil, le périmètre testé et le traitement des erreurs.