Le W3Québec a effectué une étude sur l’accessibilité des projets qui figuraient parmi les finalistes des Boomerangs 2005 et dont l’adresse Internet était… accessible! C’est le cas de 12 des 34 lauréats pour lesquels les conclusions sont ici présentées.

Consulter le tableau général des résultats.

Introduction

Démarche

Il y a 10 ans, les Éditions Infopresse lançaient un concours de communications interactives, connu aujourd’hui sous le nom de Boomerang. Très prisés dans l’univers des communications, du multimédia et des technologies de l’information, les Boomerangs ont attiré pour leur 11e édition plus de 330 pièces publicitaires interactives ainsi que des sites Web conçus par une centaine d’entreprises québécoises.

Sans pour autant remettre en question les critères d’évaluation ayant permis aux jurés issus des milieux professionnels de récompenser les meilleures réalisations dans chaque catégorie, le W3Québec a voulu mesurer jusqu’à quel point les lauréats des Boomerangs 2005 ont tenu compte des Directives pour l’accessibilité aux contenus Web, qui existent depuis maintenant six ans, dans l’élaboration de leur projet.

Méthodologie

Pour en juger, des membres du W3Québec ont examiné un échantillon de pages de chaque projet pertinent à la lumière des sept règles d’accessibilité qu’une étude menée par le directeur d’AccessibilitéWeb , Jean-Marie D’Amour, considérait comme prioritaire.

Seuls les projets dont l’adresse Internet était connue ont pu être analysés. Pour chacun, la page d’accueil a été évaluée et, dans la mesure du possible, une page de contenu et une page contenant un formulaire ou présentant un tableau de données ont aussi été sélectionnées. La page de garde, qui offre généralement un choix linguistique, a également fait l’objet d’une étude. En tout, ce sont 33 pages prélevées sur 12 projets qui ont été examinées.

Les critères retenus

La notion d’accessibilité

L’accessibilité pourrait se définir comme la capacité d’un site à être utilisé par tout le monde, sans discrimination. Ce qui suppose que les concepteurs ont pris les mesures nécessaires pour ne pas bloquer la compréhension du contenu ou l’usage des fonctionnalités aux personnes qui ont des limitations fonctionnelles ou qui sont aux prises avec des contraintes technologiques.

Par exemple, un site qui ferait reposer une information importante uniquement sur un code de couleurs ne permettrait pas à tous ceux qui, pour une raison ou une autre, ne perçoivent pas les couleurs, de consulter cette information. Il n’est qu’à penser aux personnes aveugles, mais il est également possible que certains daltoniens soient concernés. Il faut aussi tenir compte des internautes qui accèdent à un site via un logiciel de synthèse vocale, qui utilisent un navigateur en mode texte, disposent d’un écran monochrome ou ont simplement substitué leur propre feuille de styles à celle du site qui s’affiche.

Dans tous ces cas de figure, une information importante n’aura pu être perçue par certains groupes d’utilisateurs. Ce qui montre qu’un choix ou une manière de faire apparemment sans importance peut avoir des conséquences insoupçonnées au départ et s’avérer, dans les faits, un obstacle de taille à l’accessibilité d’un site.

Les 65 points de contrôle

La plupart des problèmes d’accessibilité peuvent être résolus en appliquant les règles contenues dans les Directives pour l’accessibilité aux contenus Web, un document faisant autorité et connu sous le nom de WCAG 1.0.

Les WCAG 1.0 contiennent 14 règles d’accessibilité, divisées en 65 points de contrôle, eux-mêmes classés selon 3 niveaux de priorité en fonction de leur importance et de leur effet sur l’expérience de navigation des utilisateurs.

Les 7 cibles prioritaires

Une étude menée en 2003 sur un échantillon de quelque 200 sites francophones du Québec et du Canada révélait que 7 de ces 65 points de contrôle présentent un intérêt particulier en raison de la fréquence des problèmes qu’ils sous-tendent, de l’importance de leur conséquence sur les utilisateurs et du coût relativement peu élevé associé à leur correction.

C’est à l’aune de ces sept points de contrôle que le W3Québec a mesuré le niveau d’accessibilité des pages à examiner.

Les résultats présentés par cible prioritaire

Parmi tous les projets à analyser, il est à noter que l’un d’entre eux ne pouvait l’être qu’à partir d’un des deux navigateurs supportés par le site, c’est-à-dire Netscape ou Internet Explorer.

Cible prioritaire nº 1 : définir la taille des textes affichés à l’écran avec des unités de mesure relatives

Explication

