Note du traducteur

Mon site Web est aux normes ! Et le vôtre ?

Statut

Cet article est une production du groupe d'intérêts Assurance Qualité du W3C. Veuillez adresser vos remarques à la liste de diffusion public-evangelist@w3.org dont les archives sont publiques ou, pour un commentaire privé, à karl@w3.org. L'auteur remercie les personnes qui l'ont passé en revue ou y ont contribué par leurs idées.

Introduction

Vous trouverez ici des techniques et des idées permettant sans peine d'améliorer la qualité de votre site Web et de le rendre valide. Ce document est destiné aux utilisateurs de HTML, aux développeurs travaillant sur des applications pour le Web et aux webmestres.

La plupart des sites Web ne sont pas valides. On peut estimer que 99 % des pages Web sont dans une telle situation bien qu'aucune statistique ne permette de le confirmer. Il serait d'ailleurs intéressant de réaliser un sondage pour vérifier que c'est bien le cas.

Pourquoi ?

HTML et normes

Les commentaires habituels

J'ai entendu de nombreux commentaires et propos véhéments sur ce sujet. La plupart d'entre eux sont souvent la marque d'une méconnaissance et d'une compréhension insuffisante de ce que représente la validation HTML. En voici quelques-uns :

  1. Steve (Directeur Général) : Si mon site Web est fabriqué selon les normes, il sera insipide et on perdra des clients.

    Les normes du Web permettent de faire des sites Web sensationnels. La création d'un site Web respectant les normes n'a rien à voir avec la génération de pages Web uniquement textuelles.

    Le W3C propose maintenant un ensemble de technologies intégrées très impressionnantes. On peut faire l'expérience d'un site Web multimédia dans sa totalité avec les technologies interopérables existantes du W3C en recourant aux langages XHTML (balisage XML structuré), CSS (feuilles de style), SVG (graphiques vectoriels animés en deux dimensions) et SMIL (multimédias synchronisés). Ces technologies sont les fruits des consensus auxquels sont parvenus les divers acteurs sur le marché du Web.

  2. Alan (Directeur Technique) : Je n'ai pas les ressources financières nécessaires pour me préoccuper de normes sur mon site Web. Ça me coûtera trop cher !

    Une conception respectueuse des normes simplifiera la maintenance du code du site Web car vous n'aurez plus à proposer des versions différentes selon les divers navigateurs. Vos pages auront une durée de vie plus grande et ne dépendront plus de technologies éphémères. Donc une conception tenant compte des normes du Web reviendra finalement moins cher.

  3. Dean (Directeur Artistique) : Si je respecte les normes, ma créativité en pâtira.

    Les contraintes techniques sont inhérentes à tous les supports artistiques, que vous dessiniez, sculptiez ou conceviez des pages Web. L'aquarelle ou la peinture à l'huile ont leurs propres contraintes, pourtant ces techniques ne bloquent pas la créativité et elles définissent plutôt le cadre dans lequel s'exprime cette créativité.

    La création selon les normes du Web dévoilera un monde nouveau avec les techniques adaptées à un média, une technologie et un public. Il y a encore beaucoup à découvrir dans ce domaine. Nous commençons tout juste à réaliser les avantages des expériences multimédias s'appuyant sur les normes.

  4. Claudia (Graphiste) : L'accessibilité ne m'intéresse pas. Les personnes invalides ne font pas partie de mon public cible.

    Une conception tenant compte de l'accessibilité vous profitera. Les personnes invalides représentent 8 à 10% de l'ensemble de la population. Il est plus facile d'entretenir un site web qui respectent les directives pour l'accessibilité (et donc les normes du Web). La fréquentation de votre site Web verra une augmentation et une gamme élargie de navigateurs pourra accéder au contenu du site.

    Les règlements de certains pays imposent l'accessibilité comme l'Australie (Notes consultatives de la Loi de discrimination de l'invalidité, version 3.1 de mai 1999) ou les États-Unis d'Amérique (Section 508 Informations et applications Web sur un intranet ou Internet), ou encore l'Europe qui travaille à un objectif similaire (accessibilité électronique).

  5. Aminata (Développeur Web) : Pourquoi devrais-je respecter les normes ? Le Web est un espace de liberté.

    Le Web est un espace de liberté partagé par de nombreux utilisateurs dont les besoins ne sont pas forcément connus. Les normes ont été conçues en tenant compte de tous les publics potentiels. La création en respectant les normes est un défi adressé à la communauté du Web. Vous ne serez prisonnier d'aucune entreprise ou technologie propriétaire. Vous pouvez utiliser des technologies qui sont indépendantes des contraintes des plates-formes.

  6. Karl (Développeur Web) : Je n'ai fait que suivre les instructions trouvées dans des livres.

    Malheureusement, trop de livres enseignent une mauvaise programmation Web. Lorsque vous créez un site Web, vous devez vérifier l'exactitude de votre balisage. Si vous développez pour le Web, soyez vigilant lorsque vous vous servez de livres pour développer votre application : lisez les spécifications particulières que vous essayez de mettre en œuvre.

    Certains sites Web rassemblent une documentation utile pour aider les personnes à concevoir des projets conformément aux normes du W3C. Le site Web du W3C tient une liste croissante de tutoriels encourageant les bons usages.

    Certains membres du W3C ont développé des logiciels libres que vous pouvez utiliser. Nous vous encourageons à y recourir autant que possible. Ces suites logicielles mettent en œuvre les technologies du W3C.

  7. Tim (Comptable) : Mon outil d'édition Web produit du balisage invalide.

    Beaucoup d'outils d'édition génèrent un balisage invalide. Quelques-uns intègrent des vérificateurs de syntaxe, d'autres font ce qu'il convient mais beaucoup d'entre eux ne génèrent pas un balisage valide. Comme solution intermédiaire, vous devez vérifier votre page Web à l'aide d'un validateur HTML. Par la même occasion, contactez l'éditeur du logiciel (par courrier électronique, téléphone, lettre) pour l'avertir de cette situation. Les éditeurs prendront les mesures nécessaires si vous leur demandez de le faire.

  8. Valérie (Développeur de contenu pour le Web) : Je n'y suis pour rien. C'est à cause du moteur de gabarits (souvent un système ayant une interface Web).

    Vous avez raison. Souvent ce n'est pas de votre faute. S'il s'agit d'un formulaire simple dans lequel vous n'écrivez jamais de code HTML à la main, dites le au développeur de l'interface ou à la personne chargée de l'entretien du site jusqu'à ce que le problème soit résolu. Si vous n'êtes pas sûr de la conformité du contenu produit vis-à-vis des normes du W3C, effectuez une validation du contenu à l'aide du validateur HTML et transmettez le rapport obtenu à votre webmestre ou à la personne responsable du système de gestion de contenu.

  9. Ning (Développeur de logiciels) : Je ne dispose d'aucune information qui puisse m'aider. Toutes les documentations que j'ai pu trouver sont en anglais.

    Quelques personnes ont traduit des documents et des spécifications en d'autres langues. Le W3C tient une liste des traductions.

HTML est une norme (tout comme XHTML !)

Le langage HTML a poursuivi son évolution au cours des développements et il en existe plusieurs versions. Toutes ces versions constituent des normes et vous pouvez sélectionner celle qui convient à vos besoins. La dernière version représentera la plupart du temps le meilleurs choix, à moins que vous ne visiez un public très particulier ou des navigateurs approximatifs plus anciens. La version que vous choisirez déterminera les éléments et les attributs que vous pourrez utiliser.

Par exemple, dans HTML 4.01, vous avez la liste des éléments et la liste des attributs admis dans vos pages. Vous pouvez éditer vos pages manuellement, ce que l'on désigne habituellement par les expression codage à la main ou écriture de la source.

La version HTML 4.01 vous permet d'écrire un paragraphe et un identificateur d'ancre vers le paragraphe suivant comme ceci :

<p id="ref">Voici un paragraphe</p>

Faites attention à l'imbrication de vos éléments. Certains éléments ne peuvent pas être contenus par d'autres, et certains attributs n'appartiennent qu'à certains éléments.

Les éléments que vous pouvez placer dans votre document ou mettre en œuvre dans votre logiciel dépendent de la version HTML. Ce tableau contient une liste des définitions HTML, ou types de document (DOCTYPE), que vous pouvez employer :

Version Liste des DTD Déclaration DOCTYPE dans les documents
HTML 2.0 DTD
<!DOCTYPE html PUBLIC "-//IETF//DTD HTML 2.0//EN">
HTML 3.2 DTD
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
HTML 4.01 Strict, Transitional, Frameset
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
   "http://www.w3.org/TR/html4/strict.dtd">
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
   "http://www.w3.org/TR/html4/loose.dtd">
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Frameset//EN"
   "http://www.w3.org/TR/html4/frameset.dtd">
XHTML 1.0 Strict, Transitional, Frameset
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
   "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
   "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Frameset//EN"
   "http://www.w3.org/TR/xhtml1/DTD/xhtml1-frameset.dtd">
XHTML 1.1 DTD
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" 
   "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">

Vous ne pourrez pas valider votre document si vous n'employez pas l'un de ces DOCTYPE au début de votre document. Ne l'oubliez pas quand vous écrivez vos documents à la main.

Outils de création HTML
Tous les outils de création HTML doivent proposer un DOCTYPE et générer le balisage conformément au langage.
Gabarit HTML
Tous les gabarits HTML doivent avoir un DOCTYPE.
Bibliothèque ou moteur de gabarits HTML (côté serveur)
Les bibliothèques ou les moteurs de gabarits HTML doivent tous renvoyer un DOCTYPE.

Voici un exemple de gabarit de document XHTML 1.0 Strict :

<?xml version="1.0" encoding="utf-8"?>
<!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="fr" lang="fr">

<head>
    <title>Un gabarit à la norme XHTML 1.0 Strict</title>
    <meta http-equiv="content-type" content="text/html; charset=utf-8" />
    <meta http-equiv="Content-Style-Type" content="text/css" />
</head>

<body>

    ... Votre contenu HTML ...

</body>
</html>

Un gabarit XHTML Strict est très simple à fabriquer. Les modifications et validations des documents sont faciles et directes.

La validation des documents

La validation HTML

Un validateur HTML vérifie simplement l'exactitude de votre document par rapport au DOCTYPE déclaré.

Si on souhaite vérifier la validité du document final lors de sa restitution par l'agent utilisateur (par exemple, un navigateur Web), on peut se servir du validateur HTML du W3C. Le validateur HTML renverra une liste des erreurs vis-à-vis du DOCTYPE HTML choisi. Si le document ne comporte aucune erreur, il renverra le message de résultat Validation passée [ndt. Passed validation].

Si vous éditez votre site Web à l'aide de formulaires (et que vous n'y utilisez aucune balise HTML), vous pouvez signaler les erreurs au webmestre de votre site et lui demander de corriger le générateur de balisage HTML.

