Pourquoi les standards du Web sont importants

Par Carrie Bickner

Vous venez à peine d'inaugurer le nouveau site Web de votre bibliothèque que déjà, le téléphone n'arrête pas de sonner : "Je viens tout juste de télécharger la version la plus récente de Netscape et votre barre de navigation supérieure est invisible." ; "J'utilise un lecteur d'écran et votre site est tout simplement incompréhensible. Je n'arrive pas à y retrouver quoi que ce soit." ; "Je vous appelle de la part du Consortium des Bibliothèques du Tricounty ; nous apprécions tout le travail que vous avez accompli, mais nous aurions quelques questions à vous poser à propos de la charte graphique du nouveau site."

Le site (malgré des mois de durs labeurs, les meilleurs logiciels et des tests exhaustifs d'assurance qualité) souffre de sérieux problèmes. Pourquoi ? Comment remédier à la situation, tout en ne répétant pas les mêmes erreurs ? La solution se trouve dans l'adhésion à un ensemble de normes Web établies et mondialement reconnues.

Qu'est-ce que le W3C ?

Le Consortium du World Wide Web (W3C), fondé en 1994 par Tim Berners-Lee, est un consortium industriel international comptant plus de 300 membres. Sa principale raison d'être consiste à faire en sorte que les spécifications ouvertes qui y sont produites, communément surnommé les "standards du Web" encourageront l'interopérabilité. C'est aux membres du Consortium et à ses experts invités des différents groupes de travail que revient la responsabilité de rédiger ces spécifications. Une fois approuvées, ces idées sont alors promues au titre de recommandations officielles du W3C.

Le W3C a publié plus d'une quarantaine de recommandations depuis 1994. HTML, XHTML et CSS ne représentent qu'une petite portion du travail réalisé. Les autres recommandations incluent :

  • Les lignes directrices de l'accessibilité Web (Web Accessibility Guidelines) visant à favoriser l'accès au Web pour les personnes aux prises avec des limitations physiques. Ces principes sont également profitables pour l'ensemble des utilisateurs (ils sont en fait similaires aux lignes directrices pour l'accès mobile) ;
  • Scalable Vector Graphics (SVG), un format d'images basé sur XML. Les graphiques SVG sont éditables dans tout éditeur texte et peuvent être indexés par les moteurs de recherche ;
  • MathML, un outil pour baliser les formules mathématiques sur le Web, à l'aide de XML .

On retrouve parmi les membres du W3C des entreprises comme Netscape, Microsoft, Apple, Ask Jeeves, Cannon, DoubleClick, Ericsson et OCLC. L'adhésion d'OCLC repose sur le fait qu'il est essentiel pour la communauté des bibliothécaires de jouer un rôle prépondérant dans le développement et la gouvernance des standards du Web. Alors que les bibliothécaires se retrouvent dans une position où ils sont appelés à partager l'univers technologique avec une multitude de parties prenantes, nous éprouvons le besoin de promouvoir nos perspectives et nos valeurs.

Que sont les standards du Web ?

"Standards Web" est l'appellation utilisée par les développeurs Web pour faire référence aux spécifications et aux lignes directrices émises par le Consortium du World Wide Web (voir ci-contre). Ces lignes directrices, communément appelées "standards," couvrent plusieurs domaines, dont la sécurité et le cryptage sur le Web. Mais les recommandations pour les langages structurés comme HTML, XHTML , XML , ou encore, les langages de mise en page des documents comme CSS (Cascading Style Sheets - Feuilles de Style en Cascades), sont les aspects des normes qui devraient principalement intéresser les développeurs Web œvrant dans les bibliothèques.

En quelques mots, les guides du W3C pour le balisage des documents déterminent comment ceux-ci devraient être structurés et comment les récepteurs (incluant navigateurs, PDAs et interpréteurs Braille) devraient afficher leur balisage.

En ayant recours à XHTML pour la structure des documents et à CSS pour leur aspect, les bibliothécaires ont en main tous les atouts pour créer des sites qui sauront résister au passage du temps ainsi qu'à l'évolution éventuelle des navigateurs et autres agents utilisateurs, incluant toutes les technologies d'assistance. XHTML et CSS, les normes les plus récentes du W3C pour le balisage des documents et leur mise en page, offrent aux sites Web d'aujourd'hui une structure rigoureuse dont les interfaces Web, les moteurs de recherche, les systèmes de gestion de contenu et autres outils apparentés devraient pouvoir tirer avantage.

