Voici donc une liste (non-exhaustive) des points de contrôle effectués :

Points de contrôle
Ergonomie
	Ne pas utiliser de soulignement de texte pour autre chose que des liens.
	La page 404 est indispensable et doit être personnalisée aux couleurs du site. Proposer éventuellement un formulaire de recherche.
	Une feuille de style d’impression doit être prévue.
Accessibilité
	En cas d’utilisation de plug-ins (vidéo, Flash), prévoir une alternative textuelle pour un utilisateur qui n’aurait pas installé et/ou ne voudrait pas installer le plug-in.
	Tester la page sans images (via l’extension Webdevelopper de Firefox) pour s’assurer que l’ensemble du contenu est lisible sans les images de fond. Exemple : Un texte blanc sur une image def fond peut devenir illisible si aucune couleur de fond n’a été spécifiée dans les propriétés du bloc conteneur.
	Toute image doit avoir un alt, renseigné ou non. Illustration : alt vide, ou image de fond
	Dans le cas où des fichiers sont proposés au téléchargement, deux points sont à respecter : format ouvert, poids du fichier à télécharger doit être indiqué.
	Le javascript doit être non-obstrusif et le site doit être parfaitement utilisable s’il est désactivé par l’utilisateur.
Intégration HTML / CSS
	Les pages sont valides W3C
	Le balisage est propre : pas de styles ou de scripts dans le code HTML
	Le doctype du document HTML sera du XHTML 1.0 Transitional dans le cas (limité) d’utilisation d’iframe.
	Le doctype du document HTML sera du XHTML 1.0 Frameset dans le cas (limité) d’utilisation de frameset.
	Bannir l’utilisation de tableaux pour la mise en page, les tableaux ne doivent être utilisée que pour des données tabulaires et non pas pour créer des mises en page.
	S’efforcer de renseigner l’intitulé « title » des liens pour des raisons de référencement et d’accessibilité. Le title du lien doit fournir plus d’informations que l’intitulé du lien lui-même (mais y compris l’intitulé ; ex : « Aide (nouvelle fenêtre) »)
	La structuration de l’information doit être cohérente par rapport au contexte général du site Web (ex : pas de pub au milieu du texte)
	Une page Web doit posséder une structure cohérente (utiliser h1 (oblig.), h2, …pour leur fonction 1ère ; les blocs d’infos doivent être distincts)
	Pour les tableaux de données, identifier les zones suivante : « thead » (pour l’entête du tableau), « tbody » (pour le corps du tableau) et « tfoot » (pour les données de pied de tableau). On s’efforcera de fournir une description du tableau au sein de la balise « summary »
	Les champs de saisie d’un formulaire doivent être reliés à leurs textes explicatifs respectifs (spécifier label, id et for)
	Respecter le sens sémantique des balises. Proscrire l’utilisation des balises et attributs dépréciés (ex : b, center, basefont, applet, dir, font, isindex, menu, s, strike, u et align, bgcolor, height…).
	Utiliser la balise <abbr> et/ou <acronym> ainsi que son attribut title lorsque cela est possible.
	Dans le cas d’un style spécifique à Internet Explorer, utiliser les commentaires conditionnels. Evitez les hacks du type « _margin » ou encore « *width »
	Pour conserver un maximum de souplesse aux feuilles de style, limiter tant que possible le « poids » des déclarations. Exemple : privilégier « .content » à « body.page #wrapper div.content »
	Pas de notions topographiques ou colorimétriques dans les noms de classes ou : noms faisant référence à la structure. Pas de couleur ni gauche/droite. Exemple : ne pas utiliser div.rouge ou div.left. Si on décide un jour de modifier les propriétés de placement ou d’apparence, ces classes n’auront plus de sens.
	Ne pas utiliser de cote, double ou simple, dans les chemins des CSS.
	Les sites, les pages doivent pouvoir être actualisés facilement et avec souplesse. De ce fait, les zones de contenu doivent s’étendre graphiquement en hauteur (pas de hauteur fixe donc pour les blocs)
