Sept pas vers l’accessibilité

Ou comment améliorer d'une manière significative l'accessibilité d'un site Web

Par Normand Lamoureux, 15 août 2005

Résumé

Ce guide vise à présenter au néophyte les règles essentielles d'accessibilité. Il en explique le bien-fondé et illustre leur mise en œuvre à travers des exemples.

Sommaire

• Entrée en matière
• Premier pas : définir la taille des textes à l'écran avec des unités de mesure élastiques
• Deuxième pas : fournir un équivalent textuel aux images liens et aux régions sensibles des images à zones cliquables
• Troisième pas : offrir une alternative à tout système de navigation dépendant de JavaScript
• Quatrième pas : structurer le contenu des pages avec de véritables en-têtes
• Cinquième pas : associer explicitement les étiquettes et les champs de formulaire
• Sixième pas : fournir un équivalent textuel aux éléments graphiques ayant une valeur significative
• Septième pas : utiliser du code et des feuilles de styles valides
• Conclusion

Entrée en matière

La notion d'accessibilité

Si la plupart des individus accèdent au Web via un écran d'ordinateur, une souris et un clavier, ce n'est pas le cas de tous.

Certains naviguent en effet depuis un téléphone cellulaire ou un assistant numérique personnel. Ils ont un petit écran et pas de souris. D'autres accèdent au contenu des pages aidés d'un logiciel de grossissement. Ils ont un écran, mais aucune vision globale de la page. D'autres, enfin, naviguent en mode braille ou en mode synthèse vocale. Ils n'ont ni souris ni écran.

Sur le Web, la diversité des conditions de navigation dans lesquelles se trouvent les utilisateurs n'est pas l'exception, mais la règle. Aussi est-il nécessaire de produire des contenus utilisables par un grand nombre de personnes dans un grand nombre de situations. En un mot, il est nécessaire de produire des contenus accessibles.

Les 7 cibles prioritaires

Rendre un site accessible n'est pas une mince affaire. Les Directives pour l'accessibilité aux contenus Web 1.0, document de référence incontournable en la matière, comptent 14 règles subdivisées en 65 points de contrôle, à leur tour classés selon 3 niveaux de priorités. Un document complémentaire, intitulé Techniques pour les règles d'accessibilité du contenu Web 1.0, a même été rédigé pour venir en aide à ceux qui voudraient savoir comment s'y prendre pour mettre en application les recommandations qui y sont faites.

Chacun de ces 65 points de contrôle a son importance et tous les sites Web sont invités à s'y conformer. Certains sont cependant plus significatifs que d'autres et les connaître permet au moins de savoir par où commencer.

En 2003, une analyse détaillée de quelque 200 sites francophones du Québec et du Canada permit à AccessibilitéWeb de dresser une liste des points de contrôles jugés prioritaires. Cette liste fut établie en tenant simultanément compte de la fréquence du problème, de son impact sur la navigation des personnes ayant des limitations fonctionnelles et de son coût de correction.

Je me propose de reprendre un à un les éléments de cette liste, d'en expliquer le bien-fondé et de montrer comment ils peuvent servir de point de départ à un programme visant à améliorer progressivement l'accessibilité d'un site Web. D'où le titre : sept pas vers l'accessibilité.

Premier pas : définir la taille des textes à l'écran avec des unités de mesure élastiques

Explication

Lorsque les caractères à l'écran lui apparaissent trop petits, l'utilisateur peut y remédier en modifiant les options d'affichage de son navigateur. Sous Internet Explorer, par exemple, il lui suffit de parcourir Affichage > Taille du texte et de sélectionner une taille plus importante, et le tour est joué.

Une solution semblable fonctionnera aussi dans les navigateurs alternatifs, comme Firefox, Netscape, Mozilla, Camino, Safari, Opera, etc.

Mais le problème est qu'elle ne fonctionnera pas avec Internet Explorer lorsque les tailles de police ont été définies en pixels. Or près de neuf utilisateurs sur dix se servent d'Internet Explorer et la plupart du temps, les concepteurs Web définissent leurs tailles de police en pixels…

Cependant, Internet Explorer acceptera d'agrandir la taille d'affichage des polices lorsque ces dernières ont été définies avec des mots-clés, en pourcentage ou avec des unités de mesure em — sur laquelle je reviendrai plus tard.

Mise en œuvre