Par ailleurs, le recours à ces normes réduit considérablement les coûts associés à la production de sites Web, tout en assurant des économies substantielles quand arrive le temps des refontes. De plus, en tant que version allégée de XML , le XHTML est en mesure d'assister les développeurs Web dans une transition en douceur vers un XML déployé à grande échelle par le biais d'un langage de balisage enrichi, promettant aux sites Web un plus grand degré d'interopérabilité.

Supporter l'accès

La première étape pour réaliser des sites Web accessibles consiste à vous assurer d'utiliser du XHTML bien-formé. XHTML remplace la recommandation pour le HTML 4, qui elle même, remplaçait celle pour le HTML 3 et ainsi de suite. Chacune de ces recommandations est basée sur les fondements de la précédente. De manière générale, XHTML 1.0 conserve les bons éléments de HTML 4 tout en se débarrassant des moins bons. Plusieurs des exemples présentés ici faisaient également partie de HTML 4 ; qu'importe, les développeurs devraient apprendre à utiliser les normes les plus récentes.

La documentation du W3C est rédigée par et pour des programmeurs et peut s'avérer difficile d'accès pour un lecteur inexpérimenté. Les développeurs apprennent, dans une certaine mesure, à utiliser directement les recommandations à partir du site du W3C, mais aussi plus fréquemment, par l'intermédiaire d'autres développeurs, d'articles ou de bouquins. (Pour un coup de pouce, consultez "Une rapide entrée en matière pour XHTML")

Un des exemples les plus évidents des standards du W3C concerne l'attribut alt de l'élément image qui constitue un pré-requis pour XHTML 1, tout comme ça l'était également pour les versions de HTML 4. Nous savons tous que pour qu'un site s'affiche convenablement dans un navigateur non-graphique comme les lecteurs d'écran JAWS ou Window-Eyes, il importe de fournir une alternative textuelle pour les images de manière à permettre l'affichage conforme de leur contenu. Le XHTML valide exige que la moindre image présente dans un document Web inclue systématiquement un texte descriptif laissant savoir à quoi correspond l'image en question. Voici à quoi ressemble le code :

<img src="tiger.gif" width="245" height="46" alt="Une photo d'un tigre courant dans les rues de la ville de New York." />

Ce qui assure ainsi à l'utilisateur ayant recours à un lecteur d'écran la réception d'une description précise de l'image en question.

Le XHTML requiert également que les entêtes, listes et autres balises structurelles soient utilisées de manière à ce que les interpréteurs des technologies d'assistance puissent être en mesure de parcourir un document cohérent au travers duquel l'information est logiquement organisée. Ce n'est qu'un exemple parmi tant d'autres de la manière par laquelle les développeurs XHTML peuvent être incités à écrire des documents bien structurés, lesquels deviendront par là même des pages Web plus accessibles.

Une fausse impression, qui circule parmi les développeurs Web, et plus particulièrement parmi ceux appartenant à la communauté des bibliothécaires, est qu'il est impossible pour un site d'être à la fois visuellement très attractif et complètement accessible. Rien n'est plus faux. En fait, plusieurs éléments de design sophistiqués —variations subtiles de couleurs, multimédia, recours aux images de grande dimension— qui sont rejetés par certains défenseurs de l'accessibilité peuvent s'avérer être des améliorations substantielles pour le grand public et ne diminuent en rien l'expérience de personnes aux prises avec des limitations physiques s'ils sont utilisés efficacement. Un site Web au design des plus élaborés, bâti en harmonie avec les standards et les principes d'accessibilité, sera toujours un site accessible.

Créer l'interopérabilité

L'accessibilité n'est pas la seule raison justifiant l'intérêt que les bibliothécaires devraient avoir pour les langages de présentation basés sur les normes. Après tout, les bibliothèques et les bibliothécaires se sont de longue date engagés dans la création et le support de standards qui encouragent l'interopérabilité, la compatibilité et le partage des ressources.

L'enregistrement MARC s'avère être une bonne analogie pour le balisage structurel. Pourquoi le nom de l'auteur figure-t-il toujours dans le champ 100 d'un enregistrement MARC ? Tout simplement parce que le champ 100 indique au système la manière par laquelle l'information au sujet d'un auteur doit être organisée afin d'être convenablement présentée dans une variété de modes de consultation, incluant les catalogues de cartes imprimées et les écrans d'ordinateurs. Pour des besoins plus sophistiqués, le champ 100 nous permet de construire des applications capables de limiter les paramètres de recherche. Quiconque a ressenti, à un moment ou un autre, le besoin de limiter la recherche dans un catalogue au seul champ Auteur sait que c'est une excellente idée. Enfin, la spécificité d'un enregistrement MARC permet la mise en œuvre de services spécialisés comme la recherche inter-catalogues.

