Évaluer l’accessibilité des sites web 3ème partie, Aller plus loin

Par Roger Johansson

Cet article est la troisième et dernière partie d'une série de Roger Johansson sur l'accessibilité. La première partie a été traduite sous le nom Évaluer l'accessibilité des sites web 1ère partie, préliminaires et la deuxième sous le nom Évaluer l'accessibilité des sites web 3ème partie, les points de contrôle de base.

Dans Évaluer l'accessibilité des sites web 1ère partie, Préliminaires, je fournis quelques notions et outils utiles lors d'une évaluation. Dans le deuxième article de cette série, Évaluer l'accessibilité des sites web 2ème partie, Les points de contrôle de base, j'explique les aspects de l'accessibilité qui peuvent être testés avec des outils automatisés comme avec des contrôles manuels relativement simples.

Ce dernier article 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. Je pars du principe que vous avez déjà lu les deux articles précédents, si vous ne l'avez pas déjà fait veuillez le faire avant de commencer.

Cet article couvre les points suivants:

  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

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.

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.

5. La discrimination des navigateurs et/ou des systèmes d'exploitation

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

8. Les libellés et contrôles de formulaires

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.

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.


http://www.456bereastreet.com/archive/200603/evaluating_website_accessibility_part_3_digging_deeper/

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 :

Accessibilité

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