Un texte est essentiellement écrit pour être lu. Lorsque la taille d’affichage des caractères est trop petite, l’utilisateur peut théoriquement l’agrandir en modifiant les options d’affichage de son navigateur.

Ce qu’il n’est malheureusement pas possible de faire avec Internet Explorer lorsque les tailles de police ont été définies en pixels, en millimètres, en points, en picas ou en pouces, en raison d’un bogue dans ce navigateur. Or il s’agit du logiciel de navigation dont se servent près de 9 utilisateurs sur 10.

Méthodologie

Pour mesurer ce point de contrôle, il suffit d’ouvrir une page dans Internet Explorer et d’observer ce qui se passe en essayant d’agrandir la taille d’affichage des caractères à l’écran.

On accorde un point lorsque la taille des caractères change et zéro dans le cas contraire.

Résultat

La taille d’affichage du contenu principal de la page était modifiable avec Internet Explorer pour 4 des 33 pages analysées. Soit dans 12 % des cas.

Cible prioritaire nº 2 : fournir un équivalent textuel aux images liens et aux zones sensibles des images cliquables

Explication

Plusieurs groupes d’utilisateurs ne voient pas les images. C’est le cas des personnes aveugles ou fonctionnellement aveugles, ainsi que celles qui accèdent au Web depuis un navigateur en mode texte ou qui ont désactivé la prise en charge des images dans leur navigateur pour aller plus vite ou pour économiser sur leur bande passante.

Lorsqu’une image ou une portion d’image sert de lien, les règles de l’art de la conception Web veulent qu’on fournisse un équivalent textuel qui puisse en tenir lieu dans les cas où l’image ne serait pas perçue.

Lorsque ce travail relativement simple est bien fait, les logiciels de revue d’écran avec plage braille ou synthétiseur vocal lisent ou permettent de lire le texte de remplacement en lieu et place de l’image, tout en indiquant à l’utilisateur qu’il s’agit d’un lien. Dans le cas contraire, le lien est inutilisable, faute d’information.

Méthodologie

Ce point de contrôle peut être vérifié mécaniquement. L’outil d’analyse utilisé par le W3Québec renvoie le pourcentage d’images liens dépourvues d’équivalents textuels.

Pour mesurer ce point de contrôle, il suffit de noter le chiffre indiqué par l’outil d’analyse.

On accorde un point lorsque les images liens ont un équivalent textuel, zéro dans le cas contraire et « s/o » si aucune image lien n’a été trouvée.

Résultat

Des images liens se trouvent sur 22 des 33 pages analysées. Les images liens sont correctement renseignées sur 9 d’entre elles. Soit, dans un 27 % des cas.

Cible prioritaire nº 3 : offrir un système de navigation de remplacement pour tout système de navigation dépendant de JavaScript

Explication

L’accès à une donnée en cliquant sur un lien constitue l’un des grands atouts du Web. Cependant, cette possibilité peut être sérieusement compromise lorsqu’elle dépend de JavaScript ou d’une autre technologie de programmation côté client.

En effet, certains groupes d’utilisateurs naviguent sans JavaScript, et ce, pour diverses raisons : le parc informatique depuis lequel ils accèdent au Web leur impose cette restriction; ils en ont désactivé le support dans leur navigateur; leur navigateur ne leur en offre pas la possibilité; etc.

Parfois, l’obstacle est consécutif à la piètre qualité du script lui-même, conçu pour fonctionner dans tel navigateur à l’exclusion des autres.

Quoi qu’il en soit, les règles de l’art de la conception Web veulent qu’une solution de rechange soit offerte lorsqu’un moyen de navigation dépend du bon fonctionnement d’un script.

Méthodologie

Ce point de contrôle fait l’objet de deux questions.

La première, mécaniquement vérifiable, consiste à calculer le nombre de liens inutilisables sans JavaScript. Il suffit alors de noter le chiffre renvoyé par l’outil d’analyse.

La seconde doit être vérifiée manuellement et vise à déterminer si des mécanismes de navigation deviennent inutilisables sans JavaScript. Pour en juger, on accède à la page à vérifier avec JavaScript activé, puis une seconde fois après avoir désactivé le support de JavaScript dans le navigateur. Il ne reste plus alors qu’à comparer les possibilités de navigation offertes dans les deux cas et à noter les observations.

On accorde un point lorsque les liens et les mécanismes de navigation ne dépendent pas de JavaScript ou lorsque l’équivalent est offert en mode JavaScript désactivé, et zéro dans le cas contraire.

Résultat

Les liens et les mécanismes de navigation restent utilisables sans JavaScript sur 19 des 33 pages analysées. Soit, dans 57,5 % des cas.