Il faut donc éviter de définir les tailles de police en pixels et choisir une autre solution de remplacement. L'ennui est que ces solutions sont nombreuses et que toutes n'offrent pas les mêmes avantages. Aussi vais-je les passer en revue afin d'éclairer votre choix.

Utilisation des mots-clés

Le plus simple est de commencer par les mots-clés, que tout bon designer Web doit connaître. Il s'agit de xx-large, x-large, large, medium, small, x-small et xx-small. Donc un groupe de sept expressions, toutes en anglais, dans lequel se trouve trois tailles plus grandes que medium, trois tailles plus petites que medium et, bien entendu, la taille medium elle-même.

Le grand avantage des tailles de police définies avec des mots-clés vient est qu'on ne se soucie jamais du contexte dans lequel on les utilise. Large et x-large, par exemple, seront toujours définies par rapport à medium. De sorte que si la taille de medium change, toutes les autres tailles s'ajusteront en même temps. Ce qui assure une cohérence d'ensemble du premier coup.

L'inconvénient, vous l'aurez deviné, est qu'on ne peut connaître d'avance la taille de medium. Cette valeur a 16 pixels dans la plupart des navigateurs graphiques, mais c'est à condition que l'utilisateur n'en ait pas changé les options par défaut.

Comme tout dépend de medium, aussi bien dire qu'on n'aura aucune idée précise des tailles dans lesquelles les polices vont s'afficher sur l'écran des visiteurs. Il ne devrait pas y avoir de conséquence sur un design fluide, mais sur un design prévu pour s'afficher au pixel près, il peut réussir à le casser. Ce qui en fait un inconvénient de taille, si vous me permettez l'expression…

Largeur d'em et pourcentage

Il y a un intérêt pédagogique à traiter ces deux unités de mesure en même temps et la suite fera clairement comprendre pourquoi.

La largeur d'em — ou em tout court — correspond à la largeur du M majuscule dans une police donnée. Plus précisément, à la taille de cette lettre au moment où elle fut dessinée par son concepteur. Donc avant toute modification de taille.

C'est à partir de cette largeur que la taille des autres lettres et que les espaces entre les caractères seront calculés au moment d'agrandir ou de diminuer la taille de la police. De sorte que modifier la largeur d'em dans laquelle s'affiche une police revient à effectuer une modification proportionnelle sur l'ensemble de ses éléments.

Les pourcentages sont calculés par rapport à la largeur d'em. Ainsi, 100 % équivaut à 1 em, 90 % à 0.9 em, 120 % à 1.2 em, etc.

En théorie, il reviendrait donc exactement au même d'exprimer les tailles de police d'une manière ou d'une autre. Cependant, dans les faits, Internet Explorer fera varier plus rapidement la taille d'un texte défini en em qu'en pourcentage. En grossissement, la taille des polices définies en em va croître plus rapidement et, en diminution, décroître plus rapidement.

Dans les situations où vous voudrez limiter l'élasticité des tailles de police, comme dans une barre de navigation où l'espace disponible est souvent plus restreint, mieux vaudrait exprimer vos tailles de police en pourcentage. Même chose si vos tailles de police sont déjà petites et que vous ne voulez pas les rendre illisibles trop rapidement. Dans les autres situations, l'expression des tailles de police en em pourra très bien convenir.

Comment atteindre une taille précise en pixel

Il arrive qu'on doive atteindre une taille de police précise pour satisfaire aux exigences d'un design. L'usage des pourcentages risque alors de se révéler ardu. En effet, quelle valeur de pourcentage faut-il indiquer pour qu'une police s'affiche à 12 pixels? La réponse n'est pas évidente.

Heureusement, il existe une astuce qui permet d'établir une corrélation simple entre une valeur exprimée en pourcentage et une taille en pixel. Il suffit de ramener les tailles de police du body à 62,5 % de leur taille d'origine. Par défaut, la taille des polices d'un navigateur réglé à 100 % ou medium est en effet de 16 pixels. En ramenant les tailles de police comme on a dit, on ramène ces 16 px à 10 px, puisque 62,5 % de 16 donne effectivement 10. Une fois ce changement fait, 100 % vaut 10 px, 90 % vaut 9 px, 150 % vaut 15 px, etc.

La corrélation entre les valeurs en pourcentage et les pixels n'est pas très difficile à saisir et il devient plus facile d'obtenir la grosseur de caractère voulue depuis une valeur exprimée en pourcentage.

Précision n'est pas exactitude