Si vous créez votre site Web à la main ou composez directement le code de balisage, et que le validateur signale des erreurs sur votre page, corrigez simplement le balisage. Le validateur HTML vous indique le numéro de la ligne à laquelle l'erreur se trouve.

Comme le validateur HTML indique la ligne où l'erreur apparaît, vous situerez donc facilement le problème dans votre document. Le validateur vérifie le fichier ligne par ligne en commençant par la première ligne. Une erreur au début du document est donc susceptible de provoquer d'autres erreurs dans la suite de votre page. Une bonne méthode pour résoudre les erreurs consiste à corriger la première erreur affichée puis à valider à nouveau la page. Vous constaterez souvent qu'un problème résolu tôt dans le document résoudra plusieurs erreurs en même temps. Répétez cette opération jusqu'à ce que toutes les erreurs soient corrigées et le document résultant sera valide.

Si vous utilisez un outil de création HTML et que vos pages ne sont pas valides après édition, veuillez signaler ce fait au développeur ou à l'éditeur du logiciel. Vous devriez pouvoir contacter les personnes responsables du support technique de la société.

Si vous êtes le développeur d'un moteur de gabarits, d'un outil de création ou d'un système de gestion de contenu, servez-vous du validateur HTML pour corriger les problèmes dans votre mise en œuvre. Vous pouvez aussi incorporer le validateur HTML dans votre logiciel ou votre ordinateur principal. Le code source du validateur HTML est en accès libre. Le validateur est continuellement amélioré et on peut participer à son développement.