Cible prioritaire nº 4 : structurer le contenu des pages avec de véritables en-têtes

Explication

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 n’en perçoivent qu’une partie à la fois. Il devient alors très difficile pour eux de se représenter la manière dont la page est construite ou de s’y déplacer pour trouver l’information qu’ils cherchent.

Lorsqu’une page ne comporte aucun titre ou lorsque ceux-ci ne sont pas identifiés dans le balisage comme étant des titres, les utilisateurs non voyants doivent parcourir toute la page pour se faire une idée sur son contenu. Imaginez une pleine page de journal sans titres ni sous-titres et vous aurez une idée de la difficulté à laquelle ils font face.

À l’inverse, lorsque les divers niveaux de titres et de sous-titres sont identifiés comme ils devraient l’être, c’est-à-dire avec des éléments h1 à h6, ceux qui font usage d’un logiciel de revue d’écran peuvent avoir une idée du contenu en consultant la liste des titres, et se déplacer rapidement de l’un à l’autre.

Méthodologie

Ce point de contrôle fait l’objet de deux questions distinctes.

La première, mécaniquement vérifiable, consiste à déterminer si la page contient ou non des titres identifiés comme tels. Dans un cas comme dans l’autre, il suffit de noter la réponse renvoyée par l’outil d’analyse.

La seconde permet de savoir si les titres sont correctement hiérarchisés. En l’absence de titres, la question ne se pose pas et l’on écrit NA pour « Ne s’applique pas ». Dans tous les autres cas, on consulte la liste des titres renvoyée par l’outil.

S’il n’y a qu’un seul titre et que celui-ci n’est pas de niveau 1, ou s’il y a plusieurs titres et que les niveaux de titres subséquents ne s’enchaînent pas de façon logique, on répond « non ».

Pour finir, on accorde un point lorsque le balisage des titres est logiquement correct, et zéro dans le cas contraire ou lorsqu’il n’y a aucun titre.

Résultat

Seules 10 des 33 pages analysées ont au moins un titre défini comme tel dans leur contenu. Soit, 30 % d’entre elles. Et seules 5 des 33 pages analysées font un usage logiquement correct des éléments de l’en-tête. Soit 15 % d’entre elles seulement.

Cible prioritaire nº 5 : associer explicitement les étiquettes et les champs de formulaire

Explication

Les formulaires ouvrent d’intéressantes perspectives aux utilisateurs. Mais à condition de pouvoir les remplir. Or cette tâche devient difficile, voire impossible, lorsqu’un non-voyant accède à un formulaire dont les étiquettes ne sont pas explicitement associées aux champs auxquels elles correspondent.

Lorsque la chose se produit, l’utilisateur peut savoir, par exemple, qu’il se trouve dans une zone de saisie de texte, mais il peut également n’avoir aucune idée du type de renseignement qu’il doit y inscrire. Ce pourrait aussi bien être son nom que son adresse ou son nº de client.

Ce genre de situation peut être évité en respectant simplement les règles de conception Web voulant qu’une étiquette de formulaire (par exemple, « Prénom ») soit, d’une part, identifiée comme telle via l’élément label et, d’autre part, explicitement associée au champ de formulaire auquel elle correspond via l’attribut "for".

Méthodologie

Ce point de contrôle peut être vérifié mécaniquement. L’outil d’analyse utilisé renvoie un chiffre indiquant le nombre d’étiquettes de formulaire qui ne sont pas associées explicitement. Nombre qu’il s’agit simplement de noter ensuite.

On accorde un point lorsque les étiquettes sont associées à leur champ de façon appropriée, zéro dans le cas contraire et « s/o » lorsque la page ne comporte aucun formulaire.

Résultat

Un formulaire existe sur 7 des 33 pages analysées, mais aucune page n’associe explicitement toutes les étiquettes aux champs correspondants.

Cible prioritaire nº 6 : fournir un équivalent textuel aux éléments graphiques ayant une valeur significative

Explication

Certaines images n’ont qu’une fonction esthétique, alors que d’autres ont une valeur informative. Lorsqu’une image est porteuse d’information, les règles de l’art de la conception Web veulent qu’on y associe un équivalent textuel capable de renseigner adéquatement ceux qui, pour une raison ou une autre, ne voient pas les images.

En l’absence d’un tel texte, l’utilisateur qui ne voit pas l’image peut savoir qu’il y en a une, mais il n’a aucune idée de son rôle ou de sa signification. Les histogrammes, les graphiques et les phrases du genre « voir l’illustration ci-contre » n’ont alors aucune signification pour lui.

Méthodologie