En toute rigueur terminologique, une telle correspondance entre les pourcentages et les pixels n'est pas exacte. Pour la simple et bonne raison que la largeur d'em varie légèrement d'une police à l'autre. N'empêche que l'approximation à laquelle on arrive en suivant cette méthode est assez précise pour demeurer utilisable.

Pour plus de détails sur cette technique, voir l'article de Richard Ruter, How to size text using ems, ou la traduction française de Laurent Denis, Comment définir la taille du texte en ems.

Un écueil à éviter : l'héritage

Dans le langage de style CSS, on appelle « héritage » la propriété que les éléments parents ont de transmettre certaines de leurs caractéristiques à leurs descendants. Il s'agit d'une notion qui échappe à la plupart des débutants et à laquelle il faut prendre garde lorsqu'on manipule la taille des textes.

En clair, cela veut dire que la taille du texte d'un élément parent aura des répercussions sur celle de ses descendants.

Supposons un paragraphe dans un conteneur div au sein d'un document où la taille des textes est fixée à 100 %. Si vous fixez la taille de police de vos paragraphes à 90 % et que celle de votre conteneur div est elle-même fixée à 90 %, les paragraphes qui s'y trouvent ne s'afficheront pas à 90 %, mais à 90 % de 90 %, soit 81 %.

Le même raisonnement vaut pour les listes imbriquées, auxquelles il faut prendre particulièrement garde.

Le plus sage consiste donc à ne modifier vos tailles de police qu'en cas de nécessité et à visualiser vos pages à différents taux de grossissement pour vous assurer que l'héritage ne vous a pas joué de vilains tours.

Deuxième pas : fournir un équivalent textuel aux images liens et aux régions sensibles des images à zones cliquables

Explication

Il arrive qu'une image soit inscrite dans un lien. Les navigateurs graphiques afficheront l'image et l'utilisateur n'aura qu'à cliquer sur celle-ci pour suivre le lien.

Il est également possible de découper une image en plusieurs zones et d'associer les coordonnées de chacune à un lien. Le lien suivi dépend alors de la zone sur laquelle l'utilisateur clique.

Dans un cas comme dans l'autre, on suppose que l'utilisateur voit les images. Or ce n'est pas toujours le cas. Les personnes aveugles ou fonctionnellement aveugles ne les voient pas. Celles qui accèdent au Web depuis un navigateur en mode texte non plus, de même que celles qui ont désactivé la prise en charge des images dans leur navigateur. Certains utilisateurs en effet désactivent la prise en charge des images pour aller plus vite ou pour économiser leur bande passante. Ce peut être aussi bien des voyants que des non-voyants.

Il n'est pas nécessaire de renoncer aux images pour satisfaire ces divers groupes d'utilisateurs. Il suffit juste d'associer un équivalent textuel aux images utilisées.

Les navigateurs graphiques sont en effet conçus pour afficher un texte de substitution lorsqu'il ne leur est pas possible d'afficher l'image. Idem pour les navigateurs en mode texte et les logiciels de revue d'écran. Dans tous les cas de figure, les utilisateurs auront au moins accès à l'information contenue dans ce texte. Si ce texte est suffisamment clair, ils auront alors une idée du contenu vers lequel pointe le lien et pourront décider de le suivre ou non.

À terme, personne ne sera mis de côté et tout le monde sera satisfait. Voyants comme non-voyants. En prime, votre page sera mieux référencée. Car les robots indexeurs tiennent compte du texte alternatif contenu dans une balise image.

Mise en œuvre

L'attribut alt des éléments img

En HTML, l'élément img dispose d'un attribut appelé « alt ». Cet attribut est si important que sa présence est requise pour la validité du code. Son rôle est justement de servir d'alternative à l'image. C'est donc là qu'il faut mettre l'équivalent textuel.

Ceci vaut aussi pour l'élément area, utilisé pour définir les parties d'une image à zones cliquables.

Pour jouer pleinement son rôle, l'équivalent textuel doit pouvoir se substituer à l'image et remplir la même fonction qu'elle. En gros, s'il s'agit de l'image d'un texte, utilisez ce texte comme équivalent textuel. S'il s'agit d'une image symbolique, indiquez le sens que vous lui accordez plutôt que de vous contenter d'une description. Par exemple, « Haut de page » fera mieux que « Flèche pointant vers le haut ».

L'attribut alt des éléments area

