É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 :
- Christophe Bélanger
- Jean-Marie D'Amour
- Vincent François
- Normand Lamoureux
- Denis Boudreau
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 :
- déterminer l'accessibilité des sites en les évaluant selon une grille de 46 points de contrôle tirés des niveaux de priorité 1 et 2 du Web Content Accessibility Guideline (WCAG) 1.0 ;
- mesurer si le site produit ou maintenu est plus apte à répondre aux besoins des utilisateurs handicapés ou vieillissants.
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 :
- la page d'accueil,
- une page de pivot ou de section,
- une page contenant un tableau de données,
- une page contenant un formulaire.
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 :
- Priorité 1 : Un développeur de contenu Web doit satisfaire à ce point de contrôle. Sinon, pour un ou plusieurs groupes, il sera impossible d'accéder à l'information du document. Satisfaire à ce point de contrôle est une exigence élémentaire.
- Priorité 2 : Un développeur de contenu Web devrait satisfaire à ce point de contrôle. Sinon, un ou plusieurs groupes auront des difficultés d'accès à l'information du document. Satisfaire à ce point de contrôle lèvera certaines barrières empêchant l'accès aux documents Web.
- Priorité 3 : Un développeur de contenu Web peut respecter à ce point de contrôle. Sinon, un ou plusieurs groupes auront de la difficulté à accéder à l'information du document. Satisfaire à ce point de contrôle améliorera l'accès aux documents Web.
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 :
- Perceptible : S'assurer que le contenu peut être perçu par tout utilisateur. Par exemple, une image sans équivalent textuel ne peut être perçue par une personne aveugle. De même, un fichier sonore sans transcription textuelle ne peut être perçu par une personne sourde.
- Utilisable : S'assurer que les éléments d'interface du contenu sont utilisables par tout utilisateur. Par exemple, une personne incapable d'utiliser une souris doit être en mesure de se déplacer dans le contenu à l’aide du clavier. De même, un tableau de données et un contenu non structuré rendent la navigation difficile si une personne n'a pas une vision globale de l'écran et doit l'explorer pas à pas.
- Compréhensible : Rendre le contenu et les contrôles compréhensibles par autant d'utilisateurs que possible. Par exemple, indiquer les changements de langue permet aux utilisateurs de synthèse vocale d'entendre la description du contenu dans la langue désirée. De même, un langage simple et des mécanismes de navigation cohérents rendent le contenu plus compréhensible pour les personnes ayant une limitation cognitive.
- Robuste : Le contenu d'un site Web doit pouvoir être utilisé par les technologies courantes ou à venir, incluant les technologies d'adaptation informatique (logiciel ou matériel permettant à une personne handicapée d'utiliser un ordinateur de façon autonome pour accéder à l'information).
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 :
- 10,0 = Conforme (AA)
- 9,5 à 9,99 = Excellent (A+)
- 9,0 à 9,49 = Excellent (A)
- 8,5 à 8,99 = Très bon (B+)
- 8,0 à 8,49 = Très bon (B)
- 7,5 à 7,99 = Bon (C+)
- 7,0 à 7,49 = Bon (C)
- 6,5 à 6,99 = Faible (D+)
- 6,0 à 6,49 = Faible (D)
- 3,0 à 5,99 = Très faible (E)
- 0,0 à 2,99 = Extrêmement faible ou nul (F)
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 |
 |
 |
 |
 |
 |
 |
 |
 |
| Page type de contenu |
 |
 |
 |
 |
 |
 |
 |
 |
| Page avec tableau |
 |
 |
 |
 |
 |
 |
 |
 |
| Page avec formulaire |
 |
 |
 |
 |
 |
 |
 |
 |