Remarque : Certains documents peuvent être valides vis-à-vis d'un DTD et pourtant invalides vis-à-vis de la spécification HTML. Dans un futur proche, nous présenterons une liste des erreurs possibles qui ne sont pas détectées par le validateur HTML.

Liste des validateurs HTML :

La validation des liens

Un autre problème important concernant beaucoup de sites Web tient à la permanence des adresses URI. Lorsque vous ajoutez dans vos documents des liens vers d'autres sites Web, vous entendez que ces liens restent stables et permanents. C'est-à-dire que les informations que vous voulez mettre en avant existeront toujours quand quelqu'un cliquera sur les liens qui auront été fournis. Vous voudrez également vérifier et garantir que les liens menant vers d'autres pages Web ou vers d'autres sections de votre site Web ne comportent aucune erreur. Un outil a été développé dans ce but : le vérificateur de liens du W3C.

Le vérificateur de liens génère un état des liens. La longueur du l'état dépend du temps mis pour rechercher et vérifier tous les liens contenus dans la page. Pour vérifier un lien, le programme envoie une requête HTTP HEAD pour le document. Si le serveur est mal configuré, vous aurez un état erroné, même si le lien est bon, simplement parce que le serveur sera incapable de répondre à une requête HEAD. Auquel cas, il faudra demander au webmestre du site Web de revoir la configuration du serveur.

    Checking link http://webstandards.org/
    HEAD http://webstandards.org/  fetched in 0.1s