Le Web serait un meilleur endroit pour tout le monde si les forçats du code réfléchissaient plus en termes de catalogue. Conservant en mémoire l'analogie du champ 100, pensez seulement à l'élément HTML <title>, l'endroit où vous pouvez écrire le titre de votre document. Voici un exemple :

<title>Digital Web Magazine</title>

La plupart des navigateurs Web affichent le contenu de la balise <title> dans le coin supérieur gauche du navigateur. Les moteurs de recherche affichent ce même contenu lorsqu'une page est invoquée dans un ensemble de résultats de recherche. À la lointaine époque de Netscape 1.0, lorsqu'un développeur écrivait plus d'un élément <title>, Netscape 1.0 réagissait en bouclant sur chacun d'eux, simulant ainsi une jolie présentation visuelle enchaînée.

<title>Magazine Digital Web</title>

<title>Un magazine pour les développeurs Web</title>

<title>Ne manquez pas cette fabuleuse opportunité</title>

Dès les premières heures de Netscape 1.0, les développeurs devinrent habitués à écrire du code destiné à fonctionner dans les navigateurs primitifs et développèrent même des astuces visant à tirer avantage des faiblesses de ceux-ci. La multiplication des éléments <title> est un exemple classique qui est entré dans l'histoire. La tradition des astuces HTML est forte et la très grande majorité du code que l'on retrouve sur le Web aujourd'hui s'inspire largement de ces abus créatifs. Ce type de balisage était amusant et créatif, mais il était aussi très mauvais pour le Web. Comment les moteurs de recherche, les outils d'indexation et de confection de catalogues pouvaient-ils espérer déterminer le véritable titre d'un document ?

Nous ne faisons pas de classification en fonction de l'apparence de nos entrées sur un système donné ; nous classons en fonction d'une norme. Nous sommes conscients des avantages à court et long terme d'une classification normalisée. Toutefois, nous échouons souvent à voir les mêmes utilisations et avantages dans les standards du Web.

Je vous l'accorde, l'enregistrement MARC n'est pas entièrement analogue au XHTML, mais lorsque l'imposante machine sémantique nommée XML remplacera XHTML, nos sites pourront être aussi puissamment structurés qu'un enregistrement MARC. Les appareils et les programmes seront en mesure de tirer plein avantage de cette structuration d'une manière qui rendra tous les bibliothécaires très heureux. Le XML rendra possible une structure qui permettra de grandes opportunités en matière d'interopérabilité et de recherches avancées.

Contrôler la mise en page

Tout aussi importants que puissent être les aspects d'accessibilité et de compatibilité, les économies substantielles en temps et en argent sont des raisons toutes aussi séduisantes d'adopter les standards du Web.

Le W3C a créé et développé un langage de présentation nommé Cascading Style Sheet. La première spécification CSS fut rédigée en 1996. À cette époque, le support CSS dans les navigateurs était un rêve à atteindre, mais avec l'évolution des CSS, le support dans les navigateurs s'est grandement amélioré. Nous sommes désormais dans une position où nous pouvons enfin commencer à profiter de ce puissant outil.

Par le passé, les développeurs Web créaient des mises en page HTML qui étaient contrôlées par des images transparentes, des astuces HTML et des balises de formatage. Pour refaire un site construit de cette façon, chaque image, astuce et page devait être rééditée. Les CSS permettent aux concepteurs de contrôler la mise en page de tout un site à partir d'un seul et même document centralisé : la feuille de style.

Les CSS permettent de contrôler tous les aspects du design d'un site : typographie, couleur et mise en page. Les CSS peuvent même être utilisées pour créer des effets de déroulement. Par exemple, une zone d'un document peut être programmée de manière à ce que le texte et la couleur de fond changent au passage de la souris du visiteur. Ce type d'effet est habituellement réalisé avec des images et du javascript, mais il peut être réalisé beaucoup plus simplement avec CSS, et ce avec beaucoup moins de lignes de code. Cet exemple n'est qu'un aperçu de ce qui peut être réalisé avec CSS. En contrôlant tous les aspects de présentation d'un site avec une seule feuille de style, les CSS offrent un niveau de contrôle inégalé sur la mise en page d'un document XHML et ce, avec un indice de bande passante incroyablement peu élevé.

