L'XHTML ainsi que l'HTML sont des langages devenus normalisés afin d'assurer une meilleure compatibilité par conséquent une plus grande portabilité. Dès lors, de nombreuses spécifications expliquant leurs fonctionnements et leurs utilisations ont vu le jour (vous pouvez retrouver la majorité des documents chez le W3C).
Le validateur [1] permet entre-autre de vérifier si la syntaxe est respectée. Ainsi, il recherchera les balises non refermées, des caractères non conformes (les débutants rencontrent la plupart du temps des erreurs sur l'entité AND symbolisée par &). Toutes les erreurs qu'il renvoit correspondent à un contexte technique. Or, les normes ne sont pas que techniques, il y a aussi un aspect philosophique (sémantique).
Voilà pourquoi, vous trouverez ici, des liens vers Opquast[2].
Les normes pour l'accessibilité
Les normes ne sont pas nées du jour au lendemain, elles sont le fruit de plusieurs semaines, mois, voire années de travail. À la base, le langage du net était l'HTML. De nombreuses compagnies y ont ajouté des balises spécifiques à leur besoin, c'est ainsi qu'est apparue <marquee>, <blink>, <comment>.
Au final, cette guerre de navigateurs[3], posa un réel problème aux développeurs de sites web : faire en fonction du marché ou développer pour un navigateur méconnu ? Ce problème existe toujours aujourd'hui puisque IE, également mozilla[4], disposent de propriétés CSS qui leurs sont propres.
Les normes ne sont pas là que pour les personnes souffrant d'handicaps, elles existent aussi pour les engines[5]. Il faut savoir que les navigateurs corrigent les codes sources pour essayer d'en rendre un meilleur rendu par exemple :
<img src='adresse'>
Il manque l'attribut alt. Voici ce que le navigateur rendra après correction :
<img src='adresse' alt=''>
Quelques autres corrections pourront avoir lieu : tout dépendra du header HTTP que vous avez choisi. Si vous êtes en application/xhtml+xml, le navigateur rajoutera le slash fermant la balise. Rendant donc le code suivant :
<img src='adresse' alt=''/>
Le navigateur enclanche donc des processus de correction en fonction du type mime utilisé.
Ici, les corrections sont minimes, mais dans le cas de balises imbriquées (souvent dues à des éditeurs WYSIWYG à interface permettant l'édition de manière graphique) :
<font family=Trebushet MS, sans size=2+ Texte</font>
Là, seul les navigateurs les plus performants arriveront à avoir un résultat correct, pour les autres, vous risquez soit de voir la balise font soit de voir « sans size=2+ Texte », dans d'autres cas, l'ensemble, bref, dès qu'un code est non-valide le résultat devient aléatoire. Imaginez simplement le cas des lecteurs d'écran : un aveugle entendra des balises, des noms de polices, ainsi que des tailles, je vous laisse le plaisir d'imaginer ce que l'utilisateur pensera de votre site.
Par ailleurs, il ne faut pas être anarchiste. Les pages comportant une voire deux erreurs sont des pages qualifiables de « valides », surtout si elles sont dues à un ajout de numéro de sessions dans les liens.
En tant que conclusion à cette partie, je dirai que les normes développent une accessibilité polymorphe (cette accessibilité est aussi bien destinée aux personnes ayant des problèmes de santé, mais aussi à la logistique en elle-même).
Complément
Lire : FAQ Décideur
Apprendre les normes
Pour apprendre les normes, il n'y a pas de solution « miracle », il faut lire les sites appropriés. En voici une liste :
Il y a bien évidement la question à se poser : quel doctype vais-je utiliser ? Il en existe plusieurs, et beaucoup répondent à des différents besoins. Fix Your Site With the Right DOCTYPE! vous aidera à faire votre choix. Par ailleurs, vous ne devez oublier qu'il est inutile de prendre un doctype qui ne vous est pas destiné même si c'est celui qui vous semble être le plus évolué. Par exemple : l'utilisation de l'XHTML 1.1 vous impose l'utilisation de l'entête HTTP application/xml obligeant votre navigateur à afficher une erreur si la page est mal codée.
Complément
Cet article vous donne plus d'explications sur le pourquoi ne pas utiliser l'XHTML 1.1 : C² retourne en XHTML 1.0 strict
Comprendre les normes
Les normes sont assez faciles à utiliser mis à part quelques subtilités pouvant poser problème comme les AND, les divisions à ajouter dans les formulaires, les slashes placés en fin de balise. Pour le reste, il s'agit de comprendre à quoi peut servir une balise, et pourquoi l'utiliser. Pour répondre à ce problème, je vous propose de corriger en même temps que moi un code source valide syntaxiquement mais invalide sémantiquement.
Un doctype adapté
La personne qui a réalisé cette page s'occupe d'un Gite de séjour. Il s'agit donc d'un site servant de devanture web. Il faut donc un maximum d'accessibilité. À regarder le code source uniquement et le fait qu'il n'y ai aucun tableau laisse à penser qu'il serait plus bénéfique de faire passer le site en XHTML 1.0 strict obtenant ainsi l'attribut : xml:lang, un code dont l'aspect est plus proche de l'XML (définissant ainsi le début et la fin d'une balise).
Donc, dans le code, il faudra remplacer le DT :
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
Par :
<!DOCTYPE HTML PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
Ensuite, toutes les balises uniques (telles que img) devront être refermées : ainsi <img src="images/panoexte.jpg" alt="Vue de la terasse du gîte"> deviendra : <img [...] />. Ce ne sont pas les seules différences entre un code HTML et un code XHTML, il faut aussi rajouter un prologue XML [...] une publication de Laurent Jouanneau et Denis Boudreau vous donnera la liste détaillée des modifications à effectuer.
Critique d'une page aux normes
En tant que rappel, les normes peuvent vous permettre d'avoir une page dont la syntaxe est valide mais dont le fond est loin de répondre à l'accessibilité.
Une balise, un sens
Comme souvent dit chez Opquast : « les balises ont un rôle, une fonction, elles ne peuvent en aucuns cas être remplacées par des balises artifices », signifiant que toutes les balises existantes ne peuvent en remplacer d'autres même par soucis d'esthétique.
En regardant le code source de la page d'exemple, on voit rapidement ce que cette citation a d'important :
<p>
<span class="titremenu">Gite de séjour</span>
<a href="#" title="Découvrez le gite dans ses moindres détails !">Descriptif</a>
<a href="#" title="Découvrez nos offres pour les familles et les individuels">Accueil familles & individuels</a><a href="#" title="Découvrez nos prestations spécial groupes">Accueil groupes</a>
<a href="#" title="Rien ne remplace les images, laissez vous guider !">Visite en photo</a><a href="#" title="Découvrez le gite">Webcam-live</a>
</p>
Ici, il s'agit de la partie « Menu » du site. Le problème est directement visible : pour une engine, ce texte ne contient que des liens dans un paragraphe texte. Or d'un point de vue idée, il s'agit d'une liste de lien ayant pour titre ou description : « Gite de séjour ». Donc, la balise paragraphe n'est absolument pas adapté : ici, il faudrait placer une balise de division (pour séparer les différentes parties du menu), ensuite, le code <span class="titremenu"> devra être remplacé par une balise titre (<h2> fera l'affaire), et chaque lien aura un élément appartenant à une liste.
Voici donc le code source après correction :
<div>
<h2>Gite de séjour</h2>
<ul>
<li><a href="#" title="Découvrez le gite dans ses moindres détails !">Descriptif</a></li>
<li><a href="#" title="Découvrez nos offres pour les familles et les individuels">Accueil familles & individuels</a></li>
<li><a href="#" title="Découvrez nos prestations spécial groupes">Accueil groupes</a></li>
<li><a href="#" title="Rien ne remplace les images, laissez vous guider !">Visite en photo</a>
<li><a href="#" title="Découvrez le gite">Webcam-live</a></li>
</ul>
</div>
Il faut donc utiliser toutes les balises dont vous disposez. Ayez donc le réflexe de vous demander quelle balise vais-je utiliser pour faire ceci ? Et si vous n'en trouvez pas la solution, d'aller faire un tour sur des forums d'entraide (« Yahoo! is your friend ») comme ceux d'Alsacreation.
Note
Cependant, ne surchargez pas vos pages web de divisions inutiles : il n'est pas nécessaire d'encadrer une liste (...).
À lire : Y'a des calques qui s'perdent de Fabrice Bonny
« Le coup du ID »
L'ID est un attribut unique : il permet dans de nombreux cas de concrétiser des structures de sites web (en définissant des zones), d'appliquer des feuilles de style avec beaucoup plus de facilité que la simple utilisation des attributs class.
Mais comment ça marche ? Un ID par son unicité permet de classifier et d'ordonner le contenu d'un site web.
Ainsi, imaginons que vous souhaitez avoir plusieurs zones dans votre menu, voici ce que vous pourriez obtenir :
<div id="menu">
<div id="menu-general">
<h2>Général</h2>
<ul>
<li><a href="lien">Lien</a></li>
</ul>
</div>
<div id="menu-liensl">
<h2>Liens</h2>
<ul>
<li><a href="http://genesys.net">Genesys</a></li>
</ul>
</div>
</div>
Par ailleurs, cette méthode demande une petite pause de réflexion, et si vous avez du mal à déterminer les ID, réalisez un brouillons concernant la structure de votre site (ou inspirez-vous de sites existants).
D'un point de vue CSS, pour définir un style sur un ID, il suffit de faire :
#menu {
color:green;
}
#menu h2 {
color:darkblue;
}
Compléments
Articles CSS chez Alsacréations
Tutoriaux AListPart
Vous devez également prendre en compte que les « classes » existent pour désigner un ensemble de balises (identiques ou différentes).
Une logique par l'ordre
Un document HTML ou XHTML se doit d'avoir une structure significative : avec des zones ayant une fonction précise. Dans la majorité des sites web, on trouve l'ordre suivant :
- #header : logo du site, description
- #nav : la navigation rapide se fait ici : on place les liens vers les principales zones du site
- #main : la page en question qui est divisée en deux grandes parties :
- #content : le contenu de la page web
- #menu : le menu de la page web
- #footer : le bas de la page (copyrileft, copyright, publicité ...)
Or, lorsque l'on regarde la page d'exemple, pour désigner la partie #header, le code source suivant a été appliqué :
<div class="banniere">
<img src="images/banniere.jpg" alt="Domaine de Sénos - Gite d'étape & de séjour">
</div>
Là, les erreurs sont de nouveau très apparentes :
- La division porte une classe et aucun ID
- Le nom de la classe n'est significatif que de l'aspect physique et non de le l'aspect technique : (« banniere » sera plus employé lorsque l'on veut styliser une affiche publicitaire).
- Le nom du site est placé dans une image uniquement or il devrait être encadré entre deux balises
<h1> puisqu'il s'agit de la partie la plus importante de la page
- L'esperluette (&) n'est pas en entité HTML (&)
Voici le correctif :
<div id="header">
<h1>Domaine de Sénos – Gite d'étape & de séjour</h1>
</div>
Ou :
<div id="header">
<h1>Domaine de Sénos</h1>
<p id="description">Gite d'étape & de séjour</p>
</div>
Vous l'avez sûrement compris, il existe plusieurs solutions. C'est pourquoi je vous invite vivement à aller consulter le site Opquast.
Maintenant, en ce qui concerne la structure globale de la page, on voit également que le menu a été placé avant le texte. Imaginez-vous aveugle, vous utilisez un lecteur d'écran pour connaître le contenu du site web que vous parcourez. Le logiciel lira votre code source comme il est marqué et non comme les CSS l'affichent : ce qui signifie qu'a chaque changement de page, le visiteur aura la lecture du menu avant le contenu.
Cependant, vous devez également prendre en compte l'existence d'une barre de navigation. Elle permet de se déplacer sur les différentes zones composant la page. Tout comme sur ce blog, elle contient différentes zones telles que "Aller au contenu" et "Aller au menu". Ce système utilise le principe des ancres. Pour faire un lien vers une zone d'un site, il suffit simplement d'utiliser l'ID qui lui correspond. Ainsi, si vous souhaitez faire un lien vers le menu, il vous suffira de poser :
<a href="#menu">Aller au menu</a>
Donc pensez à mettre votre menu après votre contenu et de rajouter une barre de navigation. Niveau des erreurs, je crois que c'est tout et qu'il n'y a plus grand chose à rajouter.
Lorsque les normes sont pensées : il est plus compliqué de l'expliquer
La conclusion d'un ticket dont le sujet consiste à expliquer les normes est loin d'être évident. On navigue sur l'ensemble, on se perd dans ses explications, pour au final constater que l'on n'a marqué que des sottises et qu'il faudra tôt ou tard tout récrire.
Les normes sont loin d'être évidentes, et parler facilement sans s'embrouiller et sans embrouiller les autres consiste à un palier trop élevé pour que je puisse le pratiquer sans difficulté. C'est pourquoi je tiens à remercier l'auteur de la page m'ayant servit d'exemple pour expliquer l'intérêt des normes et principalement le fait que même si le validateur marque que la page ne contient pas d'erreur, qu'elle n'en a aucune.
Par ailleurs, nous sommes très loin d'avoir démystifié l'intégralité des spécifications, des sous-entendus, et le pouvoir de prendre en compte chaque changement, chaque moeurs. Voici pourquoi j'espère que ce petit ticket contient un minimum d'explications quant à l'amélioration de sa page (x)html.
En espérant, pour une fois, ne pas avoir pas trop dit de bêtises, je vous laisse regarder le corrigé.