Un exemple de liste de liens précède. Le temps mis pour obtenir [ndt. fetch] la ressource désignée par le lien est indiqué.

Après la liste des liens, on obtient l'état des liens cassés ou redirigés qui permet de corriger les liens erronés.

Si vous souhaitez d'autres informations au sujet de l'importance des liens, nous vous invitons à lire le document Les adresses URI sympas ne changent pas écrit par Tim Berners-Lee.

Si, en tant que webmestre, vous souhaitez intaller le programme sur votre site Web pour permettre à des utilisateurs de vérifier leurs pages Web, le code source du vérificateur de liens du W3C est en accès libre.

La validation CSS

Depuis 1996, les feuilles de styles en cascade (CSS) permettent de séparer la structure et le style de manière élégante et efficace. Au cours des dernières années (2001), beaucoup d'agents utilisateurs (navigateurs) ont mis en œuvre les normes CSS 1 et CSS 2. Le recours à une feuille de style permet de réunir toutes les informations concernant le style des documents en un seul endroit.

Au moment de la rédaction de cet article, vous pouvez choisir entre les normes CSS 1 et CSS 2 pour styler vos documents.

L'utilisation des feuilles de style offre beaucoup d'avantages, tels qu'une réduction des coûts de création du site Web et une interopérabilité accrue (c'est-à-dire que beaucoup d'agents utilisateurs différents pourront lire votre site Web). Une conception de site Web qui tient compte des diverses versions des agents utilisateurs, avec des tables et des scripts JavaScript, augmente d'environ 30 % le coût de construction initiale.

N'employez pas d'éléments FONT ni d'attributs FACE. C'est une combinaison qui est jugée néfaste en ce qui concerne l'internationalisation. Si vous envisagez de vous débarasser de l'élément FONT pour adopter les feuilles de style, nous vous encourageons à lire le tutoriel de Todd Fahrner Au-delà de la balise FONT : la stylisation pratique du texte HTML.

