Accessibilité d'un site Web

L'accessibilité d'un site dépend du webmestre et des outils qu'il ou elle utilise (CMS, éditeur de HTML, en particulier).

Bien que le Web ne manque pas d'informations sur son propre sujet, quelques rappels avec mise au point ne seront pas inutiles.

Qu'est-ce que l'accessibilité ?

Il vaut mieux avoir lu d'abord Faire un site : pour bien commencer

Rappel :

• Pour faire des pages Web il suffit d'un éditeur de texte et d'un navigateur.
• Pour écrire une page Web, on utilise une sorte de langage qui produit du sens et qui s'appelle HTML ou XHTML.

L'accessibilité est un ensemble de normes, qui n'ont portant pas de valeur officielle, élaborées pour permettre à tous, dans le monde entier, de voir les sites du Web sur des navigateurs variés et sur des types d'écran variés et malgré des handicaps visuels ou moteurs.

Pour cela, le World Wide Web Consortium (W3C), organisation internationale mais basée aux USA et fondée par l'Anglais qui a inventé le Web, Tim Berners-Lee, s'est chargée de mettre au point deux types de langage qui constituent une norme pour le Web. Ces deux types de code sont le HTML ou  son successeur le XHTML et les CSS qui sont bourrés de ressources et demandent un effort au webmestre et au développeur de logiciels pour le Web pour les connaître et savoir les exploiter.

À charge aux concepteurs de navigateurs et aux webmestres de suivre ces normes. IE ne les suit pas tellement et cela ne rend pas la tâche facile aux webmestres. Les autres navigateurs sont souvent en retard par rapport aux recommandations du W3C. Il faut en effet souligner que le W3C caracole avec ses versions de normes XHTML et CSS toutes fraîches bien en avance sur les navigateurs et sur les CMS (logiciels d'aide à la fabrication de sites web). Les webmestres ne peuvent donc pas toujours appliquer les normes les plus récentes — paradoxalement, leurs sites risqueraient d'être moins accessibles.

Il ne reste plus qu'à demander aux développeurs de votre navigateur préféré et de votre CMS préféré de faire le ménage. On aimerait bien que Firefox 3 affiche des animations au format ouvert SVG, basé sur XML, qui pourra remplacer Flash, format binaire souvent très lourd, et propriétaire.

L'accessibilité n'est pas une vague conformité à des normes rigides rebutantes. Elle demande pas mal de réflexion et de bonne volonté pour faire du Web un lieu accessible à tous les internautes. Ce n'est évidemment pas une tâche facile de combiner une apparence agréable et un contenu visible par tous.

L'accessibilité est maintenant une obligation pour les sites dits «publics» (gouvernements, institutions publiques, nationales, régionales, départementales ou territoriales). Il y a du boulot…

Et maintenant, en avant pour une excursion dans le monde du Web accessible !

HTML, XHTML

C'est une sorte de langage qui permet de transformer un texte en une page lisible sur le Web.

Le HTML est un nom générique, il en existe plusieurs versions. On est passé depuis longtemps au XHTML 1.1 strict qui est une évolution du HTML et qui n'est pas plus compliqué. De nombreux sites suivent la norme HTML 4.1 non strict (loose) ou transitoire (transitional).

Un exemple affreux de HTML se trouve dans l'article sur le HTML dans les emails. Un bon exemple de HTML sera plutôt ceci et vous voyez que c'est plus simple :

C'est un exemple très simple bien sûr (et une page minuscule, dont la partie HEAD est très incomplète). Vous voyez que c'est assez dépouillé.

Pour le vérifier, vous pouvez afficher ce bout de page dans votre navigateur :

• copier-coller le contenu du presse-papier  dans un éditeur de texte
• enregistrer le fichier sous un nom quelconque suivi de l'extension html

Si vous avez un bon éditeur de texte, le contenu sera affiché dans des couleurs variés  c'est le code qui est coloré pour que le ou la webmestre s'y reconnaisse mieux et évite les erreurs.

Ensuite, vous ouvrez ce fichier dans votre navigateur et voici une page HTML : le texte, le lien et le fond sont dans les couleurs de votre navigateur (par défaut ou modifiées), la police de caractère est sans doute du sérif (= avec empattements), celle de votre navigateur (par défaut ou modifiée).

Le HTML sert à structurer les éléments d'une page (titres, paragraphes, citations, etc.) et à leur donner un sens.

Ici, on voit bien le titre de niveau 1 (h1), les deux titres de niveau 2 (h2), les paragraphes (p) à l'intérieur de chaque partie (h2) et le tout dans la partie h1. Tout est organisé logiquement et les éléments s'affichent sur la page Web dans le bon ordre, c'est-à-dire l'ordre indiqué sur la page de texte HTML.

Dans les paragraphes, deux apparentes fioritures en italique («cite» et «em») sont là pour donner le sens du texte :

L'élément «cite» indique qu'il s'agit d'un titre de livre ou d'une autre référence. Cite ne veut pas dire citer des paroles (ça c'est «quote») mais faire une référence à un livre ou autre. Donc, ici on sait qu'il ne s'agit pas du héros Tintin mais de l'œuvre d'Hergé.