De même, si votre image à zones cliquables est une mappemonde, indiquez « Mappemonde » comme équivalent textuel. Les utilisateurs auront ainsi le contexte dans lequel s'inscrivent les zones cliquables. Si chaque zone correspond à un continent, servez-vous du nom de ce continent comme équivalent textuel. Les utilisateurs comprendront qu'en suivant le lien « Afrique », ils seront conduits à un contenu où il sera question de cette région du monde.

Il sera sans doute instructif de montrer à quoi peut ressembler le code de cet exemple. Voici :

<img src="…" alt="Mappemonde." usemap="#nomquelconque">
<map name="nomquelconque">
  <area shape="…" coords="…" href="…" alt="Amérique.">
  <area shape="…" coords="…" href="…" alt="Europe.">
  <area shape="…" coords="…" href="…" alt="Afrique.">
  <area shape="…" coords="…" href="…" alt="Asie.">
  <area shape="…" coords="…" href="…" alt="Océanie.">
</map>

Remarquez le point par lequel se termine le texte des attributs alt. Il forcera la synthèse vocale à marquer une pause. Les liens se démarqueront mieux et les utilisateurs apprécieront.

Le cas de l'attribut title

Au survol de l'image avec la souris, Internet Explorer affichera le texte de l'attribut alt sous forme d'infobulle. Cela ne devrait pas être, car selon les spécifications HTML, c'est l'attribut title qui devrait déclencher ce comportement et non l'attribut alt. C'est pourquoi les navigateurs conformes n'afficheront rien.

Si l'affichage d'un complément d'information sous forme d'infobulles vous intéresse, saisissez simplement le texte voulu dans un attribut title. En ayant un alt et un title, le comportement d'Internet Explorer deviendra soudain normal : le alt servira d'alternative à l'image et le title s'affichera sous forme d'infobulle. Comme c'est ce que les autres navigateurs font déjà, tout le monde sera bien servi.

Vous ne vous êtes pas trompés si vous avez compris que les textes du alt et du title peuvent être identiques ou différents. S'ils sont différents, assurez-vous que le texte du title ne contienne aucune information essentielle à la compréhension du lien. Car les logiciels de revue d'écran ne tiennent généralement pas compte des attributs title.

Le alt d'une image jointe à un texte dans un lien

Il arrive qu'on assemble une image et un texte à l'intérieur d'un même lien. On peut alors se demander s'il convient toujours de renseigner l'attribut alt de l'image.

La réponse est affirmative si l'image véhicule un complément d'information utile à la compréhension du lien. Dans le cas contraire, la réponse devrait quand même être positive, car une image avec un alt vide dans un lien sera jugée fautive par la plupart des outils d'évaluation automatiques.

Troisième pas : offrir une alternative à tout système de navigation dépendant de JavaScript

Explication

Au lieu de pointer directement vers une ressource comme une image ou un document HTML, l'activation d'un lien peut commander l'exécution d'un petit programme écrit en JavaScript. C'est ce qui se produit dans tous les cas de figure lorsqu'on fait pointer un lien vers un fichier JavaScript.

La plupart des menus déroulants qui se trouvent sur le Web fonctionnent avec JavaScript. Plus qu'un simple lien isolé, c'est alors bien souvent tout le système de navigation du site qui repose sur le fonctionnement de cette technologie.

JavaScript peut avoir de nombreux autres usages et, dans certains cas, contribuer à améliorer d'une manière significative l'expérience utilisateur. Mais là n'est pas la question.

Le problème vient du fait que certains groupes d'utilisateurs n'ont pas JavaScript. Ce peut être parce que le parc informatique depuis lequel ils accèdent au Web ne leur en offre pas la possibilité; parce qu'ils ont désactivé le support de JavaScript dans leur navigateur pour des raisons de sécurité ou autre; parce que le matériel ou les logiciels qu'ils utilisent ne supportent pas cette technologie; etc.

Lorsque le fonctionnement d'un lien ou d'un groupe de liens est assujetti à celui de JavaScript, mieux vaut donc prévoir une alternative. Autrement, plusieurs groupes d'utilisateurs seront irrémédiablement privés de leur usage.

Mise en œuvre

Comment fonctionne l'élément noscript

Outre l'élément script, le HTML dispose de l'élément noscript. Ce qui est intéressant, c'est que le contenu de cet élément ne sera pris en considération que si JavaScript n'est pas supporté. Cet élément fait donc partie de la solution à notre problème.

Un lien ou un menu de navigation dépend-il de JavaScript? La plupart du temps, mieux vaudra y renoncer, faire autrement ou chercher une solution équivalente côté serveur. Lorsque ce n'est pas possible, il suffit d'enchâsser un contenu alternatif entre deux balises noscript et le tour est joué.

