Voir le Web autrement
Étude du W3Québec sur l'accessibilité des projets finalistes des OCTAS 2005
Sommaire
Le W3Québec a effectué une étude sur l'accessibilité des projets d'intérêt public qui figurent parmi les finalistes des OCTAS 2005 et en présente ici les conclusions.
Consulter le tableau général des résultats.
Introduction
Démarche
Depuis 1987, la Fédération informatique du Québec (FIQ) organise le concours des OCTAS, un événement très couru au Québec, car il vise à récompenser les meilleures réalisations dans le domaine des technologies de l'information (TI).
Environ 15 % de la population québécoise présente une limitation fonctionnelle susceptible de nuire à son expérience de navigation sur le Web.
Alors que les Directives pour l'accessibilité aux contenus Web existent depuis maintenant six ans, le W3Québec a voulu mesurer jusqu'à quel point les finalistes des OCTAS 2005 en ont tenu compte dans l'élaboration de leurs projets.
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, une page contenant un formulaire et une page présentant un tableau de données ont également été sélectionnées.
En tout, ce sont 38 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 de l'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 possible à modifier avec Internet Explorer sur 6 des 38 pages analysées. Soit dans 15,8 % 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 « Ne s'applique pas » si aucune image lien n'a été trouvée.
Résultat
Des images liens se trouvent sur 33 des 38 pages analysées. Les images liens sont correctement renseignées sur 12 d'entre elles. Soit, dans 36,4 % 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 17 des 38 pages analysées. Soit, dans 44,7 % 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 13 des 38 pages analysées ont au moins un titre identifié comme tel dans leur contenu. Soit, 34,2 % d'entre elles. Et seules 5 des 38 pages analysées font un usage logiquement correct des éléments d'en-têtes. Soit 13,2 % 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 « Ne s'applique pas » lorsque la page ne comporte aucun formulaire.
Résultat
Un formulaire existe sur 27 des 38 pages analysées, mais aucun n'associe explicitement 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 « Ne s'applique pas » lorsqu'il n'y a aucune image.
Résultat
Les images s'accompagnent d'un équivalent textuel sur 5 des 38 pages analysées. Soit dans une proportion de 13,2 %.
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'URL 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'URL 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
Aucune des 38 pages analysées n'est exempte d'erreurs de code HTML. Les deux meilleures n'en ont qu'une, alors que les deux plus mauvaises atteignent les marques peu enviables de 480 et 386 erreurs, respectivement.
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, toutes les pages analysées en font usage. La moitié d'entre elles ont un code sans faute, tandis qu'on compte de 1 à 25 erreurs chez les autres.
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
- 3 : la navigation peut se faire lorsque JavaScript est désactivé
- 4 : le contenu est structuré avec de véritables titres
- 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 (1) a systématiquement été accordé lorsque la priorité contrôlée se vérifiait; zéro (0) dans le cas contraire et « Ne s'applique pas » (NA) 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.
Les pages suivies d'un astérisque (*) contiennent des cadres et ont été analysées séparément, puis les résultats ont été additionnés. Les URL correspondent au contenu principal et les valeurs affichées, aux totaux.
| Nom du projet (catégorie) |
Page analysée | Cible prioritaire | Note | |||||||
|---|---|---|---|---|---|---|---|---|---|---|
| 1 | 2 | 3 | 4 | 5 | 6 | 7a | 7b | |||
| Progiciel de billetterie de la Place des Arts de Montréal (B2C) |
Accueil1 |  |
|
 |
|
|
|
8 | 1 | 1/7 |
| Contenu1 | |
|
|
|
 |