Ce point de contrôle a été vérifié mécaniquement. L’outil d’analyse utilisé détecte les images dépourvues d’attribut "alt" et en retourne le nombre, exprimé en pourcentage.

Il est possible de pousser l’analyse un peu plus loin en allant vérifier si le texte de substitution prévu est ou non pertinent. En la présente, le W3Québec a préféré en rester au stade du simple constat.

On accorde un point lorsque la page contient des images dont les attributs "alt" ont été renseignés, zéro lorsque les attributs "alt" sont manquants et « s/o » lorsqu’il n’y a aucune image.

Résultat

7 des 33 pages analysées échouent cette analyse. Soit dans une proportion de 21 %.

Cible prioritaire nº 7 : utiliser du code et des feuilles de styles valides

Explication

Bien que la plupart des navigateurs soient conçus pour être tolérants aux erreurs de code, il n’en reste pas moins que les logiciels d’adaptation, eux, ne le sont généralement pas. 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 logiciel et avoir des conséquences imprévues.

Méthodologie

Ce point de contrôle a fait l’objet de deux questions, toutes les deux vérifiables mécaniquement. La première vise à déterminer si le code HTML de la page est syntaxiquement valide. Pour en juger, il suffit de soumettre l’URI de la page au validateur HTML du W3C et de noter le nombre d’erreurs retourné par l’outil.

Il faut parfois procéder à une revalidation du code, si aucune indication sur l’encodage de la page n’est spécifiée et que le validateur ne parvient pas à déduire l’encodage utilisé. Il suffit alors de passer en mode « interface étendue », de choisir un encodage iso-8859-1 est presque toujours le bon et de revalider.

La seconde question vise à déterminer si le code CSS de la page est syntaxiquement valide. Pour en juger, on a recours au validateur CSS du W3C. La plupart du temps, il s’agit de soumettre l’URI de la page au validateur et de noter le nombre d’erreurs retourné.

Lorsque cette technique ne fonctionne pas, il faut commencer par éditer la ou les feuilles de styles de la page. Ce qu’on peut faire en parcourant CSS > Voir les CSS depuis la Barre d’outils pour développeur Web de Chris Pedderick. On effectue ensuite un copier-coller du code dans la section « Validation par saisie directe » du validateur CSS du W3C, puis on totalise le nombre d’erreurs détectées par l’outil.

Résultat

2 des 33 pages analysées sont exemptes d’erreurs de code HTML, la pire atteignant 332 fautes.

On aura beau minimiser la chose en reportant ces résultats sur le nombre total de lignes de code dans la page, en faisant valoir qu’il s’agit d’erreurs redondantes ou que certaines d’entre elles ont un effet domino, il n’en demeure pas moins que de pareils résultats sont tout de même des indicateurs du peu d’importance accordée à la validité syntaxique du HTML.

Quant au code CSS, 28 pages sur les 33 analysées en font usage. 21 d’entre elles ont un code sans faute, tandis qu’on compte de 2 à 34 erreurs sur les 7 autres pages.

Tableau général des résultats

Remarques

Chacune des « cibles prioritaires » dont il est question dans le tableau, étant expliquée en détail ci-dessus, il s’agissait donc de vérifier si :

• 1 : la taille des textes est extensible dans Internet Explorer
• 2 : les images liens ont un équivalent textuel
• 3a : le nombre de liens inutilisables sans javascript
• 3b : la navigation peut se faire lorsque JavaScript est désactivé
• 4a : le contenu est structuré avec de véritables titres
• 4b : les en-têtes (H1-H6) sont imbriqués de façon logique
• 5 : les étiquettes de formulaire sont explicitement liées à leurs champs
• 6 : les images ayant une valeur significative ont un équivalent textuel
• 7a : le code HTML est valide
• 7b : le code CSS est valide

L’outil d’analyse utilisé a spécialement été mis au point pour aider à l’évaluation des points de contrôle susnommés. Il est à la disposition de quiconque voudrait s’en servir.

Un point () a systématiquement été accordé lorsque la priorité contrôlée se vérifiait; zéro () dans le cas contraire et « Ne s’applique pas » () lorsqu’il était sans objet.

Les valeurs des colonnes 7a et 7b expriment le nombre d’erreurs HTML et CSS, respectivement.

La Note figurant dans la dernière colonne correspond au nombre de points de contrôle vérifiés sur le nombre de points de contrôle applicables.

Fait par Normand Lamoureux le 1er janvier 2006 pour le compte de W3Québec. Ont fait partie de l’équipe des analystes et réviseurs : Christophe Bélanger, Mathieu Chartier, Normand Lamoureux, Benoît Meunier et Catherine Saguès.