Si le navigateur de l'utilisateur supporte JavaScript, le lien ou le menu de navigation mis en place fonctionnera comme souhaité. Sinon, c'est le contenu de l'élément noscript qui entrera en jeu. Ce qui s'y trouve sera utilisable sans JavaScript et les utilisateurs qui n'ont pas ce dernier pourront s'en servir.

Quoi mettre dans le noscript

Notez que le contenu alternatif en question doit offrir quelque chose d'équivalent. Selon les cas, cet équivalent sera un contenu similaire à celui vers lequel pointait le lien, mais présenté autrement, ou un groupe de liens offert comme alternative à un menu dynamique géré par JavaScript.

Dans le cas d'un menu déroulant, c'est l'ensemble des liens de ce menu qu'il faudra mettre en clair dans l'élément noscript. Dans le pire des scénarios, il s'agira de produire un texte expliquant à l'utilisateur que certains mécanismes de navigation de votre page dépendent de JavaScript et que vous n'avez malheureusement rien d'équivalent à lui offrir.

N'hésitez pas à décrire l'action de vos scripts. Même s'ils ne font rien d'extraordinaire. Cela rassurera toujours l'utilisateur de savoir qu'il n'a rien perdu d'essentiel.

Remarquez enfin qu'il n'est pas nécessaire de faire correspondre un noscript à chaque élément script. Il peut être utile d'avoir plusieurs noscript dans certains cas, mais la plupart du temps un seul suffit. On y met alors tout ce qu'il faut, d'un seul coup.

Quatrième pas : structurer le contenu des pages avec de véritables en-têtes

Explication

Il n'est pas rare de rencontrer des sites où les distinctions entre les divers niveaux de titres et de sous-titres reposent uniquement sur des artifices visuels, comme l'usage des majuscules, la grosseur des caractères, le gras, l'italique ou une combinaison de ces éléments.

Outre qu'il n'a aucun sens pour les non-voyants, cet usage typographique repose sur une méconnaissance du HTML. En effet, ce dernier dispose d'un jeu de balises spécifiquement conçu pour mettre en évidence les divers niveaux de titres et de sous-titres au sein d'un document. Ce sont les balises d'en-tête h1 à h6. En faisant usage de celles-ci, le document HTML sera mieux structuré. Résultat : on augmente ses chances de référencement et l'on facilite la vie à plusieurs.

Certains groupes d'utilisateurs n'ont pas une vision globale de l'écran. Soit parce qu'ils ne voient pas du tout ce dernier, soit parce qu'ils utilisent un logiciel d'adaptation à fort grossissement qui ne leur permet de voir qu'une fraction de page à la fois. Il leur est très difficile de se représenter la manière dont la page est construite et, ensuite, de s'y orienter ou de s'y déplacer pour trouver l'information qu'ils cherchent.

Lorsque la page est structurée avec de véritables en-têtes, ces mêmes utilisateurs en tirent profit. Leurs logiciels d'adaptation permettent en effet de consulter la liste des en-têtes contenues dans la page. Ce faisant, ils accèdent comme à une table des matières qui leur permet de se faire une idée rapide du contenu. Ce qui facilite d'autant leurs recherches.

Comme si ce n'était pas assez, vos chances de référencement seront aussi majorées. Si les logiciels d'adaptation sont capables de reconnaître les divers niveaux de titre et de sous-titre avec un balisage adéquat, il en est de même des robots chargés d'indexer le contenu des pages Web. Ces derniers accorderont plus de poids aux mots-clés contenus dans une balise d'en-tête que si les mêmes mots étaient inscrits en capitales grasses dans un paragraphe. Or qui dit plus de poids dit meilleure indexation.

Mise en œuvre

Les éléments h1 à h6 sont stylables

Le balisage des titres et des sous-titres d'une page devra se faire avec les éléments d'en-tête h1 à h6. Au lieu de baliser un titre avec une panoplie d'artifices visuels comme ceci :

<p><b><font size="7">Sept pas vers l'accessibilité</font></b></p>

on en indique simplement le niveau hiérarchique et c'est tout :

<h1>Sept pas vers l'accessibilité</h1>

C'est plus élégant, sémantiquement plus riche et beaucoup plus robuste ainsi.

Que vous n'aimiez pas le style par défaut des éléments h1 à h6 ne devrait pas vous empêcher de les utiliser. Modifiez plutôt leur apparence avec CSS. Par exemple :