|
14 | 1 | 2/6 | |
| Tableau1 | – | – | – | – | – | – | – | – | – | |
| Formulaire1 | – | – | – | – | – | – | – | – | – | |
| Site Internet yoplait.ca (B2C) |
Accueil2 | |
|
|
|
|
|
40 | 9 | 1/7 |
| Contenu2 | |
|
|
|
|
|
44 | 9 | 1/7 | |
| Tableau2 | |
|
|
|
|
|
42 | 9 | 1/7 | |
| Formulaire2 | |
|
|
|
|
|
41 | 9 | 1/7 | |
| Refonte du site Internet de Desjardins Sécurité financière (B2C) |
Accueil3 | |
|
|
|
|
|
115 | 0 | 2/7 |
| Contenu3 | |
|
|
|
|
|
161 | 6 | 2/7 | |
| Tableau3 | – | – | – | – | – | – | – | – | – | |
| Formulaire3 | |
|
|
|
|
|
192 | 2 | 1/7 | |
| Association sur l'accès et la protection de l'information (e-Formation) |
Accueil4 | |
|
|
|
|
|
12 | 25 | 1/6 |
| Contenu4 | |
|
|
|
|
|
5 | 25 | 1/5 | |
| Tableau4 | – | – | – | – | – | – | – | – | – | |
| Formulaire4 | – | – | – | – | – | – | – | – | – | |
| passepart.ca (Français dans les technologies de l'information) |
Accueil5 | |
|
|
|
|
|
14 | 5 | 2/6 |
| Contenu5 | – | – | – | – | – | – | – | – | – | |
| Tableau5 | – | – | – | – | – | – | – | – | – | |
| Formulaire5 | – | – | – | – | – | – | – | – | – | |
| Parachèvement du site Internet de la STL (Français dans les technologies de l'information) |
Accueil6 | |
|
|
|
|
|
49 | 0 | 0/7 |
| Contenu6 | |
|
|
|
|
|
35 | 0 | 0/7 | |
| Tableau6 | |
|
|
|
|
|
262 | 3 | 0/7 | |
| Formulaire6 | |
|
|
|
|
|
26 | 0 | 0/7 | |
| Je Passe Partout : Refonte du site Internet et création d'un jeu interactif (Partenariat stratégique - OSBL) |
Accueil7 | |
|
|
|
|
|
62 | 0 | 1/6 |
| Contenu7 | |
|
|
|
|
|
157 | 0 | 0/6 | |
| Tableau7 | |
|
|
|
|
|
156 | 0 | 0/6 | |
| Formulaire7 | – | – | – | – | – | – | – | – | – | |
| Eurêka, un référentiel de ressources d'enseignement et d'apprentissage (Partenariat stratégique - OSBL) |
Accueil8 | |
|
|
|
|
|
11 | 1 | 2/7 |
| Contenu8 | |
|
|
|
|
|
1 | 1 | 2/6 | |
| Tableau8 | |
|
|
|
|
|
31 | 1 | 2/6 | |
| Formulaire8 | |
|
|
|
|
|
1 | 1 | 2/6 | |
| www.cegep-ste-foy.qc.ca/tim/2004/ (Relève collégiale) |
Accueil9 | |
|
|
|
|
|
9 | 0 | 3/7 |
| Contenu9* | |
|
|
|
|
|
56 | 0 | 2/6 | |
| Tableau9* | |
|
|
|
|
|
40 | 0 | 2/6 | |
| Formulaire9 | – | – | – | – | – | – | – | – | – | |
| Le Portail de la BNQ : Un accès unique à la culture et au savoir (Services gouvernementaux en ligne) |
Accueil10 | |
|
|
|
|
|
480 | 0 | 2/7 |
| Contenu10 | |
|
|
|
|
|
386 | 1 | 2/7 | |
| Tableau10 | |
|
|
|
|
|
377 | 6 | 3/7 | |
| Formulaire10* | |
|
|
|
|
|
311 | 13 | 2/7 | |
| Hydro-Québec : Diagnostic résidentiel Mieux Consommer (Services gouvernementaux en ligne) |
Accueil11 | |
|
|
|
|
|
67 | 0 | 1/6 |
| Contenu11 | |
|
|
|
|
|
33 | 0 | 1/6 | |
| Tableau11 | |
|
|
|
|
|
74 | 0 | 2/6 | |
| Formulaire11 | |
|
|
|
|
|
82 | 0 | 1/7 | |
| Gouvernement du Québec : Le Service québécois de changement d'adresse (Services gouvernementaux en ligne) |
Accueil12 | |
|
|
|
|
|
74 | 0 | 2/7 |
| Contenu12 | |
|
|
|
|
|
54 | 0 | 2/7 | |
| Tableau12 | |
|
|
|
|
|
29 | 0 | 1/7 | |
| Formulaire12 | |
|
|
|
|
|
6 | 0 | 3/7 | |
W3Québec : C.P. 58508, COP Complexe Les Ailes, Montréal, QC, Canada, H3B 5K8
Téléphone : +1 514.924.2401 | Courriel : decouvrir@w3qc.org
© 2003-2008, déposé sous licence CC, Paternité - Partage des Conditions Initiales à l'Identique 2.0 (Canada).