Comme pour les services de validation HTML et de validation de liens du W3C, on peut vérifier la validité de sa feuille de style. On peut également vérifier la validité des feuilles de style appelées par son document. Si vous souhaitez installer une version personnalisée du validateur sur votre site Web, le code source du validateur CSS est en accès libre.

La validation de l'accessibilité

La fabrication du site Web ne suffit pas. La plupart du temps, on ignore quel sera son public. Les personnes qui viendront sur votre site Web auront différents matériels, navigateurs et/ou des incapacités particulières. Une conception Web accessible présente beaucoup d'avantages commerciaux. Malheureusement, il est plus difficile de valider ses documents par rapport à l'accessibilité. Certains outils, tel que Bobby, peuvent vous aider dans cette tâche mais ils ne constituent pas la réponse définitive à vos problèmes d'accessibilité. La vérification finale du contenu vous incombera. Le groupe d'intérêts Initiative pour l'accessibilité du Web tient une liste de ressources pour vous aider à concevoir des sites Web accessibles.

Les outils pour améliorer pas-à-pas la qualité

Souvent le découragement gagne lorsqu'on essaye de rendre son site Web valide parce que le nombre des pages invalides est immense ou bien parce qu'on ne sait pas par où commencer. C'est très simple, soyez rusé ! Fixez-vous des étapes courtes qui aboutiront à un site Web valide, sans douleur ni découragement. Avancez donc progressivement et recherchez les solutions qui faciliteront votre travail, comme l'utilisation d'un moteur de gabarits.

Voici une liste d'outils qui vous aideront à obtenir un meilleur site Web.

HTML Tidy

Le programme Tidy a été développé à l'origine par Dave Raggett. Ce programme vous aidera à obtenir une page Web valide. Tidy est parfois incapable de venir à bout de toutes les erreurs. Ce n'est pas un outil d'édition :il vous aidera seulement à résoudre les problèmes.

Les documents invalides les plus demandés

Il est parfois difficile de savoir quelles sont les pages invalides de ses sites Web. Lorsqu'on lance un script pour explorer l'ensemble des pages, on peut obtenir une liste énorme de pages invalides.

Comment faire alors ?

Au W3C, Gerald Oskoboiny a développé un outil progressif pour l'assurance qualité des sites Web qui ne surcharge pas de travail le webmestre du site. Celui-ci produit un rapport signalant les dix documents invalides les plus demandés, avec un descriptif et on peut ainsi les corriger. Chaque semaine, le webmestre reçoit un nouveau rapport listant les dix documents les plus invalides. Cet outils est mis à la disposition du public. Vous pouvez l'adapter à vos besoins.

Olivier Théreaux (W3C) en a développé une version plus portable et modulaire : LogValidator

Le programme prend les derniers journaux d'accès d'un serveur Web et les passe par des modules de validation. Ces modules vérifient la validité des documents les plus demandés par rapport à une technologie particulière. Le module par défaut est celui de validation HTML mais d'autres seront bientôt disponibles.

Vous pourrez donc corriger l'orthographe de vos pages Web, vérifier si vous avez des métadonnées incorporées, si les liens sont toujours valides, etc. La documentation de l'interface de programmation d'application (API) permet de créer d'autres modules en fonction des besoins.

Remerciements

Merci à ceux qui ont relu cet article, à savoir Ian Jacobs, Susan Lesch, Olivier Théreaux, Stephanie Troeth et Jeffrey Zeldman, et aux intervenants de la liste de diffusion public-evangelist.

Cet article n'aurait pas vu le jour sans la participation de Kim Nylander, rédacteur technique, qui l'a relu et y a contribué.


Valid XHTML 1.0!

Créé le 2002-04-08 par Karl Dubost
Dernière modification $Date: 2003/05/28 01:17:04 $ par $Author: kdubost $

Copyright © 2000-2003 W3C® (MIT, ERCIM, Keio), tous droits réservés. Les règles de responsabilité, de nom de marque, d'utilisation des documents et d'octroi de licences du W3C s'appliquent. Vos échanges avec ce site interviennent conformément à notre politique de confidentialité vis-à-vis du public et vis-à-vis de nos membres.