Optimisation du référencement
	Pour des raisons de référencement, limiter au maximum les paramètres et les caractères « exotiques » dans les liens.
	Les balises d’indexation <title>, <meta name= »description » /> et <meta name= »keywords » /> doivent êtres renseignées même si leur action en terme de référencement peut être discutable. Elles doivent être situées juste sous la balise définissant l’encodage et dans l’ordre suivant : title / description / keywords
	La balise <title> doit être présente et renseignée sur toutes les pages. Elle doit être en adéquation avec son contenu et donc, dans la plupart des cas, différente d’une page à l’autre.
	La balise <meta name= »description »> doit être présente et renseignée sur toutes les pages. C’est une balise visible par l’internaute. Elle doit être significative de son contenu, des services rendus par la page, des informations livrées.
	La balise <meta name= »keywords »> doit être présente et renseignée sur toutes les pages. Elle doit reprendre les quelques mots-clé de la page. On peut aussi y inclure certains pluriels, synonymes, anglicismes, etc.
	Prévoir un fichier à l’intention des robots d’indexation, à la racine du site. (robots.txt)
Compatibilité Navigateurs
	Internet Explorer 6, (N.B. : Pour cette version, il faut que le site soit un minimum exploitable)
	Internet Explorer 7 et +,
	Firefox 2 et +,
	Safari 2 et + (tolérance)
	Opera 9 et + (tolérance)
	Les pages livrées doivent s’afficher, sans ascenseur horizontal, dans un écran en 1024 x 768
Performance
	Le poids maximal d’une page, images incluses, ne doit pas dépasser 150k.
	Seule la page d’accueil fait exception et peut atteindre jusqu’à 250k, images incluses.
	Évitez les appels multiples à des feuilles de style ou à des fichiers javascript. Merger ces appels pour des raisons évidentes de performance
	L’utilisation du format PNG 24 devra être utilisé avec parcimonie pour des raisons de compatibilité navigateur (IE6 ne supporte pas les couches alpha sans l’utilisation de DirectX. Ce dernier pose des soucis de performances, les images filtrées n’étant pas mises en cache).
Autre…
	L’encodage privilégié est l’UTF-8, il est indiqué avec la balise meta « content type ».
	Les caractères suivants doivent être encodés sous forme d’entité HTML : &, <, >, €
	Prévoir une icône de favori à la racine du site.
	Les valeurs monétaires, statiques ou dynamiques, doivent suivre le format suivant : un espace insécable comme séparateur de millier une virgule comme séparateur de décimale un espace insécable entre le nombre et son unité
	Utiliser un espace insécable entre une double ponctuation et le mot qui la précède : !, ?, :, ;
	Les chemins vers les pages (mais aussi vers les scripts, feuilles de style, images, etc) doivent être en absolu en considérant le répertoire / comme la racine du site.
	Dans le cas d’envoi de paramètre dans l’URL, ne pas oublier d’encoder sous forme d’entité HTML le « & » (&amp;).

Il existe différentes versions du XHTML :

• XHTML 1.0 Strict : Il ne gère que le contenu du document et non l’affichage. C’est le type de document à privilégier.
• XHTML 1.0 Transitional : C’est la passerelle entre le HTML et le XHTML. Il permet l’utilisation de balises liées à l’affichage.
• XHTML 1.0 Frameset : C’est le seul type de document qui autorise les frames. Logiquement, un document accessible ne doit pas inclure d’éléments frame donc à éviter…
• XHTML 1.1 : C’est une évolution du XHTML 1.0 Strict avec quelques balises qui ont été implantés ou modifiés.

Lors de la construction d’un document XHTML, il est important d’avoir à l’esprit que ce n’est pas l’apparence du site qui engendre le balisage mais bien le contenu de ce document.

Pour l’élaboration d’un document type, nous prendrons le XHTML Strict 1.0 comme référence. Nous ne gérerons que le contenu. Exit les propriétés d’affichage tels que bgcolor, color ou encore size. Nous éviterons, de ce fait, de placer l’attribut (tout à fait valide) style= »" qui insère dans le document des propriétés CSS. Cela se fera dans une feuille de style externe. Le XHTML nécessite de se mettre en conformité avec certaines règles :