L'élément «q» (quote) affiche une citation entre guillemets. Ainsi, on sait que ce n'est pas l'auteur des pages qui parle mais Tournesol.

L'élément «em» affiche par défaut de l'italique comme ceci : un joli site. Ce n'est pas pour faire joli mais pour insister sur le mot «joli»: («em» = «emphasized» = «mis en relief», «mis en valeur»).

NB : Contrairement à ce qui s'écrit presque partout, le terme «balise» ne désigne pas un titre h1 par exemple mais la convention qui veut que pour être affiché l'élément doit être entouré de balises (tags) :

• balise d'ouverture, «start tag» : <h1>
• balise de fermeture, «close tag» : </h1>

Exception : les deux éléments image et saut de ligne.

C'est bien austère — et pour décorer et enjoliver sa page, alors ? Les CSS sont là pour ça !

Les CSS (feuilles de style en cascade)

CSS = Cascading Style Sheets = «Feuilles de style» (en cascades)

Le HTML s'occupe du sens et de la structure et les CSS de la présentation : disposer les éléments de la page sur deux ou trois colonnes, déterminer la couleur d'un menu, la couleur du texte, la typographie (taille des caractères et choix des polices de caractères), la couleur du fond de la page, et même le logo du site, mettre des guillemets à la française, afficher des chapitres précédés de leur numéro, sans avoir à taper les numéros, etc.

Exemple pour le titre de niveau 1a :

h1
{
  color:#ff9900;
  font-family:"Bitstream Vera sans", sans-serif;
}

CSS et HTML ne contiennent que des mots anglais avec l'orthographe américaine («color» et non «colour»).

Ici le titre h1 («h»= header = «titre») est orange et la police de caractère est indiquée à la suite de font-family (font = police de caractère) ; un choix est donné au navigateur (et/ou à l'internaute) parce que la première est typique du Libre et la deuxième est générique (n'importe quelle famille mais sans empattement = «sans-serif»).

Pour que l'effet produit par les CSS soit visible dans le navigateur, il faut bien sûr lier la page CSS à la page HTML.

Le XHTML est austère, et on peut lui rajouter des tas de fioritures avec les CSS; vous pouvez ainsi créer un autre titre de niveau 1 d'apparence différente en lui ajoutant un attribut et une valeur:
Côté HTML : <h1 class="joli">Titre 1</h1>
(attribut «class», valeur «joli»)

