Code valide ne suffit point

Bannières W3C valides

Vous avez tous vu ces labels en bas de page d’accueil avec ces libellés W3C XHTML4 valid ou W3C XHTML1 valid.

L’importance des standards.

Ecrire un code au plus proche des standards définis par le W3C est essentiel pour préserver l’interopérabilité des langages HTML et CSS même si les navigateurs ne les respectent pas toujours.
Dans le cas de l’HTML4, de l’XHTML1 strict ou transitionnel  la version est accompagnée d’un Doctype qui définit intégralement la spécification du langage via une DTD.
Vous trouverez ici les différents Doctypes.

Pour simplifier, le Doctype est en quelque sorte un contrat entre votre code et les navigateurs. En cas de bug côté navigateur, vous pourrez ainsi dire : mon code est valide, c’est la faute à ce foutu navigateur !

Faut-il s’en vanter ?

Les valid banners, même si vous les trouvez laides et que ça fait « petit site perso », ont eu un rôle dans les années 2000 où il fallait faire plier les navigateurs peu standards et donc communiquer sur cette rigueur de code nécessaire. En dehors de cet aspect militant, quel est l’intérêt pour l’utilisateur de votre site ? Va-t-il faire un lien entre son navigateur obsolète et ce jargon de geek ?

Un outil précieux pour le développeur

Le validateur est surtout un outil indispensable pour tester régulièrement l’intégrité de votre code HTML et vérifier les minimas requis pour qu’une page s’affiche proprement comme l’encodage, la bonne imbrication des balises ou encore la bonne syntaxe de balise et d’attributs. Cette vérification fait partie du travail d’intégration HTML. Dans un projet sérieux, on est bien d’accord sur le fait que ces standards doivent être respectés tout au long de la chaîne web, sinon vous risquez une piètre interopérabilité ou des bugs d’affichage inextricables.

Dans le cas de la syndication de contenu via des flux RSS, cet outil va être franchement indispensable pour créer des flux de données à parser sans problème.

Dans la pratique il faudra peut-être que vous fassiez quelques écarts par rapport au standard choisi pour répondre à des besoins d’animations graphiques en JavaScript, le client qui vous oblige à mettre  tel lien en nouvelle fenêtre alors que vous êtes en XHTML1 strict, certes il y a des JavaScript pour contourner cela mais est-ce bien honnête ? La validation de votre code ne doit pas être une finalité, sinon elle risque fort d’être l’arbre qui cache la forêt. Alors sachez discerner les erreurs vraiment bloquantes des écarts volontaires peu impactant car le temps que vous aurez perdu à contourner ces règles vous ne le prendrez pas sur l’amélioration de votre intégration pour les utilisateurs. Votre code doit faire beaucoup plus que de respecter ces standards.

Est-ce un label de qualité ?

Non, mais c’est à partir de ces bonnes bases de syntaxe que l’on peut commencer à travailler sur de la qualité.
Vous pouvez avoir un code valide en XHTML1 strict et une qualité de code abominable. Inversement vous pourrez avoir quelques erreurs mineures d’attributs comme des attributs property sur les balises meta ne touchant pas la restitution et à côté de cela une très bonne qualité de code.

Pas convaincu ?

Vous connaissez les sites proposant des services d’automatisation d’intégration ? Vous leur fournissez un fichier PSD et ils vous en sortent une intégration HTML/CSS plus ou moins automatiquement. Une société russe a créé ce service en 100% automatique et leur grand argument c’est ce fameux valid banner. En effet, j’ai vérifié leurs exemples, ils sont bien valides XHTML1 strict ! Mais si vous y regardez de plus près c’est une vraie catastrophe ou pour être plus concret ce n’est pas du code HTML sémantique ni même utilisable en production. D’ailleurs ils ont retiré leurs exemples de leur site tellement ils avaient honte !
Il y a bien d’autres studios spécialisés dans ce domaine dont un de Las Vegas avec un magnifique work-flow en 10 étapes avec plusieurs contrôles qualité, donc un processus semi-automatique cette fois. Du zéro sémantique on passe à quelque chose d’un peu plus sophistiqué mais en un coup d’œil on s’aperçoit que les blocs sont bloqués en hauteur, les tailles de polices sont en pixels, les labels ne sont pas associés à leurs inputs et enfin que le bouton de validation de formulaire n’en est pas un mais un simple lien :