• Le XHTML impose l’utilisation d’attributs
  <input type= »checkbox » name= »_option-test » id= »option-test » value= »" checked> en HTML s’écrit en XHTML : <input type= »checkbox » name= »_option-test » id= »option-test » value= »" checked= »checked » />
• Toute balise ouverte doit être refermée
  Vous pourrez remarquer dans l’exemple ci-dessus le slash à la fin de la balise input.
• Les balises doivent être correctement imbriquées
  Un ordre hiérarchique des balises est défini. C’est l’ordre logique de lecture du document qui déterminera l’agencement des balises et non l’affichage que le site devra avoir à l’écran.
• Toute la syntaxe doit être rédigée en bas de casse
  Autrement dit, en minuscule.
• Les attributs obligatoires ne doivent pas être omis
  On citera notamment alt pour la balise img.
• Chaque attribut sera encadré de guillemets
  L’utilisation de double-quote est donc de rigueur conseillé pour chaque attribut de balise.

L’entête du document

L’entête de page permet au navigateur de connaître un certain nombre d’informations avant de charger le corps de page (le contenu). On y trouvera par exemple, le type d’encodage (UTF-8 ou ISO), le titre du document ou l’appel à des fichiers externes (feuilles de style, javascript). L’entête est introduit par la balise <head> qui est insérée juste après le balise <html>.

La première étape n’est pas indispensable. On indique au navigateur qu’il s’agit d’un document XML tout en renseignant dans l’attribut encoding, l’encodage des caractères (ici ISO) :

< ?xml version="1.0" encoding="iso-8859-1"?>

Un problème se pose toutefois avec Internet Explorer. En effet, en affichant cette balise avant le doctype, le navigateur passe en quirks mode, c’est-à-dire en mode non-standard.

Le DOCTYPE est la seconde chose à spécifier dans le document XHTML. Il permet au navigateur de savoir à quel type de document il a à faire. Voici les DOCTYPEs XHTML qu’il est possible d’insérer :

XHTML 1.0 Strict

< !DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" 
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">

XHTML 1.0 Transitional

< !DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" 
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

XHTML 1.0 Frameset

< !DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Frameset//EN" 
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-frameset.dtd">

XHTML 1.0 Strict

< !DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" 
"http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">

Ensuite, il faut renseigner la balise <html> avec un namespace utilisant l’attribut xmlns. On prendra le soin de spécifier la langue du document dans les balises xml:lang= »la_langue » et lang= »la_langue ». Cette redondance est requise pour la validité du document et la compatibilité avec les différents navigateurs. Ces deux attributs ont la même fonction mais lang= »" permet en réalité d’être compris sur les anciens navigateur.

<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="fr" lang="fr"></html>

Nous passons ensuite à l’entête du document par le biais de la balise <head>. Cette balise permettra de lier au document une ou plusieurs feuilles de styles, d’insérer des appels à des fichiers javascript. Mais auparavant, il faut définir l’encodage du document à l’aide d’une balise meta :

Pour de l’UTF-8 (Encodage international) :

<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />

Pour de l’ISO (Encodage européen) :

<meta http-equiv="Content-Type" content="text/HTML; charset=iso-8859-1" />

Pour plus d’info sur la notion d’encodage, lisez l’article d’OpenWeb sur les jeux de caractères

On aura la possibilité d’ajouter différentes balises méta afin de permettre un meilleur référencement du document. En voici un exemple :

<meta name="DC.title" xml:lang="fr" content="Clearideaz.com, XHTML, CSS, Accessibilité, Marketing, Design web" />
<meta name="author" content="Gorzalka, Olivier" />
<meta name="description" content="Carnet web de Olivier Gorzalka" />

Comme vous pourrez le constatez, on utilise une balise meta avec dans l’attribut name DC. Il s’agit en fait d’un schéma de métadonnées générique préconisé par le W3C.

Nous pouvons maintenant définir le titre du document avec la balise <title>. Il faut qu’il soit explicite. Évitez de donner le même titre à toutes les pages de votre site. Pensez aux personnes non-voyantes (et pas seulement…) utilisant des lecteurs de d’écran et qui se repèrent grâce aux dénominations des différents articles. Le titre se présentera de la façon suivante :

