Évaluation de l'accessibilité pour : Site Web

Avis : L'impression de ce document peut rencontrer des problèmes d'édition (par exemple : titre d'une colonne séparé sur 2 lignes mais sans tiret, tableau imprimé sur 2 pages, etc.) qu'il a été impossible d'éviter. Ainsi, il est recommandé d'en faire l'impression au format paysage plutôt qu'au format portrait.

Crédits

Cette évaluation a été réalisé le 18 juillet 2007. Réalisée à partir de l'information disponible sur le Web dans la deuxième semaine de juillet 2007, la présente évaluation a nécessité la participation des experts agréés suivants :

Coopérative AccessibilitéWeb
1751 rue Richardson, bureau 3.501
Montréal (Québec) H3K 1G6, Canada
http://accessibiliteweb.com

Téléphone : 514-312-3378
Sans frais : 1-877-315-5550
info@accessibiliteweb.com

Table des matières

Sommaire

L'objectif de l'évaluation était de déterminer si le site Web est conforme au standard d'accessibilité du World Wide Web Consortium (W3C).

L'évaluation avait également pour objet de :

Le rapport de cette évaluation comprend 11 recommandations afin d'aider les webmestres à améliorer l'accessibilité de leur site Web. Une démarche est aussi proposée.


1. Le contexte

En décembre 2003, AccessibilitéWeb, appuyée par le W3Québec et parrainée par la Fondation des aveugles et l'Institut Nazareth et Louis-Braille, publiait la plus grande étude sur l'accessibilité numérique jamais produite dans la francophonie. Dans cette étude, 200 sites Web canadiens d'intérêt public furent passés à la loupe pour en mesurer la conformité aux niveaux de priorité 1 et 2 des règles d'accessibilité provenant du document intitulé Web Content Accessibility Guidelines (WCAG) du groupe de travail Web Accessibility Initiative du World Wide Web Consortium (W3C).

À l'époque, 84 % des sites Web offraient un très faible rendement en ce qui concerne l'accessibilité. Pour un peu plus de 15 % des citoyens et citoyennes du Québec aux prises avec un handicap allant de léger à sévère (selon l'Institut de la statistique du Québec), c'était la confirmation que l'information sur le Web leur était difficilement accessible, voire inaccessible, une première véritable prise de conscience quant à la fracture numérique québécoise.

Cette étude avait notamment permis de circonscrire sept problèmes majeurs rencontrés sur presque tous les sites, problèmes par la suite présentés comme les sept cibles prioritaires, accompagnées d'une procédure didacticielle pour les corriger.

L'évaluation de ce site Web s'inscrit dans une démarche similaire.


2. La méthode suivie

Un échantillon de pages Web a été jugé suffisamment représentatif aux fins de l'évaluation. Établie par consensus entre AccessibilitéWeb et le client, la sélection comprenait des pages représentatives du contenu analysé, par exemple :

L'objectif de cette sélection de pages Web était de vérifier si les règles d'accessibilité étaient globalement appliquées. Dans ce contexte, l'évaluation d'au moins un tableau de données et d'un formulaire présentant des difficultés particulières et devant respecter des règles d'accessibilité précises permettait d'obtenir une idée assez juste de la situation pour l'ensemble des pages Web d'un site.

L'évaluation des sites Web a été effectuée à partir de ce qui était disponible au moment de l'analyse. Bien entendu, la présente évaluation exclut toute amélioration apportée ultérieurement à une page Web évaluée.

L'annexe 1 présente les détails relatifs à la méthode d'évaluation utilisée.

Le standard sur l'accessibilité du W3C utilise une échelle de priorités pour classer les règles par rapport à leur impact sur l'accessibilité. Ces priorités sont :

Cette évaluation a porté sur les recommandations du W3C relatives aux priorités 1 et 2 qui «doivent» ou «devraient» être appliquées par un site Web.

La présente évaluation tient compte à la fois du classement par priorités et de celui par critères, bien que ce dernier fasse partie de la version 2.0 du standard sur l'accessibilité en cours d'élaboration au sein du W3C.

L'évaluation s'appuie également sur les quatre caractéristiques recherchées, pour chacune des priorités 1 et 2, établies dans le standard du W3C. Ces caractéristiques sont décrites comme suit :


3. Les résultats globaux

3.1. Notes

Tableau des notes obtenues pour : Site Web
Titre Note pondérée sur 10 Mention Date de saisie
Site Web
Page d'accueil 9,29 Excellent (A) 16/07/2007
Page type de contenu 8,29 Très bon (B) 18/07/2007
Page avec tableau 8,49 Très bon (B) 18/07/2007
Page avec formulaire 7,57 Bon (C+) 17/07/2007
Moyenne 8,41 Très bon (B)  

Légende et contexte

Système de pondération

Les notes ci-dessus sont calculées sur 10 et prennent en compte les points de contrôle de priorité 1 et 2 .

Lors de l'évaluation, chaque question possède un poids différent exprimé en points. Une réponse négative à la question ne donne aucun point. Une réponse positive donne le maximum de points. Une question qui ne s'applique pas n'est pas considérée. Les questions à pourcentage donnent une valeur entre 0 et le nombre de points maximum. Le tout est ramené sur 10.

Mention

La mention globale d'un site traduit la moyenne des mentions individuelles des pages :

3.2. Résultats globaux

Tableau de résultat global pour : Site Web
Titre Perceptible
P1
Utilisable
P1
Compréhensible
P1
Robuste
P1
Perceptible
P2
Utilisable
P2
Compréhensible
P2
Robuste
P2
Site Web
Page d'accueil correct correct erreur erreur correct erreur correct correct
Page type de contenu erreur correct erreur erreur correct erreur erreur erreur
Page avec tableau correct correct erreur erreur erreur erreur erreur erreur
Page avec formulaire correct correct correct erreur erreur erreur correct erreur
Taux d'erreur 25 % 0 % 75 % 100 % 50 % 100 % 50 % 75 %

Puisque l'objectif de l'évaluation est de dénicher les aspects à améliorer en matière d'accessibilité, l'attribution du pointage lié à l'évaluation est basé sur le nombre d'erreurs relevées et non le nombre d'éléments corrects pour une page donnée.

3.3. Les résultats détaillés

Perceptible

Perceptible (Priorité 1)
Perceptible P1
Titre P1.1
Images-liens, boutons ou zones sans équivalents textuels
P1.1
Autres images sans équivalents textuels
P1.1
Longue description manquante
P1.1
Applet ou objet sans équivalent
P1.1
Fichier audio sans description
P1.3
Vidéo - piste visuelle non décrite
P1.4
Vidéo - sans sous-titres
P2.1
Consigne basée sur la couleur uniquement
Site Web
Page d'accueil correct correct correct correct correct correct correct correct
Page type de contenu correct 1 2 correct correct correct correct correct
Page avec tableau correct correct correct correct correct correct correct correct
Page avec formulaire correct correct correct correct correct correct correct correct
Taux d'erreur 0 % 25 % 25 % 0 % 0 % 0 % 0 % 0 %
Images, boutons ou zones sans équivalents textuels :
Une image, une image-lien ou une zone sensible d'une image cliquable doivent comporter un équivalent textuel donnant une brève description de son contenu ou de la fonction du lien. Sinon, les personnes aveugles n'auront accès qu'au nom du fichier image ou à l'adresse du lien, ce qui rendra le contenu peu ou pas compréhensible. Cette pratique permettra également d'indexer ce contenu par les moteurs de recherche et d'améliorer le positionnement du site. Par ailleurs, un élément graphique purement décoratif doit comporter une équivalent vide (alt="").
Longue description manquante :
Une image complexe comme un diagramme ou un graphique ne peut être décrite en 10 à 15 mots et doit donc offrir un lien vers une page qui donne une explication complète et équivalente. Sinon, les personnes ayant une limitation visuelle seront privées de ce contenu. Cette pratique permettra également d'indexer ce contenu par les moteurs de recherche et d'améliorer le positionnement du site.
Applet ou objet sans équivalent :
Outre les images, d'autres éléments externes peuvent être intégrés à une page Web comme des applets qui sont de petites applications ou des objets qui peuvent contenir une présentation Flash. Les applets ou les objets doivent offrir un contenu équivalent pour les utilisateurs dont les adaptations ne donnent pas accès à ces contenus. Cette pratique permettra également d'indexer ce contenu par les moteurs de recherche et d'améliorer le positionnement du site. Toutefois, les éléments purement décoratifs n'ont pas besoin d'une description.
Fichier audio sans description :
Un fichier audio doit être accompagné d'une transcription de son contenu textuel ou d'une description de son contenu sonore. Ce contenu équivalent peut être donné dans la même page ou dans une autre page liée. Sinon, les personnes ayant une limitation auditive seront privées de ce contenu. Cette pratique permettra également d'indexer ce contenu par les moteurs de recherche et d'améliorer le positionnement du site.
Vidéo dont la piste visuelle n'est pas décrite :
Une vidéo peut comporter de l'information purement visuelle qu'une personne aveugle ne pourra percevoir si elle n'est pas décrite de façon sonore. Cette description doit être synchronisée avec le déroulement de la vidéo.
Vidéo sans sous-titres :
Une vidéo contenant de la parole sans sous-titres ne peut-être correctement perçue par une personne sourde. Les sous-titres doivent être synchronisés avec le déroulement de la vidéo. Cette pratique permettra également d'indexer ce contenu par les moteurs de recherche et d'améliorer le positionnement du site.
Consignes basées sur la couleur uniquement :
Les personnes incapables de percevoir les couleurs ne pourront répondre aux consignes basées sur la couleur uniquement. Par exemple, il ne suffit pas de mettre en rouge les champs obligatoires d'un formulaire : cette information transmise par la couleur doit être également transmise d'une autre manière, par un symbole ou un icône notamment.
Perceptible (Priorité 2)
Perceptible P2
Titre P2.2
Contraste trop faible
P3.3
Sans feuille de styles CSS
P10.2 et P12.4
Étiquette de formulaire mal associée ou manquante
Site Web
Page d'accueil correct correct correct
Page type de contenu correct correct correct
Page avec tableau erreur correct correct
Page avec formulaire correct correct 5
Taux d'erreur 25 % 0 % 25 %
Contraste trop faible :
Pour un grand nombre d'utilisateurs n'ayant pas une bonne perception des couleurs ou présentant une limitation visuelle, un faible contraste rendra difficile ou impossible de percevoir le contenu.
Sans feuille de styles :
Toute la présentation du contenu (marges, couleurs, taille des caractères, etc.) doit être gérée par la feuille de styles CSS. Cela permet aux personnes ayant une limitation visuelle de contrôler la présentation du contenu selon leurs besoins en désactivant la feuille de styles ou en la remplaçant par une autre mieux adaptée pour contrôler le choix des couleurs, la taille des caractères et la disposition des éléments.
Étiquette de formulaire mal associée ou manquante :
Les auteurs Web doivent associer explicitement les étiquettes et les champs de formulaires. Sinon, les lecteurs d'écran en braille ou en synthèse vocale doivent jouer aux devinettes pour donner l'information aux utilisateurs aveugles, ce qui augmente le risque d'erreur et peut rendre un formulaire inutilisable.

Utilisable

Utilisable (Priorité 1)
Utilisable P1
Titre U5.1
Tableau de données sans en-têtes
U5.2
Tableau de données : en-têtes et données à associer
U7.2
Clignotement ou défilement invalides
U12.1
Cadres sans titres
Site Web
Page d'accueil correct correct correct correct
Page type de contenu correct correct correct correct
Page avec tableau correct correct correct correct
Page avec formulaire correct correct correct correct
Taux d'erreur 0 % 0 % 0 % 0 %
Tableau de données sans en-têtes :
Un tableau de données doit distinguer les cellules d'en-têtes des cellules de contenu. Pour une personne aveugle qui n'a pas une perception globale de l'écran et qui explore donc un tableau cellule par cellule, les en-têtes sont des points de repère essentiels pour donner un sens aux informations contenues dans les cellules de données et rendre le tableau utilisable.
Tableau de données dont il faut associer explicitement les cellules d'en-têtes et de données :
Les tableaux de données complexes comportant plus d'une rangée ou plus d'une colonne d'en-têtes doivent être codés de façon à associer explicitement chaque cellule de donnée avec tous les en-têtes correspondants. Sinon, une personne aveugle sera incapable d'établir ces liens et donc d'utiliser adéquatement ce tableau.
Clignotement ou défilement invalides :
Les balises HTML permettant de faire clignoter ou défiler l'information sont considérées comme invalides. De plus, le clignotement et le défilement rendent l'information difficile ou impossible à lire par les personnes ayant des limitations cognitives.
Cadres sans titres :
Les sites Web utilisant des cadres doivent leur donner un titre qui permet de bien comprendre leur fonction. Les personnes aveugles utilisant un lecteur d'écran en braille ou en synthèse vocale dépendent de cette information pour s'orienter et se déplacer à l'écran.
Utilisable (Priorité 2)
Utilisable P2
Titre U3.5
En-tête non ou mal utilisé
U3.6
Listes mal utilisées
U6.4 et U9.3
Scripts inaccessibles au clavier
U7.1 et U7.3
Mouvement distrayant
U7.4 et U7.5
Actualisation ou redirection automatiques à enlever
U12.2
Cadres mal expliqués
U12.3
Champs de formulaire à regrouper
U13.2
Titre de page non significatif
U13.3
Manque un plan ou une carte du site
Site Web
Page d'accueil erreur correct correct correct correct correct correct correct correct
Page type de contenu erreur correct correct correct correct correct correct erreur correct
Page avec tableau erreur correct correct correct correct correct correct erreur correct
Page avec formulaire correct correct correct correct correct correct erreur correct correct
Taux d'erreur 75 % 0 % 0 % 0 % 0 % 0 % 25 % 50 % 0 %
En-tête non ou mal utilisé :
La structuration d'une page à l'aide d'en-têtes de niveau 1 à 6 (H1 à H6) permet aux utilisateurs de lecteurs d'écran en braille ou en synthèse vocale d'accéder facilement au plan de la page et de se déplacer facilement à la section qui les intéresse. Cette façon de faire compense en partie le manque de vision globale de l'écran qui permet à un utilisateur voyant d'aller directement à l'information pertinente.
Listes mal utilisées :
Les listes sont un mode de structuration du contenu qui est très répandu sur le Web. Elles ne doivent pas être détournées de la fonction première pour obtenir seulement un effet de retrait.
Scripts inaccessibles au clavier :
Les scripts sont souvent utilisés pour illuminer les liens ou les images-liens, dérouler des menus ou afficher des informations contextuelles. Ces fonctions doivent être accessibles aussi bien au clavier qu'à la souris pour les utilisateurs qui sont incapables d'utiliser cet outil à cause de leurs limitations motrices ou visuelles. Cela est particulièrement vital quand les scripts permettent d'accéder à des nouveaux contenus quit resteraient autrement cachés à certains utilisateurs.
Mouvement distrayant :
Les personnes ayant des limitations cognitives peuvent être incapables de se concentrer sur le contenu de la page quand celle-ci présente du mouvement distrayant. Tout mouvement n'est cependant pas à exclure. Un mouvement doux ou lent est acceptable. Par contre, un clignotement rapide peut déclencher une crise épileptique chez certaines personnes.
Actualisation ou redirection automatiques :
Les pages qui s'actualisent ou se redirigent automatiquement ne laissent pas aux utilisateurs plus lents le temps de comprendre ce qui arrive. De même, un lecteur d'écran en braille ou en synthèse vocale reprendra la lecture au début de la page chaque fois que celle-ci est actualisée, ce qui rendra difficile ou impossible d'utiliser cette page.
Cadres mal expliqués :
Les sites utilisant des cadres doivent leur donner un titre significatif et ajouter une longue description de leur fonction lorsqu'ils dépassent un nombre de trois ou quatre. Il serait d'ailleurs préférable d'éviter de dépasser ce nombre.
Champs de formulaire à regrouper :
Les formulaires contenant une dizaine de champs ou plus devraient utiliser la balise HTML permettant de créer des sous-groupes. Ceux-ci créeront une structure qui en facilitera l'utilisation pour tous les visiteurs, mais qui sera particulièrement utile aux personnes qui n'ont pas une vision globale de l'écran.
Titre de page non significatif :
Les auteurs Web l'oublient parfois, mais un titre de page significatif est essentiel à l'orientation des visiteurs dans un site Web. Cette pratique bénéficie particulièrement à ceux qui ont une limitation visuelle ou cognitive.
Manque un plan ou une carte du site :
Un plan ou une carte du site est un autre moyen de faciliter l'orientation des visiteurs sur un site Web. Il peut aussi compenser pour un système de navigation comme des menus déroulants qui sont souvent inaccessibles aux utilisateurs ayant une limitation visuelle ou motrice les empêchant d'utiliser une souris.

Compréhensible

Compréhensible (Priorité 1)
Compréhensible P1
Titre C4.1
Changements de langue non identifiés
C14.1
Langage trop complexe
Site Web
Page d'accueil erreur correct
Page type de contenu erreur correct
Page avec tableau erreur correct
Page avec formulaire correct correct
Taux d'erreur 75 % 0 %
Changements de langue non identifiés :
La synthèse vocale utilisée par les personnes aveugles ou certains utilisateurs ayant des problèmes cognitifs comporte des phonèmes et obéit à des règles de prononciation qui sont propres à chaque langue. Quand les changements de langue sont identifiés adéquatement dans le code, la synthèse vocale peut prononcer correctement le contenu dans cette nouvelle langue.
Langage trop complexe :
Le langage utilisé doit être aussi simple que possible compte tenu du public visé. Cette simplicité du langage facilitera la compréhension des personnes ayant une limitation cognitive et des utilisateurs pour qui la page est dans une langue seconde.
Compréhensible (Priorité 2)
Compréhensible P2
Titre C10.1
Liens ouvrant une nouvelle fenêtre sans avertissement
C13.1
Liens manquant de sens
C13.4
Navigation non cohérente
Site Web
Page d'accueil correct correct correct
Page type de contenu erreur correct correct
Page avec tableau erreur correct correct
Page avec formulaire correct correct correct
Taux d'erreur 50 % 0 % 0 %
Liens ouvrant une nouvelle fenêtre sans avertissement :
Les liens ouvrant une nouvelle fenêtre du navigateur sans avertissement préalable sont une cause de désorientation et d'incompréhension pour un grand nombre d'utilisateurs ayant ou non des limitations. Cette pratique est encore plus problématique pour les personnes ayant des limitations visuelles ne leur permettant pas de les voir apparaître.
Liens manquant de sens :
Pour faciliter leur navigation, les utilisateurs de lecteurs d'écran en braille ou en synthèse vocale peuvent extraire la liste des liens de la page pour la parcourir plus rapidement. Toutefois, les liens n'offrant pas un texte significatif lorsque lus hors contexte deviennent incompréhensibles. C'est le cas notamment des liens répétant le même texte, mais conduisant à des endroits différents comme « pour en savoir plus » ou « pour lire l'article ».
Navigation non cohérente :
À l'intérieur d'un même site, les mécanismes de navigation doivent être cohérents d'une page à l'autre ou d'une section à l'autre. À défaut, cela créera de l'incompréhension chez de nombreux visiteurs, particulièrement ceux ayant une limitation visuelle ou cognitive.

Robuste

Robuste (Priorité 1)
Robuste P1
Titre R1.2
Image cliquable côté serveur sans liens redondants
R6.1
Page illisible sans la feuille de styles
R6.2
Cadre avec source invalide
R6.5
Cadres sans section NOFRAMES
R6.3
Contenu ou fonction inutilisables sans javascript
Site Web
Page d'accueil correct correct correct correct 1
Page type de contenu correct correct correct correct 1
Page avec tableau correct correct correct correct 1
Page avec formulaire correct correct correct correct 3
Taux d'erreur 0 % 0 % 0 % 0 % 100 %
Image cliquable côté serveur sans liens redondants :
Il est impossible de donner un équivalent textuel à une zone sensible d'une image cliquable côté serveur. C'est pourquoi les liens contenus dans cette image doivent être repris en liens textuels redondants. Si cela est possible, il serait encore mieux de convertir l'image cliquable côté client et d'y ajouter des équivalents textuels.
Page illisible sans la feuille de styles :
Bien que les règles d'accessibilité demandent d'utiliser les feuilles de styles CSS pour tous les effets de présentation du contenu (marges, couleurs, taille des caractères, etc), celui-ci doit demeurer lisible sans la feuille de styles parce que les utilisateurs ayant une limitation visuelle désactivent souvent la feuille de styles afin d'adapter la présentation du contenu à leurs besoins.
Cadre avec source invalide :
La source d'un cadre doit être une page HTML, car si une image est utilisée comme source d'un cadre, il sera impossible de lui donner un équivalent textuel.
Cadres sans section NOFRAMES :
La section NOFRAMES doit donner les titres et les liens vers chacun des cadres. Elle permet aux utilisateurs dont le navigateur ne supporte pas les cadres d'accéder au contenu de ceux-ci. C'est le cas de certains lecteurs d'écran en braille ou synthèse vocale de première génération.
Contenu ou fonction inutilisables sans javascript :
La programmation javascript est souvent utilisée pour créer des effets dynamiques comme des menus déroulants. Toutefois la plupart des lecteurs d'écran en braille ou synthèse vocale ne supportent pas cette technologie. En y ajoutant 13 % des utilisateurs qui n'ont pas accès à javascript ou l'ont désactivé, nous atteignons une proportion significative des internautes. Il faut donc ajouter une section NOSCRIPT donnant un contenu équivalent, reprenant, par exemple, les liens contenus dans les menus déroulants. Toutefois, cette section NOSCRIPT ne sera visible que si javascript est non disponible ou a été désactivé. Dans la plupart des cas, le problème des lecteurs d'écran est différent, car javascript est généralement activé. Il s'agit plutôt d'un problème d'accès aux contenus qui apparaissent dynamiquement. Il faut donc également offrir des liens redondants en bas de page ou, au minimum, un lien vers un plan complet du site qui est accessible sans javascript.
Robuste (Priorité 2)
Robuste P2
Titre R3.2
Erreurs de codage HTML ou CSS
R11.2
Codage déconseillé ou désuet
R3.7
Blocs de citation manquants ou invalides
R5.3 et R5.4
Tableaux de mise en pages illogiques ou invalides
R3.4
Mesures absolues plutôt que relatives
R3.4
Tailles de police fixes
R8.1 et R9.2
Applets inaccessibles
Site Web
Page d'accueil correct correct correct correct correct correct correct
Page type de contenu 1 correct correct correct correct correct correct
Page avec tableau 30 correct correct correct correct correct correct
Page avec formulaire 2 correct correct correct correct correct correct
Taux d'erreur 75 % 0 % 0 % 0 % 0 % 0 % 0 %
Erreurs de codage HTML ou CSS :
Certains navigateurs comme Internet Explorer sont extrêmement tolérants pour les erreurs de codage, ce qui encourage une certaine négligence chez les auteurs Web. Toutefois, des navigateurs plus accessibles ou des lecteurs d'écran en braille ou en synthèse vocale n'ont pas la même tolérance et les erreurs de codages créent souvent des problèmes d'accessibilité au contenu. Prendre l'habitude de valider le code avant de le mettre en ligne permet d'éviter ce genre de problème.
Codage déprécié ou désuet :
Les balises dépréciées ou désuètes, la balise FONT, par exemple, sont généralement utilisées pour contrôler la présentation de la page, ce qui devrait être laissé à la feuille de styles CSS. Cette façon de faire crée des contraintes de présentation qui ne peuvent être désactivées par les utilisateurs ayant une limitation visuelle afin d'obtenir un contenu plus lisible, d'où l'avantage de distinguer clairement le contenu et sa structure de sa présentation avec le feuille de styles.
Blocs de citation manquants ou invalides :
Les blocs de citations doivent être codés comme tels : cette balise ne doit cependant pas être utilisée à seule fin de mettre un paragraphe en retrait. Le bloc de citation contribue à structurer le contenu. La présentation d'un paragraphe en retrait qui n'est pas une citation peut être obtenue à l'aide de la feuille de styles. Les lecteurs d'écran en braille ou en synthèse vocale utilisent tous les éléments de structure pour aider l'utilisateur à s'orienter et à se déplacer dans un contenu qu'il doit explorer pas à pas, n'ayant pas une vision globale de l'écran.
Tableaux de mise en pages illogiques ou invalides :
Les tableaux sont souvent utilisés sur le Web pour disposer l'information sur plusieurs colonnes. On les qualifie alors de tableaux de mise en pages. Ceux-ci doivent demeurer logiques lorsqu'ils sont lus de gauche à droite et rangée par rangée, car c'est l'ordre de lecture d'un lecteur d'écran en braille ou en synthèse vocale. Dans les tableaux de mise en pages, il faut également éviter d'utiliser des cellules d'en-têtes qui sont réservées aux tableaux de données. À défaut, il sera difficile à l'utilisateur aveugle de distinguer entre les deux types de tableaux.
Mesures absolues plutôt que relatives :
Chaque fois que possible, il est préférable d'utiliser des unités de mesure en pourcentage. Cela permet notamment aux tableaux de s'adapter à la taille de la fenêtre ou à une plus grande taille des caractères. On qualifie ce type de design de fluide.
Tailles de police fixes :
Les unités de mesure des tailles de polices doivent être extensibles (en pourcentage, par exemple) pour s'adapter aux besoins des personnes ayant une limitation visuelle. Bien que la plupart des navigateurs récents offrent un zoom qui s'applique à toutes les unités de mesure, Internet Explorer, le navigateur ayant la plus grande part de marché (87 %), n'offre le choix qu'entre deux niveaux d'agrandissement des caractères qui deviennent malheureusement inopérants sur des caractères utilisant des mesures fixes comme les points ou les pixels.
Applets inaccessibles :
Les applets sont de petites applications qui peuvent être intégrées à une page Web. Comme il s'agit d'une application indépendante du reste du contenu, il faut s'assurer que cette application est compatible avec les outils d'adaptation comme les lecteurs d'écran en braille ou en synthèse vocale.

3.4. Les commentaires particuliers aux pages évaluées

Commentaires particuliers
Adresse et code Commentaires particuliers
Site Web (Commentaires globaux)

Structure

  • Les titres h6 devraient être de simples paragraphes. Hiérarchiquement, ces h6 n'ont pas de sens.

Équivalents textuels

  • Les alt ne peuvent être bilingues. Ils doivent être soit en anglais, soit en français car ils seront incompréhensibles avec une synthèse vocale.

Interactivité

  • La section noscript devrait inclure la phrase suivante en anglais: Cette page utilise des scripts à seule fin de mesurer sa fréquentation.

Navigation

  • Même si le site n'est pas très gros, il serait normal d'y trouver une fonction de recherche.

Compréhension

  • Le code de langue des pages doit être en et non eng. Tous les passages en français, y compris les alt, doivent être marqués avec l'attribut lang.
Page d'accueil

Évaluation fonctionnelle spécifique

Rien de plus à signaler.
Page type de contenu

Évaluation fonctionnelle spécifique

Rien de plus à signaler.

Commentaires spécifiques à cette page

  • Les deux diagrammes en pointe de tarte doivent conduire à une longue description.
  • Le contraste de Subscribe now to the Email Club n'est pas tout à fait suffisant (469 au lieu de 500).
  • Il faut laisser tomber l'attribut target ou inclure un avertissement dans le lien.
Page avec tableau

Évaluation fonctionnelle spécifique

Rien de plus à signaler.

Commentaires spécifiques à cette page

  • Les deux titres h3 devraient être des h2.
  • Le contraste de Subscribe now to the Email Club n'est pas tout à fait suffisant (469 au lieu de 500).
  • Il faut renoncer à l'attribut target ou inclure un avertissement à l'intérieur du lien.
Page avec formulaire

Évaluation fonctionnelle spécifique

Il faut mettre en évidence l'étape actuelle de façon non visuelle.

Commentaires spécifiques à cette page

  • La page Registration fees pose particulièrement problème.
  • Les sections introduites par un h3 devraient plutôt être encadrées par un fieldset, le h3 étant converti en legend.
  • Le bouton Back ne fonctionne pas.

4. Les constats et recommandations

La présente évaluation énumère des recommandations concrètes et précises (voir l’annexe 2 pour la liste complète). Ces recommandations permettront aux webmestres d'améliorer l'ensemble de leur site Web, plutôt que les seules pages évaluées.

De cet ensemble de recommandations, certaines doivent être mises d'urgence en application compte tenu non seulement de l'importance des problèmes à corriger, mais également de l'effort restreint requis et de la capacité des corrections à se répercuter automatiquement sur toutes les pages du site Web.

Les 5 recommandations principales sont :

IMPORTANT ! Bien que ces recommandations soient importantes, ce serait une grave erreur de penser qu'il ne suffirait que d'appliquer celles-ci pour corriger les problèmes d'accessibilité observés sur le site Web. En effet, bien que ces problèmes soient les plus généralisés, l'accessibilité d'un site Web se mesure globalement, par l'application de principes directeurs multiples. Il est donc crucial de corriger les problèmes relevés dans ces premières recommandations, mais également de s'occuper des autres décrites à l’annexe 2.


5. Conclusion

Il importe de ne pas perdre de vue qu'une démarche de mise en conformité, pour apporter des résultats satisfaisants sans pour autant décourager ceux qui s'y adonnent, doit être abordée de manière progressive et itérative. Il faut s'attaquer en premier lieu aux problèmes les plus répandus et les plus faciles à régler, ceux qui, par exemple, peuvent être réglés en modifiant les gabarits des pages. De telles erreurs, lorsque corrigées une fois, se traduiront par autant d'améliorations dans l'ensemble des pages. La loi de Pareto (80 % de résultats pour 20 % d'efforts) doit absolument être appliquée. Progressivement, vous passerez à travers la liste points par points et à chaque intervention, le site deviendra un peu plus accessible.

Lorsque l'on parle du droit équitable d'accès à l'information, il n'y a pas de note de passage à 60 %. Il n'y a qu'avec la perfection (soit 100 %) que l'on peut prétendre à la réussite de l'accessibilité. À cet égard, les webmestres doivent être encouragés et aidés à poursuivre sur la même lancée. [client] peut en effet encore améliorer de beaucoup l'accessibilité de son site Web pour être conforme au standard du W3C. De manière générale, si une diminution importante du nombre d'erreurs par caractéristique ressort de l’évaluation, il faut souligner qu’à peu près tous les types d'erreurs possibles sont toujours présents sur les sites Web, ce qui explique en partie les résultats.

Comme le site compte de nombreuses pages, prétendre s'attaquer à un élément et le maintenir jusqu'à épuisement des pages peut sembler décourageant. Si nous avons ici affaire à un système de gestion des contenus par contre, tous les espoirs sont permis (dans la mesure bien sûr où il serait possible d'intervenir à même l'outil et d'aller y modifier le code qui est généré).

Cette analyse relève la présence de types d'erreur d'accessibilité dans les pages, mais ne relève pas, dans la majorité des cas, le nombre d'erreurs pour chacun de ces types d'erreur car la donnée serait insignifiante devant le constat final. Cela peut donc vouloir dire que, dans certains cas, bien peu de travail est nécessaire pour renverser positivement la note attribuée, alors que, dans d'autres cas, il y aura bien plus de travail à accomplir pour arriver aux mêmes résultats. C'est d'ailleurs la réalité du cas par cas qui a incité à produire cette analyse sous sa forme actuelle. Une démarche analytique individuelle plus poussée pourrait permettre de déterminer les efforts des uns et des autres pour entreprendre avec succès un tel plan d'amélioration progressif.

La clé du succès réside en voir les quelques pages qui composent cette évaluation comme autant de gabarits représentatifs de l'ensemble des pages du site. En analysant les erreurs les plus fréquentes sur ces pages (voir les recommandations) et en comparant celles-ci avec les notes particulières propres aux pages spécifiques elles-mêmes, vous obtiendrez alors une idée assez précise des principaux problèmes à régler. Comme il n'y a pas forcément d'ordre idéal pour y arriver, il s'agit plutôt de regarder l'ensemble du travail à abattre et de vous dresser un plan progressif auquel vous tiendrez une fois celui-ci établi.

À l'aube du dépôt d'une proposition de standard portant sur l'accessibilité des sites Web de l’Administration québécoise pour les personnes handicapées, il serait judicieux d'inciter les webmestres visés par cette évaluation à entreprendre sans tarder une démarche de mise en conformité de l'accessibilité. Que la volonté individuelle des intervenants soit d'atteindre la conformité par rapport au standard du W3C et d'entreprendre un processus de certification ou simplement de faire tomber autant de barrières d'accès que possible, l'important reste de prendre conscience de la part de responsabilité qui incombe à chacun et de prendre activement part à la démarche d’amélioration.

Intégrer rapidement dans cette démarche une validation systématique des erreurs de code aidera toutefois grandement à prévenir les erreurs futures, tout en offrant un cadre pédagogique propre à l'amélioration des connaissances liées au HTML et aux CSS. À cet effet, le W3C offre une paire d'outils fantastiques qui permettent justement d'identifier toutes les erreurs présentes dans une page : les validateurs HTML et validateurs CSS. Jumellés à certains outil destinés aux développeurs comme la Web Accessibility Toolbar et la Web Developer Toolbar, ces outils vous permettront de mesurer bon nombre des éléments d'accessibilité à partir de simples clics.

Pour terminer, retenons qu'un encadrement normatif clair, la formation, l'aide à l'évaluation de la conformité, des outils adaptés et de l'accompagnement technique sont des avenues réelles de solutions intéressantes à court ou à moyen terme pour aider les webmestres à repousser leurs limites dans ce domaine.


Annexe 1. Détails relatifs à la méthode d'évaluation utilisée

Les règles d'accessibilité sont définies par le World Wide Web Consortium (W3C) et sont très largement adoptées par la communauté internationale. Dans un souci de simplification, la présente évaluation utilise le classement par critères de la version 2.0 des règles d'accessibilité des contenus Web de la Web Accessibility Initiative (WAI). Toutefois, puisque la version 1.0 demeure à ce jour la seule version officiellement reconnue, l'évaluation des points de contrôle s’y réfère directement.

Sans prétendre pouvoir régler tous les problèmes des internautes dont une limitation fonctionnelle est susceptible d'avoir un impact sur leur expérience du Web, ces règles d'accessibilité touchent tous les types d'incapacités, nommément les limitations visuelles, auditives, neuromotrices et cognitives. Menée selon les règles de l'art, la présente évaluation prétend être parfaitement représentative des critères de qualité édictés dans le document normatif du W3C.

IMPORTANT ! L'évaluation a été effectuée à partir des pages Web disponibles au moment de la saisie. À ce moment, des copies des pages évaluées ont été sauvegardées dans une base de données dans l’outil d'évaluation utilisé. Par un souci de rigueur, les références au code de ces sites portent sur les versions sauvegardées plutôt que sur les versions disponibles actuellement en ligne. Les évaluations portent donc sur ces pages, telles qu'elles étaient affichées à l'époque. Une modification effectuée ultérieurement n’a donc pas été prise en compte dans ce mandat.

Outil d'évaluation utilisé

Pour le succès de l'évaluation, la Coopérative AccessibilitéWeb a réutilisé l'outil développé par la même équipe d’experts pour l'évaluation de 2003. Bien que cet outil ait beaucoup évolué, tant sur le plan fonctionnel qu'ergonomique, il permet de traiter toujours les pages Web avec la même rigueur ; il s’appuie sur les 46 points de contrôle des niveaux de priorité 1 et 2 du standard d'accessibilité du W3C.

La principale amélioration a cependant été apportée à la méthode de pondération des différents points de contrôle, méthode dorénavant plus juste qu'elle ne l'était à l'époque. En effet, comme elle tient dorénavant compte de l'impact ou de l'importance d'un point de contrôle par rapport à un autre, les résultats, quant à l'aspect fonctionnel de l'accessibilité évaluée, sont plus justes que jamais.


Annexe 2. Liste complète des recommandations

En 2003, les sept recommandations principales pour corriger les principaux problèmes rencontrés étaient les suivants, en ordre d'importance :

  1. définir la taille des textes à l'écran avec des unités de mesure élastiques ;
  2. fournir un équivalent textuel aux images liens et aux régions sensibles des images à zones cliquables ;
  3. offrir une solution de remplacement à tout système de navigation dépendant de javascript ;
  4. structurer le contenu des pages avec de véritables en-têtes ;
  5. associer explicitement les étiquettes et les champs des formulaires ;
  6. fournir un équivalent textuel aux éléments graphiques ayant une valeur significative
  7. utiliser du code et des feuilles de styles valides.

Un coup d'oeil rapide à ces recommandations principales permet de constater toute la similitude avec les résultats de cette évaluation. À l'époque, la pertinence des cibles prioritaires avait été fondée sur :

Ces recommandations s'avèrent toujours appropriées aujourd'hui. S’y ajoutent d'autres recommandations qui couvrent l’ensemble des types de problèmes rencontrés, afin de permettre aux webmestres d'aller un peu plus loin dans leur quête d'amélioration de l'accessibilité.

En suivant l'ensemble des recommandations, les webmestres possèdent dès lors tout ce qui leur est nécessaire pour entreprendre leur propre démarche d'accessibilité.

Les recommandations qui suivent ont donc pour objet de proposer des pistes de solution pour enrayer les problèmes auxquels elles se rapportent. Il ne s'agit pas de fournir des exemples de correction pour chacune des recommandations, mais bien de définir la nature même des interventions à faire. Quoique cela ne soit pas très difficile à mettre en œuvre dans la plupart des cas, un minimum de connaissance ou de formation pourrait quand même être nécessaire pour arriver à s'y retrouver.

Voici la liste complète des recommandations pour un site Web davantage accessible :

Dernière révision du rapport : 02/12/2007 par Christophe Bélanger