La sémantique : donnez un sens au Web...
Voilà un moment que je n'ai pas parlé d'accessibilité numérique, de standards du web ou même de développement sur ce blog[1]. Je remets le pied à l'étrier avec un article dédié à la sémantique. Notion souvent abstraite pour les novices mais tant rabâchée par les gourous, il est temps de clarifier la situation en expliquant de quoi il retourne. Bref, à vos dicos !
Notes
[1] Je vous rappelle en passant que la catégorie Standarderies regroupe les articles traitant de ces domaines et qu'une petite recherche ramènera à vous les quelques billets égarés dans les autres recoins de ce site.
Définition :
La sémantique n'est rien de plus que l'art d'utiliser chaque balise (x)HTML à bon escient, pour le rôle qui lui a été attribué et qui a été défini à travers les recommandations du W3C et cela indépendamment de son rendu par défaut.
Ainsi, chaque élément à un rôle approprié, une signification. L'intérêt du respect de cette signification est de pouvoir tirer des informations de la page rien qu'en analysant son code. C'est le principe des lecteurs d'écran ou des agrégateurs RSS par exemple. Ce procédé a été mis en place à des fins d'accessibilité, de clarté et de différenciation des éléments et doit être appliqué au nom du respect des standards.
L'avènement et la popularisation du XML a amplifié l'importance de la sémantique. En effet, le XML est principalement basé sur la sémantique afin d'organiser les informations et de les traiter par la suite. Le xHTML étant le résultat de l'union de ce méta-langage et du HTML, il est donc normal que cette notion soit héritée et donc relativement présente dans ce langage. Mais il ne faut pas oublier qu'elle s'applique aussi au HTML, même si il a la réputation d'être plus permissif.
Exemples et mise en oeuvre :
Il y a des réflexes à avoir afin d'éviter les principales erreurs que l'on peut rencontrer sur le net. Tout d'abord, il faut savoir que tout texte, sauf pour les titres, les listes à puces et autres cas exceptionnels, doit être inclus dans un paragraphe <p>
. Il en va de même pour les images <img />
qui font partie intégrantes de l'information que délivre le texte. J'exclus ici les images servant à la mise en page.
Un menu étant considéré comme une liste de liens, nous utiliserons donc une liste à puces <ul>
pour le mettre en page, qu'il soit orienté verticalement ou horizontalement. La mise en place d'une mise en page par les CSS nous permettra par la suite de modifier l'orientation et la mise en page de cette liste à puces. D'autres personnes y préfèreront les listes de définition <dl>
, mais c'est un long débat dans lequel nous ne rentrerons pas.
Les titres <h1>
à <h6>
sont à préférer au code suivant, qui n'apporte aucun sens réel au code, <div>
étant une balise dite neutre :
<div class="titre">Titre</div>
De même, ils doivent être utilisés selon un ordre hiérarchique et architectural logique. Ainsi, tout <h3>
aura été introduit et précédé d'un <h2>
lui même précédé d'un <h1>
. La choix des titres <hx>
ne dépend pas seulement de leur importance mais aussi de leur hiérarchisation. L'architecture d'une page Web doit transparaitre à travers le code source.
Les balises neutres <div>
et <span>
sont à proscrire pour remplacer une balise existante. On y privilégiera l'emploi de balises respectivement blocs et en-ligne adaptées et auxquelles on associera une mise en forme identique à celles des balises neutres. L'imbrication inutile de balises blocs doit également être évitée.
Les tableaux <table>
sont à proscrire pour la mise en page de sites web. Ils ne sont destinés qu'à la mise en page de données tabulaires. Les données tabulaires sont des données destinées à une classification dans un tableau à double entrée minimum. L'utilisation des tableaux pour la mise en page, bien que déconseillée a été et est toujours très utilisée pour des raison de facilité de compatibilité entre les navigateur mais elle est très lourde et comporte de nombreux désavantages.
Les balises <b>
et <i>
qui, contrairement à ce que l'on peut penser, ne sont pas invalides xHTML 1.0 Strict, ne sont pas forcément respectivement remplaçables pas les balises <strong>
et <em>
. En effet, même si elles sont interprétées de la même manière, elles n'ont pas le même sens sémantique.
Alors que <b>
et <i>
sont employées pour leur forme, c'est à dire une mise en gras et italique, <strong>
et <em>
sont les marques respectives d'une forte et d'une petite emphase, qui sont le plus souvent modélisées par une mise en gras et une mise en italique mais qui pourrait avoir une mise en page totalement différente.
Ambiguïté et difficultés d'interprétation :
Bien que la sémantique du (x)HTML soit généralement assez stricte, il existe des cas menant à une certaine ambiguïté. C'est par exemple souvent le cas pour un forum. Un forum doit-il être présenté sous la forme d'un tableau ou sous une mise en page (x)HTML/CSS ? Les données présentées y étant mi-tabulaires, mi-textuelles, il est difficile de trancher. Certains optent donc pour des tableaux, d'autres pour une mise en page (x)HTML couplé à CSS. On laisse donc le choix au développeur. C'est selon son appréciation et sa philosophie qu'il décidera de la manière de concevoir son forum.
Conclusion :
La sémantique est encore une fois le signe d'une avancée technologique, qui permet de donner du sens aux données textuelles, et donc par extension à son code. Ainsi, ce code pourra être correctement exploité sous toutes ses formes grâces aux différents outils à disposition. Il ne faut donc pas choisir ses balises en fonction d'un rendu, qui sera facilement modifiable par les CSS, mais en fonction de leur signification première. C'est là tout l'art du développeur : donner un sens à un code, sans en sacrifier l'accessibilité, la mise en page, ou le rendu et tout en permettant l'exploitation et le traitement des données postérieurs à la publication.
Commentaires
très bon article !
il y a ce validateur pour être sur de l'accessibilité de son site
http://validateur-accessibilite.api...
Très bon article qui restait depuis un moment dans mon agrégateur dans "al lire", il est désormais blogmarké! C'est exactement ce que j'explique lorsque je me retrouve formateur, le pire je crois c'est expliquer le coup de pourquoi il est préférable d'utiliser strong au lieu de b....
arnaud : merci bien, ce lien très pratique commence petit à petit à se faire connaitre des développeurs et c'est tant mieux.
Simay : Venant de la part d'un formateur en accessibilité, ça me flatte. Peut-être ai-je finalement quelques bribes de didactisme exploitables.
Fil des commentaires de ce billet