<title>
     Clearideaz.com, XHTML, CSS, Accessibilité, Marketing, Design web
</title>

A la suite de ce <title>, on insère l’appel éventuel à une feuille de style. Il existe deux méthodes sensiblement équivalentes :

La méthode @import :

<!--
     @import url(/themes/clearideaz/style.css);
-->

La méthode link

<link rel="stylesheet" href="themes/clearideaz/style.css" type="text/css" media="screen" />

Il n’existe pas, en soit, de grandes différences entre ces deux méthodes. Nous signalerons tout de même que @import n’est pas reconnue par les navigateurs dinosaures tels que Netscape 4.

Le corps du document

Nous arrivons au corps du document via la balise <body>. C’est le contenu qui sera visible dans le navigateur internet. On s’efforcera de hiérarchiser au maximum les éléments textuels. Il est important de ne pas penser à l’apparence du site lorsque l’on procède au balisage du document. Il faut respecter l’ordre de lecture du contenu. Nous userons par exemple des différents niveaux de titre : <h1>, <h2>, <h3>, … Lorsqu’il s’agira d’une liste d’éléments, on utilisera les listes à puce :

<h1>Sciences de la vie</h1>
<p>Bienvenue sur le site "Sciences de la vie"</p>
<h2>Le monde animal</h2>
<p>Voici différents animaux :</p>
<ul>
     <li>Le chien</li>
     <li>Le singe</li>
     <li>Le tigre</li>
</ul>

Rappel : Chaque balise ouverte doit être obligatoirement refermée. Ainsi un paragraphe de texte commencera par <p> et se terminera par </p>. Les balises de retour à la ligne ne s’écrivent plus <br> comme ce fut le cas dans le HTML mais <br />. Idem pour <hr> qui devient <hr />.

Un document XHTML type n’organisera pas son contenu à l’aide de tableau. Pour une meilleure hiérarchisation, on utilisera les calques qui se traduisent par des balises <div>. Ces balises nous permettrons par la suite de styler le document à l’aide de la feuille CSS. Il est judicieux d’attribuer à chaque balise <div> un ID explicite qui permettra de les différencier lors de l’élaboration de la feuille de style :

<div id="page">
     <div id="entete">
     </div>
     <div id="conteneur">
     <ul id="menu-principal">
          <li>Rubrique 1</li>
          <li>Rubrique 2</li>
          <li>Rubrique 3</li>
     </ul>
     <div id="contenu">
     </div>
     </div>
     <div id="pied">
          <p>Créé par Moi :)</p>
     </div>
</div>

Évitez de multipliez les calques, cela facilitera la compréhension de votre balisage.

Enfin on ferme la balise <body> et <html> du document. Voici donc ce que l’on pourrait obtenir :

< !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>
     <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
     <meta name="DC.title" xml:lang="fr" content="Weblog.fr, XHTML, CSS, Accessibilité, Marketing, Design web" />
     <meta name="author" content="Gorzalka, Olivier" />
     <meta name="description" content="Carnet web de Olivier Gorzalka" />
     <title>Weblog.fr, XHTML, CSS, Accessibilité, Marketing, Design web</title>
     <style type="text/css" media="screen">
          @import url(/themes/weblogr/style.css);
     </style>
</head>
<body>
     <div id="page">
          <div id="entete">
               <h1>Sciences de la vie</h1>
          </div>
          <div id="conteneur">
               <ul id="menu-principal">
                    <li>Rubrique 1</li>
                    <li>Rubrique 2</li>
                    <li>Rubrique 3</li>
               </ul>
               <div id="contenu">
                    <p>Bienvenue sur le site "Sciences de la vie"</p>
                    <h2>Le monde animal</h2>
                    <p>Voici différents animaux :</p>
                    <ul>
                         <li>Le chien</li>
                         <li>Le singe</li>
                         <li>Le tigre</li>
                    </ul>
               </div>
          </div>
          <div id="pied">
               <p>Créé par Moi :)</p>
          </div>
     </div>