| 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.
- 0 % est interprété comme la perfection, alors que 100 % signifie une omniprésence d'erreurs.
- Une croix ou un chiffre rouge signifie la présence (et possiblement la quantité) d'erreurs.
- Un crochet vert reconnaît l'absence de problème pour une page et un critère donné.
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 |
|
|
|
|
|
|
|
|
| Page type de contenu |
|
1 |
2 |
|
|
|
|
|
| Page avec tableau |
|
|
|
|
|
|
|
|
| Page avec formulaire |
|
|
|
|
|
|
|
|
| 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 |
|
|
|
| Page type de contenu |
|
|
|
| Page avec tableau |
|
|
|
| Page avec formulaire |
|
|
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 |
|
|
|
|
| Page type de contenu |
|
|
|
|
| Page avec tableau |
|
|
|
|
| Page avec formulaire |
|
|
|
|
| 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 |
|
|
|
|
|
|
|
|
|
| Page type de contenu |
|
|
|
|
|
|
|
|
|
| Page avec tableau |
|
|
|
|
|
|
|
|
|
| Page avec formulaire |
|
|
|
|
|
|
|
|
|
| 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 |
|
|
| Page type de contenu |
|
|
| Page avec tableau |
|
|
| Page avec formulaire |
|
|
| 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 |
|
|
|
| Page type de contenu |
|
|
|
| Page avec tableau |
|
|
|
| Page avec formulaire |
|
|
|
| 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 |
|
|
|
|
1 |
| Page type de contenu |
|
|
|
|
1 |
| Page avec tableau |
|
|
|
|
1 |
| Page avec formulaire |
|
|
|
|
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 |
|
|
|
|
|
|
|
| Page type de contenu |
1 |
|
|
|
|
|
|
| Page avec tableau |
30 |
|
|
|
|
|
|
| Page avec formulaire |
2 |
|
|
|
|
|
|
| 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 :
- 100 % des pages évaluées comportent des contenus ou des fonctions inutilisables sans Javascript. Il faut s'assurer que des méthodes de contournement seront mises à la disposition des utilisateurs afin de leur permettre d'utiliser le site malgré une éventuelle incapacité à supporter cette technologie. Dans plusieurs cas, il s'agit d'offrir un système de navigation de remplacement pour tout système de navigation dépendant de Javascript ou d'autres technologies de programmation du côté du client. On peut offrir des liens textuels redondants en bas de page ou un plan du site qui soit complet, à jour et constitué de liens textuels. L'impact est majeur pour les personnes incapables d'utiliser une souris à cause de limitations motrices ou visuelles, car cela peut rendre un site partiellement ou totalement inutilisable. Cette façon de faire peut également faciliter le travail des moteurs de recherche. Le coût de correction est relativement faible, car il s'agit généralement du système de navigation dans le site qui est commun à l'ensemble du site mais qui peut varier dans chaque section. La correction peut donc être faite une fois seulement pour l'ensemble du site et pour chaque section de celui-ci.
Voir les résultats de la section Robuste 1
- 75 % des pages évaluées comportent des en-têtes non ou mal utilisés. Il faut prévoir la possibilité de structurer les titres et les sous-titres des pages avec les éléments HTML de types h1 à h6 appropriés, tout en respectant la structure hiérarchique de ceux-ci, de manière à permettre aux personnes qui n'ont pas une vision globale de l'écran de se faire une idée rapide du contenu de la page et de s'y déplacer facilement. L'impact est important parce que cela permet de gagner du temps et d'explorer rapidement le contenu d'une page, d'un coup d'œil, comme le font les personnes sans limitation. L'application de cette recommandation peut également améliorer le rang de classement dans les moteurs de recherche parce que certains moteurs accordent un poids plus important aux mots clés ainsi mis en évidence. Le coût de correction est un peu plus important, car le travail doit être fait sur chacune des pages. Cependant, ces en-têtes sont faciles à repérer visuellement car ils sont mis en évidence par différents moyens. Il suffit donc de modifier le code pour transformer un simple paragraphe en H1, H2, etc.
Voir les résultats de la section Utilisable 2
- 25 % des pages évaluées comportent des formulaires dont les étiquettes sont mal associées ou manquantes. Utilisez les éléments HTML appropriés pour créer une association explicite entre les libellés (étiquettes) et les champs de saisie auxquels ils se rapportent. Ce problème affecte la grande majorité des formulaires évalués. L'impact est important pour les personnes aveugles qui sont dans l'incapacité de remplir certains formulaires parce que le logiciel de lecture d'écran ne réussit pas à associer correctement les champs des formulaires avec les bonnes étiquettes. Le coût de correction est un peu plus important, car la modification doit être apportée pour chacun des champs de formulaire. Notons toutefois que certains formulaires de recherche se retrouvent sur toutes les pages d'un site et qu'il suffit de faire la modification une seule fois. Il ne reste alors que les formulaires plus élaborés qu'on trouve généralement en petit nombre dans un site Web.
Voir les résultats de la section Perceptible 2
- 25 % des pages évaluées ne comportent pas d'équivalent textuel ni de texte de remplacement aux images, photos et autres éléments graphiques. L'impact est important pour les personnes aveugles et cela peut empêcher une partie du contenu d'être perceptible. C'est également le cas pour les moteurs de recherche. Le coût de correction est plus important, car il faut corriger chaque page individuellement. Cependant, des corrections globales peuvent être effectuées pour la plupart des images purement décoratives qui portent généralement le même nom à travers le site et auxquelles il faut donner un équivalent vide (alt=""). D'autre part, les outils de vérification automatique peuvent détecter en une seule opération toutes les images fautives dans l'ensemble d'un site, facilitant d'autant le travail de correction.
Voir les résultats de la section Perceptible 1
- 75 % des pages évaluées comportent des codes et des feuilles de styles invalides (c'est-à-dire avec des erreurs). L'impact peut être important sur les utilisateurs de navigateurs adaptés qui, dans leur interprétation du code, ne comprennent pas ce type d'erreurs. Les principaux bénéfices vont toutefois au fonctionnement technique du site : économie substantielle de la bande passante, réduction des coûts de maintenance et d'exploitation, portabilité et interopérabilité de l'information, meilleure indexation dans les moteurs de recherche, compatibilité ascendante et descendante, pérennité des documents Web, diminution considérable du volume des documents, niveau d'accessibilité de base appréciable. Le coût de correction est plus important, car il faut évaluer et corriger chaque page. Il est important de noter toutefois que ces erreurs sont souvent répétitives et qu'un bon nombre d'entre elles peuvent être corrigées par une action globale de substitution.
Voir les résultats de la section Robuste 2
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 :
- définir la taille des textes à l'écran avec des unités de mesure élastiques ;
- fournir un équivalent textuel aux images liens et aux régions sensibles des images à zones cliquables ;
- offrir une solution de remplacement à tout système de navigation dépendant de javascript ;
- structurer le contenu des pages avec de véritables en-têtes ;
- associer explicitement les étiquettes et les champs des formulaires ;
- fournir un équivalent textuel aux éléments graphiques ayant une valeur significative
- 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 :
- la fréquence du problème,
- l'impact sur la navigation des personnes ayant des limitations fonctionnelles,
- le coût de correction.
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 :
- Recommandation numéro 1
100 % des pages évaluées comportent des contenus ou des fonctions inutilisables sans Javascript. Il faut s'assurer que des méthodes de contournement seront mises à la disposition des utilisateurs afin de leur permettre d'utiliser le site malgré une éventuelle incapacité à supporter cette technologie. Dans plusieurs cas, il s'agit d'offrir un système de navigation de remplacement pour tout système de navigation dépendant de Javascript ou d'autres technologies de programmation du côté du client. On peut offrir des liens textuels redondants en bas de page ou un plan du site qui soit complet, à jour et constitué de liens textuels. L'impact est majeur pour les personnes incapables d'utiliser une souris à cause de limitations motrices ou visuelles, car cela peut rendre un site partiellement ou totalement inutilisable. Cette façon de faire peut également faciliter le travail des moteurs de recherche. Le coût de correction est relativement faible, car il s'agit généralement du système de navigation dans le site qui est commun à l'ensemble du site mais qui peut varier dans chaque section. La correction peut donc être faite une fois seulement pour l'ensemble du site et pour chaque section de celui-ci.
Voir les résultats de la section Robuste 1
- Recommandation numéro 2
75 % des pages évaluées comportent des codes et des feuilles de styles invalides (c'est-à-dire avec des erreurs). L'impact peut être important sur les utilisateurs de navigateurs adaptés qui, dans leur interprétation du code, ne comprennent pas ce type d'erreurs. Les principaux bénéfices vont toutefois au fonctionnement technique du site : économie substantielle de la bande passante, réduction des coûts de maintenance et d'exploitation, portabilité et interopérabilité de l'information, meilleure indexation dans les moteurs de recherche, compatibilité ascendante et descendante, pérennité des documents Web, diminution considérable du volume des documents, niveau d'accessibilité de base appréciable. Le coût de correction est plus important, car il faut évaluer et corriger chaque page. Il est important de noter toutefois que ces erreurs sont souvent répétitives et qu'un bon nombre d'entre elles peuvent être corrigées par une action globale de substitution.
Voir les résultats de la section Robuste 2
- Recommandation numéro 3
75 % des pages évaluées comportent des passages qui ne sont pas identifiés dans une autre langue. Utilisez l'attribut lang afin que la synthèse vocale puisse présenter verbalement ce contenu dans la langue désirée.
Voir les résultats de la section Compréhensible 1
- Recommandation numéro 4
75 % des pages évaluées comportent des en-têtes non ou mal utilisés. Il faut prévoir la possibilité de structurer les titres et les sous-titres des pages avec les éléments HTML de types h1 à h6 appropriés, tout en respectant la structure hiérarchique de ceux-ci, de manière à permettre aux personnes qui n'ont pas une vision globale de l'écran de se faire une idée rapide du contenu de la page et de s'y déplacer facilement. L'impact est important parce que cela permet de gagner du temps et d'explorer rapidement le contenu d'une page, d'un coup d'œil, comme le font les personnes sans limitation. L'application de cette recommandation peut également améliorer le rang de classement dans les moteurs de recherche parce que certains moteurs accordent un poids plus important aux mots clés ainsi mis en évidence. Le coût de correction est un peu plus important, car le travail doit être fait sur chacune des pages. Cependant, ces en-têtes sont faciles à repérer visuellement car ils sont mis en évidence par différents moyens. Il suffit donc de modifier le code pour transformer un simple paragraphe en H1, H2, etc.
Voir les résultats de la section Utilisable 2
- Recommandation numéro 5
50 % des pages évaluées n'ont pas un titre significatif. Modifiez l'élément title pour leur donner un titre qui annonce clairement le contenu de la page.
Voir les résultats de la section Utilisable 2
- Recommandation numéro 6
50 % des pages évaluées comportent des liens ouvrant une nouvelle fenêtre sans avertissement. Abandonnez cette pratique ou ajoutez un avertissement à chacun de ces liens. Vous pouvez utiliser une icône intégrée au lien textuel et comportant un texte de remplacement du genre " Attention, ce lien ouvrira une nouvelle fenêtre " ou ajouter cet avertissement au texte de remplacement d'un lien graphique.
Voir les résultats de la section Compréhensible 2
- Recommandation numéro 7
25 % des pages évaluées comportent un formulaire dont les éléments auraient avantage à être regroupés par catégories à l'aide des éléments fieldset et legend.
Voir les résultats de la section Utilisable 2
- Recommandation numéro 8
25 % des pages évaluées comportent des images complexes, des diagrammes ou des graphiques statistiques qui exigent une longue description. Utilisez l'attribut longdesc pour donner l'adresse de la page indépendante présentant le contenu de la description.
Voir les résultats de la section Perceptible 1
- Recommandation numéro 9
25 % des pages évaluées comportent des formulaires dont les étiquettes sont mal associées ou manquantes. Utilisez les éléments HTML appropriés pour créer une association explicite entre les libellés (étiquettes) et les champs de saisie auxquels ils se rapportent. Ce problème affecte la grande majorité des formulaires évalués. L'impact est important pour les personnes aveugles qui sont dans l'incapacité de remplir certains formulaires parce que le logiciel de lecture d'écran ne réussit pas à associer correctement les champs des formulaires avec les bonnes étiquettes. Le coût de correction est un peu plus important, car la modification doit être apportée pour chacun des champs de formulaire. Notons toutefois que certains formulaires de recherche se retrouvent sur toutes les pages d'un site et qu'il suffit de faire la modification une seule fois. Il ne reste alors que les formulaires plus élaborés qu'on trouve généralement en petit nombre dans un site Web.
Voir les résultats de la section Perceptible 2
- Recommandation numéro 10
25 % des pages évaluées présentent un contraste trop faible. Augmentez le contraste en choisissant des tons plus clairs et plus foncés.
Voir les résultats de la section Perceptible 2
- Recommandation numéro 11
25 % des pages évaluées ne comportent pas d'équivalent textuel ni de texte de remplacement aux images, photos et autres éléments graphiques. L'impact est important pour les personnes aveugles et cela peut empêcher une partie du contenu d'être perceptible. C'est également le cas pour les moteurs de recherche. Le coût de correction est plus important, car il faut corriger chaque page individuellement. Cependant, des corrections globales peuvent être effectuées pour la plupart des images purement décoratives qui portent généralement le même nom à travers le site et auxquelles il faut donner un équivalent vide (alt=""). D'autre part, les outils de vérification automatique peuvent détecter en une seule opération toutes les images fautives dans l'ensemble d'un site, facilitant d'autant le travail de correction.
Voir les résultats de la section Perceptible 1
Dernière révision du rapport : 02/12/2007 par Christophe Bélanger