Un meilleur rendement pour votre argent

Si vous utilisez XHTML pour structurer vos documents Web et CSS pour en assurer la présentation, la refonte de votre site pourrait être aussi simple que de retravailler votre feuille de style. Vous n'aurez plus besoin de revoir l'ensemble de votre code pour chacune des pages de votre site et vous économiserez ainsi à votre bibliothèque du temps et de l'argent.

Par exemple, lorsque la très populaire police de caractère Verdana commencera à présenter des signes de vieillissement. Il suffira de remplacer "Verdana" par "Georgia" dans la feuille de style et le changement s'opérera instantanément à travers tout le site. Les couleurs, mises en page, bordures, ainsi qu'à peu près tous les autres éléments de design peuvent ainsi être aussi simplement maintenus.

Les deux designs suivants, www.roguelibrarian.net/lj/one_a.html et www.roguelibrarian.net/lj/two.html, utilisent exactement le même balisage (la même information structurée), mais chaque version appelle une feuille de style différente.

Si vous devez modifier l'apparence de votre site, ou s'il ne s'affiche pas immédiatement de manière correcte sur une nouvelle plateforme, les ajustements nécessaires seront bien moins contraignants. Il y a d'ailleurs de bonnes chances pour qu'il vous suffise de modifier une ou deux feuilles de style, ou peut-être juste d'en créer une nouvelle.

Navigateurs et appareils du futur

Au cours des deux dernières années, les navigateurs Web sont passés d'un mode de rendu propriétaire à un mode de rendu basé sur les normes. Jusqu'aux navigateurs de leur version 4.0, Netscape et Internet Explorer affichaient les pages Web selon des moteurs de rendu qui leur étaient propres. Le moteur de rendu de Netscape supportait certaines balises, tandis que celui de Microsoft en supportait d'autres. Chaque moteur possédait également sa propre manière bien personnelle d'interpréter le code, les développeurs se retrouvant bien souvent dans une situation les obligeant à concevoir deux sites, l'un spécifique à Netscape, l'autre à Internet Explorer.

Avec l'avènement de Netscape 6 et Internet Explorer 5, le support des standards s'est considérablement amélioré, de sorte qu'il est très facile pour les développeurs de prédire sans crainte de se tromper qu'un XHTML basé sur les normes fonctionnera bien avec les versions courantes de ces deux navigateurs. Le support des standards était pitoyable dans les navigateurs de version 4 et les bibliothèques qui persistent à utiliser les navigateurs de cette génération devraient envisager de les mettre à jour dans le cadre d'une transition vers un support des normes.

Si vous construisez votre site avec les standards Web, vous pouvez être raisonnablement sûrs que ceux-ci s'afficheront convenablement dans les navigateurs futurs. Si vous réalisez qu'une mise en page est problématique sur la nouvelle version d'un navigateur, la solution impliquera un simple ajustement de votre feuille de style, et non du code de l'ensemble de votre document. Rappelez-vous que les PDAs gagnent de plus en plus en popularité comme moyen d'accéder au Web. Peut-être que les ordinateurs mobiles deviendront la norme. Si notre contenu est bien orchestré avec un balisage conforme aux normes, il aura de bien meilleures chances de s'afficher convenablement dans les appareils du futur.

Une rapide entrée en matière pour XHTML

XHTML et CSS remplacent HTML et son ensemble de balises de formatage. XHTML et HTML sont très similaires, et la transition de HTML vers XHTML n'induit qu'une petite courbe d'apprentissage et un nouvelle façon de penser. Quant à l'apprentissage de CSS, c'est un petit peu plus compliqué.

Voici donc une approche en trois parties pour adopter XHTML :

  1. apprendre quelles sont les différences entre HTML et XHTML ;
  2. réfléchir sérieusement à la structure du document ;
  3. soumettre vos pages au validateur XHTML.

HTML contre XHTML

Opérer la transition de HTML vers XHTML n'est pas si difficile que ça. En fait, il n'y a que cinq facteurs principaux à prendre en compte :

A. Assurez vous que toutes les pages débutent par le DOCTYPE et l' espace de noms adéquat.

Les documents XHTML doivent commencer avec une balise qui indique au navigateur comment les interpréter. Les pages Web de toutes les bibliothèques devraient commencer par la déclaration DOCTYPE suivante :

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