</body>
</html>

La validation W3C

Une fois le document XHTML terminé, il faut passer le fichier HTML au validateur W3C. Le W3C est un consortium visant à promouvoir la compatibilité des technologies du Web et notamment le XHTML. En vérifiant la validité de la syntaxe de votre site, vous aurez la certitude que les différents documents XHTML respectent les standards du web. Si votre document contient des erreurs, le validateur vous les listera et il faudra bien évidemment les corriger

Les balises courantes

Il existe un grand nombre de balises XHTML qui permettent de rendre le document plus compréhensible. Je vous invite à visiter l’espace de Giminik qui recense l’ensemble des balises courantes du XHTML. Il existe deux grandes catégories de balises. Les inline (en-ligne) et les block (bloc). Les balises blocs permettent de structurer le document et peuvent contenir d’autres balises block ou inline. Les inline quant à eux attribue une sémantique spécifique à des mots d’une phrase et ne peut contenir que des éléments inline.

Les balises de type block

<div>
Elle donne la possibilité de structurer le contenu en différent blocs couramment appelés calques.

<h1>, <h2>, <h3>, <h4>, <h5>, <h6>
Ils définissent différents niveaux de titre (ex: <h2>Mon titre</h2>). Il est à noter que la balise <h1> ne peut être utilisée qu’une fois.

<hr />
Cette balise insère une ligne horizontale dans le document.

<p>
Cette balise identifie un élément comme paragraphe.

<ul>, <ol>, <li>
Elles intègrent des listes d’éléments au document. La balise <ul> insère une liste à puces tandis que <ol> dresse une liste ordonnée. Les différents éléments de la liste sont encadrés par la balise <li>.

Les balises de type inline

<a>
Elle insère un lien hypertexte sur le texte balisé. Elle peut aussi agir comme point d’ancrage dans le document.

<br />
Elle permet d’insérer un saut de ligne. A utiliser avec parcimonie…

<em>
Le texte est mis en emphase? On l’assimile souvent à tort avec la balise <i>.

<strong>
Elle permet de réalise une mise en emphase forte.

<span>
Elle donne la possibilité de mettre en forme du texte à l’aide de CSS.

<img />
Cette balise insère une image dans le document. Elle doit automatiquement intégrer un attribut alt= »".

<cite>
Elle défini un texte comme citation. L’équivalent en block est blockquote.

<abbr>
Elle donne la signification d’une abréviation. (ex: <abbr title= »Cascading Style Sheet »>CSS</abbr>).

<q>
Elle caractérise une courte citation.

Ce qu’il faut éviter

Voici quelques petites choses à éviter lors de la création de votre document XHTML.

• Abuser des retours à la ligne (<br />). Préférez l’utilisation de paragraphe (<p>)
• Multipliez les balises <div>. D’autres éléments peuvent être stylés à la manière de ces calques.
• Utiliser <img /> pour des illustrations. Cette balise ne doit être utilisée que si elle apporte un complément d’information au texte de l’article.
• Insérer du javascript dans le document. Tout le code JS doit être placé dans un fichier externe. C’est ce qu’on appelle le javascript non-intrusif.
• Nommer les ID ou les class des différents éléments en fonction de la couleur qu’ils auront dans le document. Pensez que votre site pourra évoluer et donc que les couleurs pourront changer. Nommer donc vos balises selon leur sens sémantique et non selon leur apparence.
• Insérer du style CSS dans le document avec style= »". La feuille de style est là pour ça, pourquoi surcharger votre document ?

Comme nous avons pu le constater, la création d’un document XHTML est soumise à un certain nombre de règle. A ces règles s’ajoutent ensuite les contraintes d’accessibilités. En respectant ces « normes », vous garantissez à votre site d’être lu par différents supports. Être lu par le plus grand nombre, c’est bien ça le principe du web

Pour aller plus loin

Quelques liens qui apporteront un complément à ce billet :

• Documentation du XHTML 1.0 par le W3C (traduction française)
• Rubrique XHTML du site OpenWeb