h1 {
  padding:0.5em;
  font: bold 175% arial, helvetica, sans-serif;
  color: #900;
  background-color: #ffd;
}

Une fois vos en-têtes correctement balisés, vous pourrez les styler comme bon vous semble. Ils n'en perdront pas leur signification logique pour autant. Vous joindrez l'utile à l'agréable et tout le monde sera satisfait.

Imbriquer logiquement les en-têtes

L'élément h1 tient le plus haut rang. Il faut veiller à ce qu'il n'y ait qu'un seul h1 et à ce que son contenu reflète fidèlement le contenu principal de la page. Il y a de fortes chances pour que ce que vous y mettrez ressemble à ce que vous aurez mis dans l'élément title qui se trouve dans le head de votre document. Cela ne pose aucun problème.

Les éléments h2 à h6 se comportent comme les divisions d'une table des matières. On ne peut passer d'un titre supérieur à un titre inférieur en sautant des niveaux comme de h1 à h3 ou de h2 à h4. Par contre, il est possible de revenir à un titre supérieur quel que soit l'écart comme dans h4 à h2.

Cinquième pas : associer explicitement les étiquettes et les champs de formulaire

Explication

Le texte qui se trouve à proximité d'un champ de formulaire et qui indique le type de renseignement qui y correspond porte le nom d'étiquette. Si la plupart des concepteurs de pages Web pensent à doter leurs champs de formulaire d'une étiquette, rares sont ceux qui associent correctement les unes aux autres.

Plus de 9 fois sur 10 en effet, ces derniers se contentent d'associer les étiquettes à leurs champs au moyen de repères visuels, comme les espaces et le positionnement.

Cette façon de faire permet aux voyants de se tirer d'affaire, mais elle n'est d'aucune utilité aux personnes qui accèdent au formulaire depuis un logiciel de revue d'écran pour lequel les notions d'espace et de position n'ont aucun sens.

Lorsqu'un utilisateur non-voyant accède à un formulaire mal fait, il peut savoir, par exemple, qu'il se trouve dans une zone de saisie de texte, mais il peut n'avoir aucune idée du type de renseignements qu'il doit y inscrire. Ce pourrait être aussi bien son nom que son âge ou son adresse.

Ce peut même être pire. Car à défaut d'indications précises, certains logiciels de revue d'écran tenteront d'établir eux-mêmes les correspondances entre les étiquettes et les champs. Or ils ne sont généralement pas très doués pour jouer aux devinettes. Lorsqu'ils se trompent, ils induiront l'utilisateur en erreur en lui faisant croire qu'il se trouve dans un champ alors qu'il se trouve dans un autre. Les renseignements seront insérés aux mauvais endroits et, dans le pire des scénarios, le formulaire deviendra tout à fait inutilisable.

Mise en œuvre

Utiliser l'élément label conjointement aux attributs id et for

Ce genre de situation déplaisante peut être évité en associant explicitement les étiquettes à leurs champs. Ce qui se fait en trois étapes très simples.

La première étape consiste à affecter un nom propre chaque champ au moyen d'un attribut id.

La deuxième étape consiste à délimiter chaque étiquette avec des balises label, spécialement conçues à cet effet.

La dernière étape consiste à écrire dans l'attribut for de la balise label ouvrante le nom propre du champ auquel associer l'étiquette.

Concrètement, si au début le code ressemblait à ceci :

<p>
  Âge :
  <input type="text" size="2">
</p>

Après, il ressemblera à cela :

<p>
  <label for="age">Âge :</label>
  <input id="age" type="text" size="2">
</p>

Comment masquer le texte d'une étiquette

Il peut arriver qu'on veuille soustraire le texte d'une étiquette à la vue des utilisateurs voyants pour gagner de l'espace. C'est le cas pour la zone de saisie d'un formulaire de recherche à côté de laquelle se trouve un bouton « Rechercher » ou « Ok ».

La meilleure façon de faire est d'inscrire le texte à cacher dans l'attribut alt d'un GIF transparent d'un pixel par un pixel et de se servir de ce GIF comme étiquette. Le code pourrait alors ressembler à ceci :

<p>
 <label for="q">
  <img src="" width="1" height="1" alt="Rechercher.">
 </label>
 <input id="q" type="text" size="35"> <input type="submit" value="Ok">
</p>

En guise d'étiquette, les navigateurs graphiques n'afficheront qu'un pixel transparent, tandis que les logiciels de revue d'écran liront le alt de l'image. De cette manière, voyants et non-voyants y trouveront leur compte.

