Il est devenu obligatoire, dans un nombre sans cesse croissant de pays, que les sites du service public respectent les standards et les normes d’accessibilité. En conséquence, il est donc nécessaire que les responsables du développement et de la mise à jour de ces sites soient capables d’en assurer et d’en évaluer l’accessibilité.
LES PRELIMINAIRES:
Nombreux sont ceux, développeurs web et propriétaires de sites, qui découvrent l’accessibilité et la trouvent difficile à évaluer. Le but de cette série de trois articles est de leur apprendre à effectuer les contrôles de base. J’espère que cela sera assez utile pour rendre quelques sites web un peu plus accessibles.L’examen des différents points décrits dans cette série ne dispense pas de réaliser des tests avec des utilisateurs de lecteurs d’écran et autres technologies d’assistance. Si c’est en dehors de vos moyens, contrôler les points présentés dans cette série vous donnera tout de même une bonne indication de l’accessibilité du site.
Quelques notions
Une définition courante de l’accessibilité est l’accès au Web par tous, indépendamment de toute invalidité
. Selon cette définition, l’accessibilité ne concernerait que ceux qui souffrent d’infirmités. Que cette définition soit officielle ou non, je la trouve vraiment trop restrictive, et je ne suis pas le seul. Robert Nyman y réfléchit lui aussi dans What is Accessibility ?
Quand je parle d’accessibilité dans cet article (et ailleurs), c’est dans un sens plus large incluant l’indépendance vis-à-vis des appareils - l’accès universel, indépendamment de l’invalidité, de l’agent utilisateur ou de la plate-forme. Le Web doit être accessible à tous.
Un coup d’œil rapide sur les différents sites gouvernementaux en Suède (et dans la plupart des pays, du reste) amène à une triste constatation. Les développeurs de nombre de ces sites ont manqué de s’assurer qu’ils respectaient les standards du web et qu’ils étaient accessibles à tous. Même les sites les plus récemment reconstruits ou redessinés font figure de cancres. À en croire le balisage utilisé, on est encore en plein 1997. Et les sites refaits en 2006 ne font pas exception. C’est pathétique.
Pour en savoir plus sur l’usage actuel des standards par les services publics du monde entier, je vous suggère de lire les articles Government web standards usage: USA, Government Web Standards Usage: New Zealand, Government Web Standards Usage: People’s Republic of China, et Mätning av grundläggande tillgänglighet (en suédois).
Il ne faut pas confondre respect des standards et accessibilité, mais les deux sont liés et les tests de validation indiquent généralement si un effort d’accessibilité a été fait ou non.
Le test de validation effectué massivement sur les sites gouvernementaux suédois par Verva (l’agence suédoise du développement administratif), a eu un effet secondaire un peu pervers. Depuis la première série de tests, plusieurs sites ont ainsi bien ajusté le balisage de leur page principale pour le rendre valide, mais ce dernier repose encore sur des balises de présentation, des proportions importantes de CSS en ligne, de mises en page en tableau, et de GIFs d’espacement affublés d’un texte alternatif inutile. Ces procédés me dégoûtent, et j’ai plus de respect pour ceux qui ne se soucient pas des résultats du validateur que pour ceux qui trichent dans le seul but de n’afficher aucune erreur dans les tests de Verva.
L’inaccessibilité et la piètre qualité de la majeure partie des sites officiels en Suède est inacceptable. C’est aussi compréhensible dans la mesure où il est difficile d’évaluer un site sans une connaissance minimum de l’accessibilité. De nombreux organes gouvernementaux, ne disposant pas en interne des compétences nécessaires en HTML, sont forcés de se tourner vers des sociétés privées pour la réalisation de leur site web. Il est par conséquent difficile pour les responsables de s’assurer de la qualité et de l’accessibilité du travail effectué.
Malheureusement, nombre de ces sociétés semble ne se soucier ni de la qualité de leur production, ni des bonnes pratiques ou de l’accessibilité. J’ignore pourquoi, il semblerait pourtant logique que leurs employés soient fiers de donner le meilleur d’eux-mêmes. C’est pourtant loin d’être le cas.
Un autre problème vient des arguments de vente avancés par certains concepteurs de SGC (CMS). Souvent, l’accessibilité et le respect des standards des sites basés sur ces SGC sont clamés haut et fort alors que le seul objectif est d’impressionner le client potentiel à coups d’éditeurs WYSIWYG, de menus survolés, d’intégration avec Microsoft Office par simple glisser-déposer, et autres tours d’esbrouffe. Je crains que rien ne change tant qu’il sera permis à ces sociétés d’agiter des arguments mensongers, peu d’entre elles ayant un réel intérêt à s’assurer que le SGC qu’elles utilisent produit effectivement un code valide, sémantique et accessible.
Bon, refermons la parenthèse et venons-en au but de cet article : expliquer comment effectuer un test d’accessibilité rudimentaire.
Préparation : installer les outils
Avant tout, je vous recommande de télécharger et d’installer des outils qui simplifient considérablement l’évaluation de l’accessibilité :
- Le navigateur Internet Firefox
- L’extension Web Developer pour Firefox
- L’extension HTML Validator pour Firefox
- l’extension Fangs pour Firefox
- Le navigateur Internet en mode texte Lynx
Vous avez probablement déjà installé un ou plusieurs de ces outils. Sinon, il est grand temps de le faire.
Les points à contrôler
Les points présentés dans cette série d’articles couvrent les domaines causant généralement le plus de problèmes d’accessibilité, en commencant par les plus fréquents. Il y en a 18 au total :
Points de contrôle de base
- 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
Approfondir
- Le contraste des couleurs
- Le titre des documents
- Le texte des liens
- Les formats non HTML
- La discrimination des navigateurs et/ou des systèmes d’exploitation
- La navigation au clavier
- Les tableaux de données
- Les libellés et contrôles de formulaires
- Utiliser un lecteur d’écran
- Ne pas négliger le contenu
- Lectures complémentaires
LES PREMIERS POINTS A VERIFIER
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 :
- Service de validation HTML du W3C
- Service de validation CSS 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.
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.
ALLER PLUS LOIN
1. Le contraste des couleurs
Pour s’assurer que les couleurs d’arrière-plan et de premier plan contrastent suffisamment en teinte et luminosité, l’excellent évaluateur de contraste de Jonathan Snook se révèle très pratique. Il suffit de saisir les deux valeurs en hexadécimal, ou plus simplement encore de faire glisser les curseurs pour obtenir un retour visuel instantané.
L’analyseur de contraste de Gez Lemon est similaire et il est également disponible en tant qu’extension pour Firefox.
Ces deux outils calculent la visibilité des couleurs suivant l’algorithme mis à disposition par le W3C.
Une autre solution consiste à basculer son affichage en monochrome ou en nuances de gris pour s’assurer que le texte reste lisible. Sur Mac OS X le panneau « accès universel » offre d’intéressantes options : inverser les couleurs, passer en monochrome ou en nuances de gris, et régler le contraste. Si vous connaissez des outils de ce genre sur d’autres plate-formes, merci de les signaler dans les commentaires.
Pourquoi ? Parce que si le contraste en teinte ou en luminosité entre les couleurs de premier et d’arrière-plan est trop faible, les lecteurs auront du mal à distinguer et lire le contenu. Cela se produit s’ils ont du mal à distinguer les couleurs, ou encore si leur écran n’affiche pas les couleurs. Même moi, ayant une vue parfaite et un écran de très bonne qualité, j’aurais beaucoup de mal à lire un texte gris clair sur fond blanc.
Pour la même raison, il ne faut pas compter uniquement sur la couleur pour véhiculer une information. Les liens, par exemple, ne doivent pas se différencier du texte environnant que par la couleur mais aussi par l’épaisseur de la police ou son soulignement.
2. Le titre des documents
Assurez-vous que chaque document est repéré par un titre unique et descriptif, et que celui-ci n’utilise pas de signes de ponctuation de manière excessive.
Il n’y a pas de règle officielle concernant la ponctuation dans les titres ; néanmoins un usage purement décoratif est à proscrire. Les signes utilisés dans « :: Titre :: » ou encore « …== Titre ==… » seront prononcés les uns après les autres par n’importe quel lecteur d’écran, ce qui les rend très pénibles à la longue. Pour vous faire une idée de comment Jaws interprète certains de ses signes, jetez un œil à The Sound of the Accessible Title Tag Separator (le son des séparateurs de titres accessibles).
VoiceOver, le lecteur d’écran d’Apple, prononce le caractère “ » ” comme « double guillemets fermants droits coudés ». Impensable, non seulement dans les titres mais également dans le texte des liens, où il est malheureusement très populaire.
Le thème des séparateurs de titres est débattu dans Document titles and title separators (Les titres des documents et les séparateurs).
Pourquoi ? Parce que le titre des documents est bien souvent le premier élément lu au chargement d’une nouvelle page par un dispositif d’assistance visuelle ; il est également affiché dans le titre de la fenêtre, dans les marque-pages, et à l’impression. Un titre descriptif bénéficie à tout le monde, y compris au site lui-même car il compte énormément pour la visibilité dans les moteurs de recherche.
3. Le texte des liens
Les liens devraient être significatifs indépendamment du contexte. « Cliquez ici » ou « là » est tout sauf un bon texte de lien car cela n’indique absolument rien sur la cible du lien. A l’opposé, utiliser un paragraphe complet (comme il est courant sur les sites des journaux) apporte cette fois trop d’informations et est à proscrire également.
En général, deux liens pointant vers des cibles différentes ne doivent pas utiliser le même texte. Dans l’idéal, chaque lien doit se suffire à lui-même et pouvoir être lu hors contexte. Certains outils automatiques d’évaluation de l’accessibilité vous en avertiront.
Il y a cependant quelques exceptions. Comme l’explique Joe Clark dans son entretien paru sur le Web Standards Group en mai 2005, il est tolérable d’utiliser « Lire la suite » ou « Poursuivre la lecture » dans une liste d’articles ou d’annonces, pour autant que l’attribut title permette de distinguer les différents liens.
Pour avoir la liste de tout les liens d’une page, utilisez la fenêtre « Liens » dans Opera ; Fangs vous le permet également.
Pourquoi ? Parce que les liens profitent bien plus à tout le monde s’ils contiennent un texte descriptif. La plupart des gens dont la vue est bonne balaient la page du regard pour se faire une idée de son contenu, et les liens sont souvent une part importante du contenu. Des liens explicites facilitent ce balayage. Une personne à la vue déficiente ne peut parcourir la page visuellement, mais il lui est en revanche possible de naviguer de lien en lien, ou d’afficher la liste des liens contenus dans la page. Un texte descriptif joue énormément dans ce cas-là. Enfin, le texte des liens est très important pour la visibilité sur les moteurs de recherche, et une fois encore on gagne sur les deux tableaux en améliorant l’accessibilité.
4. Les formats non-HTML
Si des informations importantes sont fournies en PDF, Microsoft Word, Microsoft Excel, ou tout autre format propriétaire, il est recommandé d’en mettre une version HTML à disposition également. Il n’est absolument pas interdit d’utiliser ces formats, mais il est nécessaire de proposer une alternative HTML.
Pourquoi ? Parce que, bien qu’il soit possible de rendre le contenu de documents PDF raisonnablement accessible pour qui possède le logiciel adapté, HTML reste le format le plus largement supporté et devrait être utilisé en priorité. De plus, Microsoft Word ou Excel, ou le moyen d’ouvrir des documents dans ce format, sont loin d’être disponibles pour tous les utilisateurs. Si, comme c’est souvent le cas, des informations sont disponibles uniquement dans un format propriétaire Microsoft, une population importante en est maintenue à l’écart.
J’appelle discrimination le fait de limiter ou de refuser totalement à une catégorie d’utilisateurs l’accès à une information ou une fonctionnalité, au prétexte que le navigateur ou le système d’exploitation qu’ils utilisent est minoritaire. Dans l’idéal, pour contrôler ce point, il faudrait avoir accès à différents navigateurs sur différents systèmes d’exploitation. Cette configuration n’étant pas pratique à mettre en place, une solution de repli consiste à déguiser la chaîne d’identification du navigateur utilisé pour réaliser les tests.
Puisque vous utilisez Firefox (comme je le recommandais dans Évaluer l’accessibilité d’un site web première partie : Les préliminaires, souvenez-vous) il vous suffira d’installer l’extension User Agent Switcher (des versions localisées sont disponibles), de télécharger une liste de chaînes d’identification, et le tour est joué !
Vérifiez que le site n’autorise pas l’accès uniquement aux navigateurs identifiés comme Internet Explorer sous Windows. Notre solution de repli ne permettra d’évaluer ceci que si la discrimination s’effectue sur la base de l’identification du navigateur utilisé ; une détection basée sur les fonctionnalités liées au système d’exploitation devra être évaluée autrement.
La discrimination envers les plate-formes est parfois involontaire, mais bien trop souvent totalement intentionnelle. S’il est rare de voir un site refuser l’accès aux utilisateurs d’Internet Explorer sur Windows, la plupart des utilisateurs de Macintosh ou de Linux en revanche ont eu l’occasion de se voir interdire l’accès au prétexte que leur système d’exploitation ou navigateur n’est pas « supporté ». C’est absolument intolérable.
Je répète souvent que l’accessibilité ne se cantonne pas à faciliter l’accès aux handicapés, et en voici un exemple flagrant. C’est d’ailleurs ce point-là qui m’a, plus que tout autre, fait réaliser combien il est important qu’Internet soit accessible à tous. Me voir refuser l’accès à un site parce que j’utilise un Mac m’irrite prodigieusement.
Pourquoi ? Parce qu’il est fondamental qu’Internet soit accessible, indépendamment du logiciel ou du matériel utilisé pour y accéder. Un seul réseau, pour tous, partout, et sans contraintes.
6. La navigation au clavier
Éloignez votre souris pour un temps et tentez de naviguer sur le site en n’utilisant que le clavier. Tabulez entre les différents liens et contrôles de formulaire. Il vous sera peut-être nécessaire de toucher aux réglages de votre navigateur car cette option est désactivée par défaut sur Safari et Firefox. Comment se passe l’expérience ? S’il y a des menus déroulants, vérifiez qu’ils peuvent être utilisés sans la souris.
Pourquoi ? Les utilisateurs de lecteurs d’écrans n’utilisent pas de pointeur, il est donc important que la navigation soit possible en son absence. Il y a également un grand nombre d’utilisateurs pour qui le clavier est plus rapide et plus pratique à utiliser qu’une souris.
En fonction de l’ordre des éléments du fichier source et de la taille du document, il est parfois très utile de proposer des liens internes pointant vers les principaux blocs de la page. Cela évitera à ceux qui n’utilisent pas la souris de perdre leur temps à atteindre le début du contenu principal.
Un site doit être accessible indépendamment du matériel, et ne doit pas imposer aux visiteurs l’utilisation d’un moyen de saisie particulier, la souris en l’occurrence.
7. Les tableaux de données
Vérifions maintenant la bonne ou mauvaise utilisation des tableaux. Une fois encore l’extension Web developer nous simplifiera la tâche. Choisissez Entourer - Entourer les cellules de tableaux et Entourer - Entourer les tableaux pour mettre en évidence les tableaux utilisés dans la page. Rien ne devrait se produire si cette page ne contient aucune donnée tabulaire. Si des éléments non tabulaires sont entourés, la page utilise des tableaux pour la mise en page et le site ne passe pas ce test.
Si en revanche la page contient des données tabulaires, assurez-vous qu’elles sont placées dans un tableau correctement organisé et balisé de manière accessible. Pour plus d’informations sur la bonne manière d’utiliser les tableaux HTML, je vous renvoie à mon article Bring on the tables (traduit sur Pompage sous le titre Au tableau !, Ndt).
Pourquoi ? Les tableaux ne sont pas des éléments de mise en page, ils servent à afficher des données tabulaires et doivent utiliser les éléments et attributs améliorant l’accessibilité.
Pour ce point, vous aurez bien évidement besoin de trouver une page contenant au moins un formulaire. Pour celui-ci, vérifiez que chaque élément de saisie est associé à un libellé de type label, et que ceux-ci sont dans le bon ordre (libellés avant le contrôle associé, sauf pour les boutons radio et cases à cocher qui viennent avant le libellé).
Si le formulaire utilise des listes déroulantes (select) pour la navigation, assurez-vous que la soumission n’est pas automatique. Assurez-vous qu’il est possible d’envoyer le formulaire quand javascript est désactivé, et que chaque contrôle de saisie est effectué à la fois sur le client et sur le serveur.
Normalement, les vérificateurs automatiques d’accessibilité devraient vous signaler les éléments de saisie sans libellé associé. La barre d’outils Web developer vous permet également de vous en assurer via Formulaire - Informations sur les formulaires.
Pourquoi ? Les libellés augmentent la taille de la zone cliquable, ce qui profite à tout les utilisateurs. Tout élément de saisie visible doit être explicitement associé à un libellé.
La soumission automatique de formulaire lors d’une sélection dans une liste déroulante pose problème aux utilisateurs de clavier. Soumettre un formulaire avec javascript est bien évidement impossible si celui-ci est désactivé. Contrôler la validité de la saisie du côté client uniquement est insuffisant et des données non valides risquent d’être enregistrées dans la base de données.
9. Utiliser un lecteur d’écran
Avant tout, je tiens à rappeler que l’accessibilité ne se limite pas aux lecteurs d’écran, loin de là. C’est une confusion fréquente, mais il ne faut surtout pas s’arrêter à ça marche dans tel lecteur d’écran
.
Mais parlons-en, de ces lecteurs d’écran. Il est très difficile d’imaginer ce que représente la navigation sur Internet pour un non-voyant. Même avec la meilleure volonté, il est difficile de ne pas tricher. Il est bon d’essayer tout de même, et pour cela un lecteur d’écran est indispensable.
Si vous utilisez un Mac, celui-ci possède peut-être déjà le lecteur d’écran VoiceOver fourni par Apple à partir de Mac OS X 10.4. Sans être aussi performant que les autres lecteurs disponibles sur le marché, il suffit à vous faire une idée de comment « sonnera » un site pour un non-voyant. J’ai expliqué les bases de la navigation sur Internet avec ce logiciel dans l’article VoiceOver and Safari: Screen reading on the Mac (VoiceOver et Safari : la lecture d’écran sur Mac).
Si vous n’avez ni Mac ni Mac OS X 10.4 ou supérieur, il vous faudra installer un lecteur d’écran. Ils coûtent cher pour la plupart, et vous vous contenterez probablement d’une version de démonstration. Voici une liste des lecteurs d’écran pour lesquels une version de démonstration est disponible.
- JAWS (et sa version française)
- Window-Eyes
- Supernova
- IBM Home Page Reader (dont voici une présentation en français, NdT)
Pourquoi ? Les différents points examinés ci-dessus vous amèneront très loin en termes d’accessibilité. Néanmoins, il est essentiel de faire par soi-même l’expérience de la navigation sur Internet pour les non-voyants car cela vous fera comprendre toute l’importance des points cités précédemment.
10. Ne pas négliger le contenu
Lorsqu’un site passe tout les points cités dans cette série d’articles, on peut assez tranquillement affirmer que ce site est techniquement accessible à tous. Cela ne signifie pas pour autant que son contenu est compréhensible par tous.
Produire ou écrire un contenu réellement accessible pour tous peut se révéler difficile, mais cet aspect de l’accessibilité dépasse le cadre de cet article. Gardez seulement à l’esprit qu’un contenu mal écrit ou incohérent peut être difficile à comprendre même pour un public intellectuellement avancé.
La compréhension du contenu d’un site Web sera évidement bien plus difficile pour qui souffre d’une difficulté d’apprentissage ou d’un autre problème cognitif. Je recommande à ce sujet la lecture de Developing sites for users with Cognitive disabilities and learning difficulties (Développer des sites pour les utilisateurs ayant des difficultés d’apprentissage ou d’autres problèmes cognitifs), dans lequel Roger Hudson, Russ Weakley, et Peter Firminger présentent les points pouvant poser problème, et des solutions à ces problèmes.
11. Lectures complémentaires
Je recommande également la lecture du texte Web Content Accessibility Guidelines 1.0 et du document d’accompagnement Techniques pour les règles d’accessibilité du contenu web. Ces documents ne sont pas vraiment, comment dire, faciles d’accès eux-mêmes, mais on y trouve beaucoup d’information.
Je vous encourage également à lire les versions de travail du WCAG 2.0 et du document d’accompagnement, Techniques for WCAG 2.0. Attention, ce ne sont que des documents de travail susceptibles d’être modifiés avant publication définitive.
Enfin, laissez-moi vous rappeler qu’améliorer l’accessibilité n’est pas une histoire de tout ou rien. Faire un geste dans la bonne direction vaut beaucoup mieux que d’attendre sans rien faire, en espérant que personne ne le remarquera.
Si l’on revient sur le sens du mot favicon, on citera 