Évaluer l’accessibilité d’un site web, deuxième partie : Les premiers points à vérifier
Par Roger Johansson
Cet article est le deuxième d'une série de trois publiée sur Pompage.
Ceci est le deuxième article d'une série de trois où il est expliqué comment évaluer l'accessibilité d'un site web. Je vous recommande si ce n'est déjà fait la lecture du premier volet, Évaluer l'accessibilité d'un site web, première partie : Les préliminaires avant de poursuivre votre lecture, afin que vous disposiez des connaissances et outils nécessaires au cours de cet article.
Les points de contrôle présentés dans cet article détaillent plusieurs aspects de l'accessibilité pouvant être évalués automatiquement, ou relativement aisés à vérifier manuellement.
Une procédure d'évaluation d'accessibilité complète est plus approfondie et demande de contrôler plus de points, dont plusieurs seront décrits dans le troisième article de cette série. Il est néanmoins utile de commencer par les suivants :
- Valider le HTML et les CSS
- Pas de cadres (frames), svp
- Les outils automatiques d'évaluation d'accessibilité
- Les images et le texte alternatif
- S'assurer de l'utilisation non intrusive de JavaScript
- Augmenter la taille du texte
- Évaluer la sémantique du code
- Désactiver les CSS
- Utiliser Fangs pour simuler un lecteur d'écran
1. Valider le HTML et les CSS (feuilles de style en cascade)
Utilisez les validateurs du W3C pour vérifier que le HTML et les CSS sont valides. L'extension Web Developer permet de réaliser ce contrôle très simplement : Outils - Valider CSS et Outils - Valider HTML. Je vous recommande fortement de leur attribuer des raccourcis clavier car ces deux opérations sont à effectuer très fréquemment.
Vous pouvez évidemment utiliser les outils en ligne du W3C :
Il est souvent difficile de valider le HTML car pour de nombreux sites il ne comporte pas d'informations sur le DOCTYPE ou l'encodage de caractères utilisés. Vous devrez dans ces cas-là forcer certains paramètres du validateur, depuis l'interface avancée.
Dans certains cas extrêmes, le site refuse l'accès au validateur. Je vous assure, j'ai déjà vu ce cas de figure... Que quelqu'un prenne la peine de faire ça dépasse complètement ma compréhension. Quoi qu'il en soit, vous devrez dans ces cas-là utiliser Outils - Valider les CSS locales et Outils - Valider le HTML local de la barre d'outils Web Developer. Quand le HTML est trop mal formé, il arrive que vous deviez valider le CSS en local (via Outils - Valider les CSS locales), car le validateur CSS refuse de passer outre certaines erreurs.
L'extension HTML Validator permet elle aussi de valider des pages bloquant le validateur du W3C. La validation s'effectue entièrement en local, ce qui est particulièrement adapté aux sites situés derrière un pare-feu ou nécessitant une authentification.
L'extension HTML Validator vous avertira automatiquement de toutes les malformations et des points de contrôle d'accessibilité pour chaque page affichée dans le navigateur. Le niveau de sensibilité pour l'accessibilité est paramétrable dans les options. Gardez néanmoins à l'esprit que cette extension est basée sur Tidy, et qu'elle ne relèvera pas forcément toutes les erreurs que le validateur du W3C saurait déceler.
Ne confondez pas validité et accessibilité. J'ai vu beaucoup de sites valides dont l'accessibilité laissait beaucoup à désirer. Cela arrive très souvent avec les sites basés sur un système de gestion de contenu (CMS) dont les concepteurs semblent ne pas avoir compris le but des standards.
Pourquoi ? Parce qu'utiliser un code valide est important pour assurer l'indépendance vis-à-vis des outils, l'un des fondements du Web. C'est le meilleur moyen d'assurer que votre contenu sera correctement interprété par le maximum de dispositifs de navigation.
2. Pas de cadres (frames), merci
Dans Firefox, affichez le code source ou faites apparaître le menu contextuel pour voir si le site utilise des cadres. Si la page en contient, un menu Ce cadre sera disponible dans le menu contextuel. Les iframes (cadres en ligne) sont un peu plus ardus à déceler car il vous faudra positionner le pointeur au-dessus de l'espace utilisé par l'iframe pour pouvoir faire apparaître le menu Ce Cadre. Heureusement, la barre d'outil Web Developer permet d'entourer tous les iframes d'une page via Entourer - Entourer les frames.
Pourquoi ? Parce que même si les cadres ne sont pas forcément entièrement inaccessibles, dans la plupart des cas le site en est rendu bien moins facile d'accès et d'utilisation, et il vaut mieux s'en passer totalement. La présence de cadres indique également que le développeur du site est peu informé de l'accessibilité et de l'ergonomie. Reportez-vous à mon article Qui a mis le web en cage - cadres et accessibilité pour plus d'informations sur ce sujet.
3. Les outils automatiques d'évaluation d'accessibilité
Les outils d'évaluation automatique d'accessibilité sont principalement utilisés par ceux qui en sont encore à découvrir l'accessibilité. C'est parfaitement compréhensible : qui ne souhaiterait que vérifier l'accessibilité d'un site fût aussi simple que de valider du code ? Les outils actuels sont malheureusement loin d'être parfaits et on ne peut pas se reposer totalement sur eux.
Ils permettent tout de même de se faire rapidement une idée très grossière de l'accessibilité d'un site et de repérer quelques-uns des problèmes, c'est pourquoi je recommande quand même de consulter leur opinion sur le site. Soyez néanmoins conscients que de nombreux problèmes ne seront pas détectés, et que certains des problèmes signalés ne seront en fait pas de véritables problèmes. Il est donc toujours obligatoire de procéder à une évaluation manuelle.
En conclusion, on ne peut pas faire aveuglément confiance aux outils suivants mais ils peuvent au moins vous aider à savoir si le site est accessible ou non, et les points susceptibles de se révéler problématiques :
- TAW
- WebXACT (anciennement appelé Bobby)
- Cynthia Says
Et, que ce soit bien clair : un site qui passe tous les tests automatiques n'est pas pour autant accessible.
Pourquoi ? Les outils automatiques vous aideront à repérer les problèmes qui prendraient longtemps à isoler s'il fallait analyser le code à la main. Étudiez attentivement le rapport généré et vérifiez vous-même les portions marquées comme pouvant être source de problèmes.
4. Les images et le texte alternatif
L'attribut alt étant obligatoire pour les images et les images réactives, le validateur HTML et les autres outils précités afficheront des erreurs s'ils en rencontrent dont le texte alternatif n'a pas été défini. S'il n'y en a pas, toutes les images du document possèdent un attribut alt. Néanmoins, il peut encore y avoir des problèmes et vous devez maintenant étudier comment l'attribut alt est utilisé.
Utilisez l'extension Web Developer pour afficher le texte alternatif de toutes les images du document : Images - Remplacer les images par l'attribut Alt. Voyez si le site est intelligible, et si le texte alternatif est visible quand les images ne sont pas affichées - de nombreux navigateurs affichent ce texte de la couleur spécifiée pour l'image (ou un de ses parents). Si cette couleur ne contraste pas assez avec l'arrière-plan, le texte alternatif risque d'être difficile, voire impossible à lire. Ce problème se rencontre principalement sur les sites utilisant de nombreuses images de fond.
Le rôle de l'attribut alt est bien souvent mal compris. Il sert à fournir un texte alternatif et cohérent, à utiliser en lieu et place d'un objet graphique apportant une information lorsque cet objet n'est pas disponible. Il ne doit pas être utilisé pour afficher du texte dans une infobulle. Rappelons-le : l'attribut alt est obligatoire pour les balises img et area.
Les images porteuses d'information doivent comporter une courte description de leur contenu. Les images décoratives doivent avoir un texte alternatif vide. J'ai vu des sites où, dans un effort louable mais mal informé, chaque image décorative et chaque GIF d'espacement était consciencieusement décrit dans le texte alternatif. Une seule visite sur un tel site avec un lecteur d'écran ou un navigateur en mode texte suffira à vous convaincre à quel point cela peut être irritant.
Pour une description plus approfondie de l'attribut alt et de son proche parent, title, je vous renvoie à mon article Les attributs alt et title. Pour vous aider à dissocier image informative et décorative, consultez celui de Dimitri Glazkov : Comment garder toutes les petites touches graphiques séparées du contenu.
Pourquoi ? Parce que s'il n'y a pas de texte alternatif, ou si celui-ci n'est pas spécifié correctement, quiconque n'aura pas accès aux images recevra un contenu amputé, ou sera au contraire écrasé par une avalanche d'informations inutiles.
5. S'assurer de l'utilisation non intrusive de JavaScript
Le moment est revenu d'utiliser l'extension Web Developer. Désactivez le JavaScript (Désactiver - Désactiver JavaScript), puis tentez d'utiliser le site ; dans certains cas, cela devient impossible. Le problème le plus fréquent dans les sites de l'administration est la navigation nécessitant JavaScript. Autre problème récurrent, le chargement dynamique d'une feuille de style (après « reniflage... » du type de navigateur, un procédé d'un autre siècle). Le visiteur n'ayant pas JavaScript ne recevra qu'un document brut et sans mise en page.
J'utilise également Lynx, navigateur en mode texte qui n'implémente pas le JavaScript, pour vérifier qu'un site est utilisable sans JavaScript.
Pourquoi ? Un nombre important d'utilisateurs navigue avec JavaScript désactivé, ou avec un navigateur ne le gérant pas. Rien ne devrait les empêcher d'utiliser le site pour autant.
Ceci n'est pas une interdiction d'utiliser Javascript. JavaScript peut ajouter beaucoup à votre site, mais il faut en faire un usage raisonné et non intrusif, et assurer une solution de rechange acceptable en l'absence de support (dégradation gracieuse).
6. Augmenter la taille du texte
Pour vérifier ce point il vous faudra utiliser IE/Win ou étudier les CSS utilisées par le site. Notre attention portera ici sur les unités utilisées pour spécifier la taille du texte.
Le texte dont la taille est spécifiée dans une unité relative telle qu'em ou % sera redimensionnable avec tous les navigateurs. Exprimée en pixels, les utilisateurs d'Internet Explorer sur Windows ne pourront pas l'augmenter ou le diminuer sans modifier les préférences générales du logiciel, ce que très peu effectuent.
Affichez donc le document dans IE/Win si vous l'avez et tentez de changer la taille du texte (Ctrl + molette ou Affichage - Taille du texte - La plus grande). Si rien ne se produit, la taille du texte est probablement définie en pixels.
Si vous ne pouvez pas utiliser IE/Win, il faut étudier les feuilles de style. Rappelez l'extension Web Developer : CSS - Editer les CSS. Cherchez les unités utilisées pour les déclarations de type font-size. Si vous ne voyez que du px, les unités utilisées par le site ne sont pas relatives. (Enfin si, techniquement, mais pas de la manière qui nous intéresse.) Les unités à trouver sont em ou %.
Savoir si les navigateurs doivent autoriser le redimensionnement du texte dont la taille est spécifiée en pixels est un débat très intéressant, mais que nous n'aborderons pas ici. Cette discussion se poursuit depuis des années, et vous pourrez avoir un aperçu du débat dans mon article Définir la taille du texte en pixels.
Même lorsque la taille du texte est définie dans une unité relative, le redimensionner peut poser problème. La mise en page, en effet, doit pouvoir s'accomoder d'une taille de texte redéfinie par l'utilisateur. La plupart des mises en page deviennent rapidement inutilisables dès que le texte est agrandi. Il est évident qu'aucune mise en page ne peut tenir au-delà d'un certain seuil et il n'est pas primordial que l'aspect reste irréprochable, mais une bonne mise en page doit supporter qu'un visiteur décide d'augmenter la taille de plusieurs crans sans qu'aucun contenu ne disparaisse ou ne devienne illisible.
Si enfin vous décidez d'implémenter un petit utilitaire permettant de changer la taille du texte (ce que je déconseille), assurez-vous que la taille maximum possible est vraiment grande. Pas juste un peu plus que la taille par défaut, beaucoup plus. Après tout, pourquoi passer du temps à créer ces utilitaires si le résultat ressemble beaucoup au point de départ ?
Pourquoi ? Parce que nombreux sont ceux qui apprécient ou ont besoin de texte de bonne taille pour le lire confortablement. Citons ceux dont la vue est déficiente, les plus de 40 ans, ou encore ceux qui préfèrent s'adosser confortablement lorsqu'ils naviguent sur Internet.
7. S'assurer de la sémantique des balises
Pour vérifier que le site utilise bien des balises sémantiques, affichez la source de la page et cherchez des titres (<h1> - <h6>), des listes (<ul>, <ol>, <dl>), des citations (<blockquote>, <q>), et des marques d'emphase (<strong>, <em>). Cela se repère assez facilement en général parce que les sites n'utilisant pas de balises sémantiques se retrouvent souvent avec des assemblages tels que <span class="GrosTitreGrasEtRouge">Titre</span> là où un document sémantique ne s'encombrerait pas d'autre chose que d'un <h1>Titre</h1>.
Pourquoi ? Un balisage sémantique est important car il permet aux dispositifs de navigation de présenter le contenu en fonction de son statut dans le document. Un autre atout non négligeable est que les moteurs de recherche tendent à favoriser le balisage sémantique.
Une utilisation correcte des titres permet également aux outils d'aide de concevoir une table des matières qui se révélera très utile pour les utilisateurs de lecteur d'écran.
Bien que tous les dispositifs d'aide n'utilisent pas systématiquement les informations sémantiques qui leur sont fournies, en leur absence aucun d'entre eux ne pourra trouver de sens au texte.
8. Désactiver les CSS
Désactivez les CSS à l'aide de l'extension Web Developer : CSS - Désactiver les styles CSS - Tous les styles. Vous verrez alors la structure HTML sous-jacente du document auquel ne sera appliqué que le style par défaut du navigateur.
Si presque rien ne change une fois les CSS désactivées, le site utilise probablement des tableaux pour la mise en page et beaucoup de balises graphiques non dissociées du contenu. À ce point de l'évaluation vous aurez probablement déjà rencontré de nombreux problèmes d'accessibilité avec ce genre de documents.
Pourquoi ? Pour être accessible un document doit avoir une structure hiérarchisée, cohérente et lisible sans les CSS.
9. Utiliser Fangs pour simuler un lecteur d'écran
Si vous n'avez pas de lecteur d'écran à votre disposition, Fangs est une bonne alternative pour se faire une idée relativement correcte de la façon dont un tel dispositif lirait le site en cours d'évaluation. Il s'agit d'une extension pour Firefox (que je vous recommande d'installer dans la première partie de cette série d'articles) permettant d'afficher le contenu d'un site dans l'ordre où le lirait le lecteur d'écran le plus répandu.
Pourquoi ? Parce que les lecteurs d'écran sont des dispositifs d'aide importants. Savoir comment un site serait lu par un tel outil vous aidera à déterminer si l'ordre du contenu fait sens, si les liens et les titres sont utilisés à bon escient, et si le texte alternatif est utilisé comme il le faut.
Évaluer les résultats
Après avoir contrôlé tous les points de cette liste vous aurez ou non relevé un certain nombre de points techniques posant des problèmes d'accessibilité. Si vous êtes le développeur, faites ce que vous pouvez pour résoudre ces problèmes et refaites le point. Sinon, contactez le responsable du site et prévenez-le que vous y avez remarqué des problèmes qui méritent son attention.
Il reste pourtant de nombreux points à vérifier. Dans Évaluer l'accessibilité d'un site web, troisième partie : Aller plus loin, troisième et dernier article de cette série, je parlerai plus spécifiquement des points difficiles à évaluer de manière automatique et nécessitant une évaluation manuelle, plus longue, avant de parler de ce qui est souvent trop peu considéré quand on parle d'accessibilité : le contenu.
http://www.456bereastreet.com/archive/200603/evaluating_website_accessibility_part_2_basic_checkpoints/