Sixième pas : fournir un équivalent textuel aux éléments graphiques ayant une valeur significative

Explication

Certaines images servent à faire du positionnement d'objet dans une page. On ne les voit généralement pas. D'autres images, dites « décoratives », n'ont qu'une fonction esthétique. Elles meublent harmonieusement l'espace, véhiculent des valeurs, créent une ambiance et contribuent d'une manière significative à embellir la page, mais ne sont pas porteuses d'un message qui s'adresse d'abord à la raison.

Ces types d'images n'ont pas besoin d'un équivalent textuel. Leur en mettre un aurait même pour effet pervers de noyer l'information dans un « bruit » aussi ennuyeux qu'inutile. Le mieux est de laisser ce genre d'images avec un alt vide, comme ceci : « alt="" ».

D'autres images, au contraire, ont une réelle valeur informative. Qu'il s'agisse d'un pictogramme, d'un diagramme, d'un plan ou d'un graphique, l'image sert alors nettement de véhicule à un type d'information qui peut être exprimé verbalement.

Ce genre d'images nécessite un équivalent textuel. Un texte de remplacement capable de se substituer à l'image et de véhiculer le même type d'information qu'elle, mais autrement, avec des mots.

En l'absence d'un tel texte, les groupes d'utilisateurs qui ne voient pas les images seront privés d'une information contenue dans la page. En leur en offrant un, au contraire, vous rendez vos images accessibles et en prime vous améliorez l'indexation de votre page. Car les moteurs de recherche tiennent compte de l'attribut alt.

Ce point s'inscrit dans la foulée de ce qui a été dit sur les images liens à la différence qu'il est maintenant question d'images tout court.

Mise en œuvre

Quoi mettre comme équivalent textuel dans un alt

Les GIF transparents et autres images invisibles utilisées pour faire du positionnement de contenu devraient avoir un alt vide « alt="" ».

Les images faisant office de puces devraient contenir un trait d'union « alt="-" » et celles qui sont utilisées comme séparateur horizontal une suite de deux, trois ou quatre traits d'union « alt="---" ». En mettre plus ne sera d'aucune utilité. Pire, certains logiciels liront tous vos traits d'union à la suite.

Notons que l'équivalent textuel devrait éviter de commencer par le mot « image ». Car le logiciel de revue d'écran avertit déjà l'utilisateur qu'il s'agit d'une image.

Les logos peuvent être identifiés comme tels. Par exemple, en indiquant « alt="Logo de XYZ.com" » ou « alt="XYZ.com – Logo" ». Si le logo est dans un lien qui pointe vers la page d'accueil, mieux vaut passer la présence du logo sous silence et mettre « Retour à la page d'accueil » comme texte de remplacement.

Quand et comment utiliser longdesc

L'équivalent textuel de certaines images peut ne pas pouvoir tenir en 10 ou 12 mots. C'est notamment le cas des organigrammes et des graphiques. Vous pouvez alors incorporer un attribut longdesc pointant vers une page explicative où vous disposerez tout l'espace voulu pour verbaliser la somme de données contenue dans l'image.

Le code à utiliser devra ressembler à ceci :

<img src="…" longdesc="http://XYZ.com/…/image1.html">

Retenez surtout que longdesc doit contenir l'URL du texte descriptif et non le texte descriptif lui-même.

Dans certains cas, les informations contenues dans l'image sont déjà présentes quelque part dans la page. Il suffit alors d'en avertir le lecteur. Par exemple, un graphique peut être suivi ou précédé du tableau de données ayant permis de le créer. Le texte de remplacement du graphique indiquera alors « Graphique illustrant les données du tableau qui suit ».

Le fait que la plupart des navitateurs en vogue ne supportent pas l'attribut longdesc ne devrait pas vous empêcher de l'utiliser. Car ce sont les non-voyants qui en ont besoin et les logiciels de revue d'écran en tiennent compte.

Septième pas : utiliser du code et des feuilles de styles valides

Explication

La plupart des navigateurs sont conçus pour être tolérants aux erreurs de code HTML et CSS. Reste que les logiciels d'adaptation, eux, le sont généralement beaucoup moins.

Il en découle qu'une page apparemment correcte dans un navigateur peut, dans les faits, comporter des erreurs de code qui poseront problème dans un autre type de logiciel et avoir des conséquences imprévues. Dans le pire des scénarios, la page sera complètement inutilisable.