• Le site web dédié à cet ouvrage : transcendingcss.com

Aujourd’hui, l’apparence d’un site Web est un élément primordial qui peut fidéliser des visiteurs. Le look peut saisir l’utilisateur soit par la beauté de sa simplicité (Flickr pour ne citer que lui) ou encore par sa finesse et sa recherche du détail (le blog de Veerle en est un excellent exemple).

La réalisation web est devenu un exercice particulièrement périlleux au vue de la multiplication des supports de lecture (PDA, Lecteurs d’écran, systèmes d’exploitation) et c’est pourquoi il a fallu définir un certain nombre de conventions en quelque sorte.

On utilise le terme « Accessibilité » à tort et à travers mais de quoi s’agit-il exactement ?

Pour Tim Berners-Lee, directeur du W3C, l’Accessibilité c’est :

Mettre le Web et ses services à la disposition de tous les individus, quel que soit leur matériel ou logiciel, leur infrastructure réseau, leur langue maternelle, leur culture, leur localisation géographique, ou leurs aptitudes physiques ou mentales.

Quelle jolie idée ! Sur le papier c’est pas mal mais sur le terrain, c’est une autre histoire. Le message est parfois mal compris.

Le fond et la forme

Le W3C est un consortium qui veille à ce que les pages web respectent plusieurs règles syntaxiques. Il a mis en place sur son site officiel un validateur de pages qui scrute les différentes pages à la recherche de l’erreur de syntaxe fatale !!! Mais beaucoup considèrent que si le site passe dans le validateur, c’est qu’il est accessible. Il n’en est rien.

Plusieurs balises ou informations importantes pour les lecteurs d’écran peuvent être insérées dans le code afin de le rendre plus accessible. Par exemple pour un tableau, il est recommandé de fournir une balise <caption> afin de lui définir une légende. Mettre des title= »" pour les balises de lien est également un reflex à avoir (j’avoue parfois, j’en oublie, suis-je pardonné ?).

La vraie révolution ces dernières années a été de passer au XHTML ! Enfin, on ne mélangeait plus dans le processus de création la structure et la présentation ! C’est à ce moment qu’on a pu constater la puissance des feuilles CSS. En reprenant le même squelette HTML, on pouvait modifier l’apparence totale avec deux feuilles de style. Toutefois, même si de plus en plus de concepteurs web tendent à apprendre CSS et XHTML, d’autres se bornent à poursuivre à réaliser des sites avec tableaux. Et le plus triste dans tout ça, c’est que parfois ces sites sont présentés en exemple. Sur Webcreme (un site que je fréquente régulièrement), j’ai pu découvrir l’horreur (j’en fais trop ?). Le 23 Novembre, Webcreme publie le site FOURIV qui est bâti uniquement sur des tableaux… Je me rassure en me disant que Webcreme ne s’est jamais défini comme un relais des techniques de créations XHTML/CSS mais plutôt comme une inspiration pour le design de site web.

Finalement

Faire du design web actuellement, c’est plutôt imaginer comment disposer les différents calques de manière à obtenir la plus jolies mise en page. Il ne s’agit plus de créer sa maquette sur Photoshop et de l’adapter sans réfléchir sur son éditeur html. Il y a un véritable travail de sémantique. L’ordre dans lequel seront disposées les différentes balises ne sera pas forcément l’ordre dans lequel les éléments apparaîtront sur la page. Par exemple, il est en général, plus convenable de placer le menu de navigation en haut de la page de code juste en dessous de la balise de titre principale (h1) même si sur la maquette du site web, ce menu apparaît sur le coté gauche, en dessous de la bannière.

Lors de la phase de conception, l’idéal, serait en fait, de bâtir dans un premier temps le code html nu sans feuille de style afin de réaliser une hiérarchisation du contenu et surtout organiser une certaine logique de la sémantique (oh ça rime !).

En tout état de cause, le design web n’est plus uniquement un souci d’apparence mais aussi une réflexion autour de l’intégration des éléments graphiques dans le code. Cela permet des rapprocher les codeurs et les designeurs et ça, c’est plutot une bonne nouvelle