B. Ecrivez toutes les balises en minuscules.

HTML n'est pas sensible à la casse, mais XHTML l'est et demande à ce que tous les éléments <P> deviennent des éléments <p>, que les <TD> deviennent des <td>, et ainsi de suite. La plupart des éditeurs HTML vous permettront de définir l'écriture par défaut du balisage en minuscules.

C. Mettez tous vos attributs entre guillemets.

En HTML, vous n'avez pas besoin de mettre de guillemets autour des valeurs des attributs. Avec XHTML, celles-ci doivent être mise entre guillemets. Exemple : height="55" et non height=55.

D. Fermez tous les éléments.

En HTML, vous avez la possibilité d'ouvrir de nombreux éléments comme <p> et <li> sans avoir à les refermer. Mais en XHTML, chaque <p> doit être fermé par un </p>, et chaque <li> doit être fermé par un </li>.

E. Fermez les éléments "vides".

En XHTML, même les éléments vides comme <br> et <img> doivent être fermés en incluant un espace et une barre oblique à la fin de chacune de ces balises :

<br />
<img src="library.gif" />

Pensez à la structure du document

Comme tous les languages de balisage, XHTML est supposé donner une structure logique au document. Quand vous écrivez le code de vos documents, pensez en termes de plans traditionnels :

  • <h1>Sujet ou idée principale</h1>/
  • <p>Texte d'introduction.</p>
  • <h2>Sujet secondaire</h2>
  • <p>Texte du sujet secondaire.</p>

Évitez la tentation d'utiliser tous les éléments de formatage désapprouvés ou supprimés comme les balises <font> qui sont utilisées de manière erronée pour procurer une structure visuelle là où il n'existe aucune structure logique.

Ne faites pas ceci :

<p><font color="olive" size="7">Sujet ou idée principale</font>

Faites cela :

<h1>Sujet ou idée principale</h1>

Vous pourrez alors appliquer une feuille de style pour donner à l'élément <h1> un style particulier, de sorte qu'il s'affichera avec une couleur olive et une taille plus grande que celle du texte.

En balisant votre document, demandez-vous quelle information votre code enverra à l'appareil qui devra l'utiliser. Si vous vous retrouvez en train de créer une liste comme celle-ci :


un objet <br />
un autre objet <br />
un troisième objet <br />

Pensez plutôt à utiliser une liste ordonnée ou non ordonnée :

<ul>
<li>un objet</li>

<li>un autre objet</li>
<li>un troisième objet</li>
</ul>

La meta-information fournie par le balisage en apprendra plus à l'appareil qui va l'utiliser sur l'information qui lui est envoyée.

De plus, grâce à ce genre de liste, vous pouvez très simplement imbriquer des élements dans les autres :

<ul>
<li>un objet principal
<ul>
<li>un objet se rapportant au principal</li>

<li>unautreobjet se rapportant au principal</li>
</ul>

</li>
<li>un autre objet</li>
</ul>

Travaillez avec un validateur

La façon la plus rapide de vérifier votre code et d'apprendre XHTML est de valider vos pages. Le service de validation du W3C testera vos pages pour voir si celles-ci sont valides.

Comme le validateur d'accessibilité Bobby -un formulaire Web par lequel vous pouvez vérifier l'accessibilité de votre site- le validateur XHTML du W3C fonctionne aussi grâce à un formulaire Web. Passez votre URL dans la zone de saisie, sélectionnez Submit et le validateur testera votre page.

Si le document n'est pas valide, le validateur vous donnera une analyse des problèmes. Les premières validations peuvent être très frustrantes. Le rapport d'erreur est technique et identifie parfois la mauvaise erreur ; vous aurez peut être à faire un petit travail de détective.


http://libraryjournal.reviewsnews.com/index.asp?layout=article&articleid=CA232338&publication=libraryjournal

Fiche technique

À propos de l'auteur

Carrie Bickner travaille à la Bibliothèque Publique de New York en tant que Directrice Adjointe de la Bibliothèque Numérique. Ses nombreux projets et sa petite fille expliquent probablement pourquoi Carrie n’est pas souvent sur son blog, Rogue Librarian.

Articles similaires

Voici la liste des dix articles les plus récents en rapport avec cet article :

© 2001-2024 Pompage Magazine et les auteurs originaux - Hébergé chez Nursit.com ! - RSS / ATOM - About this site