En revanche, une page exempte d'erreurs HTML ou CSS laissera moins de place à des surprises du genre et se montrera beaucoup plus stable dans son comportement lorsque viendra le temps de la consulter depuis un téléphone cellulaire, une synthèse vocale ou un logiciel de grossissement.

Bref, un code sans erreur est gage de fiabilité, d'interopérabilité et de portabilité. En un mot, il est synonyme de robustesse.

Mise en œuvre

Il est fort peu probable que vous réussissiez à produire une page HTML valide du premier coup. Surtout si votre est longue ou complexe. Aussi vous faudra-t-il faire preuve d'un minimum de patience.

La première chose à faire sera de soumettre votre page au Validateur HTML du W3C. Avant de vous y précipiter, assurez-vous d'avoir fait débuter votre code par une ligne de Doctype.

Mettre un Doctype

Il existe plusieurs versions de HTML. Le Doctype sert à déclarer celle que vous utilisez. Sans une telle indication, le validateur n'aura aucune idée des règles à partir desquelles vérifier le code de votre document. Ces règles ne sont pas exactement les mêmes selon que vous utilisez HTML 4.01 ou XHTML 1.0, pour ne prendre que ces deux exemples.

Si vous ne connaissez pas la version de HTML que vous utilisez, il y a fort à parier que vous codez en HTML 4.01. Reste à savoir quelle « saveur » de HTML 4.01 vous utilisez.

Si vous faites reposer la structure de votre page sur un jeu de cadres (frames), voici la ligne de Doctype à mettre :

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Frameset//EN"
  "http://www.w3.org/TR/html4/frameset.dtd">

Si vous ne recourez à aucun cadre, mais que vous utilisez des éléments non recommandés ou « dépréciés », comme font ou center, utilisez la ligne de code suivante :

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
  "http://www.w3.org/TR/html4/loose.dtd">

Enfin, si vous n'utilisez aucun cadre ni élément ou attribut déprécié, voici la ligne de code à utiliser :

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
  "http://www.w3.org/TR/html4/strict.dtd">

Correction des erreurs HTML

Une fois votre document passé au crible, le validateur affichera la liste de vos erreurs. Il se peut qu'il y en ait beaucoup. Ne vous découragez pas. Certaines d'entre elles ont une sorte d'effet domino. De sorte qu'en en corrigeant une, vous en corrigerez plusieurs en même temps.

Commencez par corriger les premières en liste, puis descendez lentement et progressivement. C'est la meilleure façon de procéder.

Il se peut que vous ayez répété la même erreur plusieurs fois. Le validateur considérera néanmoins chaque occurrence comme une erreur distincte. Une fonction rechercher et remplacer peut alors être utile. Une fois que vous savez comment corriger votre erreur, vous saurez comment corriger toutes les autres qui lui sont semblables. Il vous suffit alors de lancer une opération de rechercher et remplacer pour les corriger toutes d'un coup. En procédant de la sorte, votre nombre d'erreurs diminuera rapidement.

Il se peut enfin que vous ne parveniez pas à corriger vous-mêmes toutes vos erreurs. N'hésitez pas à soumettre votre problème ou vos questions à des gens plus compétents qui vous feront partager leur savoir-faire. Deux sites francophones se révéleront alors bien utiles :

• le forum Alsacréations
• le forum Webmaster Hub

Correction des erreurs CSS

Les erreurs de syntaxe CSS sont relativement rares et faciles à corriger. Aussi n'est-il pas nécessaire de s'étendre sur le sujet.

La meilleure façon de vérifier le code de votre feuille de style est de le soumettre au Validateur CSS du W3C.

Conclusion

Ces sept pas comptent parmi les plus significatifs qu'on puisse faire dans un processus visant à améliorer l'accessibilité d'un site. Chacun a un effet important et immédiat sur l'expérience de navigation de plusieurs groupes d'utilisateurs. Certains auront même pour effet d'améliorer l'indexation de vos pages dans les moteurs de recherche.

Cependant, une fois que ces sept pas auront été franchis, vous ne serez pas pour autant au bout du chemin. Certes, le travail le plus urgent aura été abattu. Mais d'autres pas resteront à faire pour améliorer votre site et rendre vos pages encore plus accessibles. Les conseils et les explications détaillées mises à votre disposition dans la section formation en ligne d'AccessibilitéWeb vous seront alors des plus utiles.

Auteur : Normand Lamoureux.
Relectrice : Catherine Saguès.