Évaluer l’accessibilité d’un site web, première partie : Les préliminaires

Par Roger Johansson

Cet article est le premier d'une série de trois publiée sur Pompage.

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é.

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.

Cette série est composée des articles suivants :

  1. Évaluer l'accessibilité des sites web 1ère partie, Les préliminaires (cet article) fournit quelques notions et outils utiles lors d'une évaluation.
  2. Évaluer l'accessibilité des sites web 2ème partie, Les premiers points à vérifier explique les aspects de l'accessibilité qui peuvent être testés avec des outils automatisés comme avec des contrôles manuels relativement simples.
  3. Évaluer l'accessibilité des sites web 3ème partie, Aller plus loin présente les points difficiles à tester à l'aide d'outils automatisés et nécessitant plus de temps et/ou d'expérience pour une évaluation manuelle.

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é :

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

  1. Valider le HTML et les CSS
  2. Pas de cadres (frames), svp
  3. Les outils automatiques d'évaluation d'accessibilité
  4. Les images et le texte alternatif
  5. S'assurer de l'utilisation non intrusive de JavaScript
  6. Augmenter la taille du texte
  7. Évaluer la sémantique du code
  8. Désactiver les CSS
  9. Utiliser Fangs pour simuler un lecteur d'écran

Approfondir

  1. Le contraste des couleurs
  2. Le titre des documents
  3. Le texte des liens
  4. Les formats non HTML
  5. La discrimination des navigateurs et/ou des systèmes d'exploitation
  6. La navigation au clavier
  7. Les tableaux de données
  8. Les libellés et contrôles de formulaires
  9. Utiliser un lecteur d'écran
  10. Ne pas négliger le contenu
  11. Lectures complémentaires

Évaluer l'accessibilité d'un site web, deuxième partie : Les premiers points à vérifier sortira bientôt (NdT : c'est désormais fait sur Pompage). D'ici là, nous pourrions peut-être discuter des moyens de convaincre les développeurs de SGC d'améliorer le support des standards et l'accessibilité de leurs produits. Quelqu'un a de bonnes idées à proposer ?

Deuxième partie

Fiche technique

À propos de l'auteur

Roger Johansson vit en Suède, ou il travaille dans le web comme développeur/designer/rédacteur occasionnel depuis 1994.

Articles du même auteur

Articles similaires

Voici la liste des dix articles les plus récents en rapport avec cet article :

Tous niveaux

Accessibilité

© 2001-2014 Pompage Magazine et les auteurs originaux - Hébergé chez Nursit.com ! - RSS / ATOM - About this site