Côté CSS : h1.joli  {color:#ff9900;}

Les CSS2 très sophistiqués ne sont pas toujours bien interprétés par les navigateurs : ils ne les affichent pas ou les affichent de manière erronée. Les CSS évoluent plus vite que les navigateurs qui ont du mal à suivre le mouvement. IE est celui qui se donne le moins de peine, il n'a en rien l'énergie du Libre ni même celle d'un autre navigateur propriétaire comme Opera.

Les effets de la séparation HTML et CSS

Le HTML est clair, ainsi que la page. L'effet est impressionnant pour l'accessibilité d'un site.

Imaginez que vous visitez un site sur un navigateur qui n'affiche que du texte, c'est-à-dire qu'il n'affiche que la partie HTML. Le résultat est l'adéquation parfaite du HTML et du navigateur et une navigation agréable pour le visiteur.

Pour un aveugle «écoutant» un site (les pages d'un site peuvent être restituées par la voix) : le HTML est la seule chose qui lui est restitué. Si le HTML est désordonné et embrouillé, la restitution le sera aussi. Des indications de couleur, par exemple, ou de position du texte dans le HTML ne sont que des parasites.

Les CSS ne sont là que pour faire un site accessible à ceux qui peuvent voir un site sur un navigateur qui n'est pas que textuel et moins vieux que Netscape 4.5, et sur un écran d'ordinateur. Certains écrans miniatures ne prennent pas en compte les feuilles de style et ne sont pas adaptés pour afficher des colonnes. Ils lisent la page dans l'ordre indiqué par le HTML.

Questions d'accessibilité

L'accessibilité passe d'abord par la séparation du HTML et des CSS. Allons un peu plus loin dans cette histoire de sens et d'apparence.

Dans l'exemple plus haut, Les deux éléments XHTML («cite» et «em») qui affichent du texte en italique n'ont pas le même sens et pourtant ils rendent la même apparence. Dans un traitement de texte, l'italique indique l'insistance, un mot étranger, le titre d'un livre. Le lecteur comprend ces différences le plus souvent. Il reste que, traditionnellement, le titre d'un livre était souligné mais l'italique n'existait pas sur les machines à écrire mécaniques. Seuls les typographes avaient à leur disposition des caractères italiques.

En HTML pourquoi ne pas utiliser comme avant l'élément «i» (= italique) puisque de toutes façons c'est de l'italique que l'internaute voit sur son écran ? Cet élément «i» n'est plus permis en XHTML strict car il peut prendre des sens variés ; il est ambigu.

Si vous utilisez de l'italique il faut que cela ait un sens en XHTML. Si c'est pour faire un effet joli, ce sera dans les CSS qu'il faudra mettre de l'italique.

Pour les autres cas où l'apparence italique s'impose, il faut réfléchir au sens qu'elle doit avoir :

• l'élément «em» est là pour l'insistance
• l'élément «cite» est là pour une référence (titre de livre ou de film, etc.)
• l'élément «lang» permet d'indiquer que tel mot est de telle langue

Quelle importance ??

Un navigateur vocal (ou «logiciel de synthèse vocale») va devoir interpréter les mots qui apparaissent en italique. Il faut que le sens soit défini, pas seulement l'apparence. Si l'instrument est sophistiqué, il annoncera d'une certaine manière qu'il s'agit d'un titre de livre plutôt que d'un mot qui doit être prononcé avec insistance.

Autre exemple qui a heureusement perdu un peu de son côté tabou : les tableaux («tables», en anglais).

Les tableaux

Faire un tableau, c'est disposer du texte de façon synthétique et claire. Cela existe en HTML.

Le sens du tableau (sa valeur sémantique) est très souvent détourné par les webmestres et les développeurs de CMS pour en faire un simple outil : il sert alors à disposer des éléments sur la page qui devraient être disposés par l'intermédiaire des CSS. Ainsi, au lieu de faire des colonnes à l'aide des CSS, beaucoup de webmestres utilisent des tableaux.

C'est pourtant fastidieux à faire, cela alourdit la page : il y a souvent des tableaux imbriqués et il faut une cellule de tableau (une case) par élément à disposer. Tout ceci risque de produire un charabia incompréhensible.

Bien sûr, c'est en général invisible avec un navigateur sur un ordinateur (sauf quand la page s'affiche lentement). Mais comment se débrouille une machine vocale ? Vu comment la page s'affiche, colonne de gauche, panneau central, colonne de droite, il faut lire ce tableau colonne par colonne. Si la machine interprète le HTML comme étant un tableau de données, ce sera incompréhensible.

Les CSS sont très efficaces pour créer des colonnes et des blocs à l'intérieur des colonnes : la page est divisée en deux ou trois panneaux de largeur variable. Sur Libre-Fan les colonnes de droite affichent différents élément dont le menu, le panneau central le contenu de l'article mais la bannière est aussi mise en place par les CSS.

Validation de votre site

Quand on parle d'accessibilité d'un site Web on parle souvent de validation. Le W3C offre des outils de validation des pages Web, en ligne, pour le HTML, XHTML, CSS et les normes d'accessibilité (WAI). C'est très pratique car la liste des erreurs est accompagnée de quelques explications. Avec Mozilla-Firefox, vous pouvez installer une extension, Web developer, bourré d'outils d'analyse et de validation très utiles pour le webmestre.

La validation W3C n'est pas la garantie qu'un site est accessible. C'est simplement la garantie que le code HTML est conforme à la norme. Ainsi, une page pleine de tableaux utilisés pour la disposition des blocs sur la page (bandeau, menus, encarts, panneau central) passera à la validation s'il n'y a pas d'erreur dans le code qui sert à afficher des tableaux. La validation W3C analyse le code et non le sens ni la structure d'une page. Un outil ne remplace pas la pensée.

Vous pouvez très bien utiliser l'élément «cite» à la place de l'élément «em» : tous les deux sont valides et le validateur ne bronchera pas. Pourtant votre code est incorrect du point de vue sémantique et le HTML, ne l'oubliez pas, produit du sens.

Une énorme erreur trouvée dans le CMS SPIP, au moins jusque dans sa version 1.9, est le raccourci pour afficher un cadre qui peut être enjolivé mais qui en fait est un formulaire. Sur un navigateur textuel comme Lynx, on tombe dans un formulaire avec un champ à remplir qu'on ne peut remplir : c'est inattendu et cela n'a aucun sens car le but du raccourci n'est pas de faire un formulaire.

Les CMS ne sont pas toujours fautifs, les webmestres rajoutent parfois leurs erreurs. Utiliser l'élément HTML «blockquote» pour mettre du texte en relief est un non-sens car la signification de «blockquote» est «citation dépassant une ou deux lignes».

Orthographe et grammaire

Le respect de l'orthographe et de la grammaire améliore la compréhension de la page. Pour ceux qui peuvent lire un texte, les fautes ne sont pas des obstacles insurmontables : le cerveau arrive souvent à restituer le sens mais la lecture n'est pas fluide. Une restitution par une machine vocale se heurtera aux fautes et la navigation sera très désagréable pour l'internaute handicapé.

Imaginez que vous-mêmes vous lisiez le contenu d'une page Web à haute voix : à coup sûr vous hésiteriez parfois ou vous allez interrompre votre lecture d'un «c'est quoi ce truc ?», ou «Tiens, comment il écrit ça ?» ou encore «ah, c'était un verbe !». «Son article» : cela a un sens mais «sont article» est un non-sens (faute vue sur une page Web).

Mea culpa : je fais beaucoup de fautes de frappe et par la même occasion la grammaire en prend parfois un coup. Depuis que j'ai lu l'importance de l'orthographe pour l'accessibilité, je m'aide du correcteur orthographique de Firefox !

W3C-WAI (Web Accessibility Initiative)

Un navigateur visuel affiche une page avec des colonnes si le webmestre en a créé. Mais le HTML bien compris ne fait pas de colonnes. Donc sur un support n'affichant que le HTML, il n'y aura pas de colonnes: les menus seront au début de la page et seront suivis du contenu ou l'inverse (selon la structure HTML).

Mon ancien site Libre-Fan affiche d'abord les menus puis le contenu, ce qui n'est pas nécessairement agréable. J'ai donc rajouté des liens cachés sur un navigateur visuel et visible en affichage en mode textuel. On peut cependant les voir en passant la souris tout en haut des pages (au-dessous du titre du site vers la droite). J'en ai rajouté aussi en bas de page pour pouvoir remonter en haut de page et un autre caché pour aller au menu depuis le bas de page.

Accesskeys

Il faudrait donc rajouter des "Access keys" dans le code HTML : au lieu de déplacer la souris sur un lien et cliquer pour aller ailleurs, il est possible de passer par les touches du clavier que l'on détermine pour des liens essentiels de navigation. Voici des instructions extraites du site «Accès pour tous», qui a disparu :

• accesskey 0 = Politique d'accessibilité
• accesskey 1 = Accueil du site
• accesskey 2 = Aller au contenu
• accesskey 3 = Aller au menu
• accesskey 4 = Aller au formulaire de recherche
• accesskey 9 = Contacter le webmaster

Pour Firefox sous GNU/Linux : en principe c'est Alt-accesskey. Mais n'essayez pas sur ce site, ce n'est pas prêt.

Allez voir le site AccessiWeb et vous verrez qu'il reste du boulot pour faire qu'un site soit vraiment accessible. Validez vos pages comme le site vous l'indique et lisez les critiques que le validateur vous adresse. C'est instructif et cela fait réfléchir à la manière dont vous rédigez vos pages. On y trouve la confirmation de ce qui est dit dans cet article.

L'apparence n'est pas tout

Un site qui n'est fait que pour l'apparence peut être un désastre et le sera dans un futur très proche. Il existe beaucoup de sites qui sont pratiquement impossibles à afficher (lourdeur excessive, cadres envahissants, plein de Flash qui vous oblige à installer un plugin).

C'est le contenu d'un site qu'il faut privilégier et son bon affichage sur les différents supports — si le contenu n'est pas accessible, quel intérêt ? La présentation doit accompagner le contenu, même souligner son sens et sa structure pour les internautes qui peuvent le voir mais sans se substituer au sens et à la structure.

On en revient toujours au sens. S'en tenir à l'apparence («tout ce qui compte c'est que ça s'affiche comme je veux») est un leurre. Ce qui s'affiche doit correspondre au sens du contenu affiché.