Aperçu du code d'un prestataire se vantant d'un code 100% valide

Ce code est pourtant bien valide XHTML1 strict.
On pourrait discuter longtemps des lacunes de ces validateurs mais il faut se rappeler des erreurs importantes qu’ils peuvent détecter à votre place :

  • L’absence d’alternative sur les images : que ce soit des images de déco ou porteuse d’information il faut un attribut alt. Pour rappel, dans le cas où l’image est porteuse d’information, on ne laisse pas l’attribut alt vide.
  • Un DOM cassé : une balise pas fermée ou pas là où il faut et la robustesse de votre code est remise en question. Si vous ne corrigez pas cet incident la restitution risque d’être hasardeuse.
  • L’imbrication des balises est conforme au standard : par exemple on n’entoure pas une balise de type block par une balise de type inline en XHTML1.
  • Les problèmes d’encodages incohérents.
  • La syntaxe des attributs de balises incomplète (attributs obligatoires) ou invalide.

En revanche le validateur ne vous obligera pas à :

  • Mettre des alternatives pertinentes là où il faut
  • Mettre un menu dans une liste ul li plutôt que dans un tableau de mise en forme table tr td !
  • Restituer tous les textes en HTML vs images
  • Créer des formulaires vraiment utilisables par tous
  • Eviter les balises de décoration

Cerise sur le gâteau : la validation HTML5

Festival de fausses bannières W3C HTML5 valides

Des valid banners pour l’HTML5.  C’est une pure falsification ! Ces valid banners vont décrédibiliser leurs concepteurs de sites et tout le bien fondé du process de standardisation entamé.

Le validateur HTML5 est basé sur une spécification en cours donc cet outil vous aide à assurer une syntaxe proche de ce standard vivant, mais en aucun cas il garantit que votre code est valide HTML5.

Comme en atteste le document du W3C :

  • L’HTML5 n’est pas encore un standard.  Sa spécification est au statut de brouillon au moins jusqu’en 2014, pour quelques mois.
  • L’HTML5 n’a pas de DTD.

Son validateur s’autoproclame « vivant », c’est-à-dire évoluant. Donc ce qui est  « valide » aujourd’hui ne le sera pas forcément dans un an et inversement.

Si vous voulez vraiment soutenir HTML5 allez-y avec  la bannière appropriée, comme par exemple celle-ci :

logo html5 approprié

En conclusion

Le validateur du W3C est un excellent outil. Ces standards ouverts nous garantissent un internet libre et évite des dérives propriétaires comme c’est le cas actuellement avec les prefixes propriétaires.
CSS3 étant aussi en cours de travail, les navigateurs Web-kit et Gecko prennent les devants en proposant des préfixes propriétaires de type –moz ou –webkit ce qui nous rappelle de bien mauvais souvenirs avec le monopole d’internet Explorer qui était bien trop éloigné des standards.

Des outils et des référentiels permettent d’aller plus loin que cette formalité de validation.
Cette validation ne doit pas être une finalité et en aucun cas elle ne doit vous bloquer ou vous dévier et vous empêcher de travailler sur la qualité de vos pages web.

Le référentiel Accessiweb

Le critère Accessiweb concernant la validité de votre code : 8.2 (bronze)

Les checklists Opquast pour aborder les autres aspects de la qualité web

L’outil Tanaguru pour évaluer partiellement l’accessibilité de votre code

Après cela valid banner ou pas… c’est à vous de vous en justifier !

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *