La checklist d’accessibilité que je m’étais juré de ne pas rédiger
Par Aaron Cannon
J'ai déjà dit de nombreuses fois qu'il n'existait pas de checklist qui puisse vous garantir à 100% un site accessible, même si on la suivait à la lettre. Il y a tout simplement trop de variables en jeu. Cela dit, que faire lorsque vous voulez créer des pages accessibles et que vous avez des dizaines, sinon des centaines de développeurs qui (comme la plupart de leurs collègues) savent peu, voire rien de l'accessibilité ? Que faire lorsqu'il est tout simplement impossible de demander à quelqu'un de vérifier toutes vos pages ? En bref, comment vous assurer qu'une très grande organisation crée des pages qui seront accessibles au public le plus large possible, sans exploser votre budget ? C'est une des questions contre lesquelles nous bataillons depuis longtemps, et ce n'est pas fini.
Je crois que pour résoudre ce problème, nous devrons adopter une approche sur plusieurs plans. Néanmoins, un élément paraît incontournable: la formation de nos designers et de nos développeurs. Je ne crois pas qu'il soit raisonnable (même si j'adorerais tenter le coup) de transformer nos développeurs et nos designers en experts de l'accessibilité, donc que peut-on faire ? Si on ne peut pas encore parvenir à un excellent niveau d'accessibilité, pourquoi ne pas au moins faire mieux que ce que l'on fait aujourd'hui ?
Quand j'ai écrit la checklist ci-dessous, j'ai tenté de répondre à la question: «Quels conseils rapides puis-je donner aux designers qui auront le plus grand impact sur l'accessibilité dans la majorité des cas ?»
Je le répète, cette liste n'est ni la solution parfaite ni la seule envisageable, mais je crois que c'est une bonne première étape, et qu'elle peut donner à nos développeurs et designers une bonne base de départ.
J'espère que la majorité des points ci-dessous sont faciles à comprendre, mais sur notre Wiki interne, nous fournirons aussi des liens pour que la plupart des points à vérifier renvoient vers une documentation plus détaillée. Pour tous les autres, je recommande WebAIM ou, à défaut, Google.
Checklist d'accessibilité
Balisage
- Séparez la structure de la présentation et utilisez le balisage correct pour cette structure. Par exemple, balisez bien les listes en tant que listes (
<ul>, <ol>, <dl>) et non comme du texte avec une balise<br>après chaque élément de liste. - Les titres HTML (par ex.
<h1>) sont très utiles pour les utilisateurs non-voyants. Marquez correctement les sections d'une page et le corps de texte avec des en-têtes HTML plutôt qu'avec une balise<p>associée à un style CSS qui lui donne un aspect de titre. - Donnez aux pages des titres précis et porteurs de sens à l'aide de la balise
<title>. - Indiquez le langage humain principal du document en utilisant l'attribut
langau sein de la balise<html>, et indiquez les passages en langage secondaire dans d'autres balises encadrant le passage concerné (par ex.<span lang="es">Hola</span>signifie Bonjour). - Proposez des liens «Aller au contenu» dès le début du balisage lorsque les pages contiennent beaucoup de liens de navigation avant le contenu principal.
- Indiquez toujours des en-têtes dans les tableaux de données avec des balises
<th>, et associez toutes les cellules de données à leurs en-têtes. - Assurez-vous que l'ordre des tabulations est logique, en utilisant
tabindexau besoin. (Si votre HTML est déjà dans le bon ordre, alors il n'est pas nécessaire d'utilisertabindex.)
Apparence visuelle et contenu
- Assurez-vous que votre page fonctionne toujours quand les images sont désactivées. (Ce qui peut impliquer de s'assurer que le contraste reste suffisant si vous utilisez une image de fond, et que cette image est enlevée.)
- Assurez-vous que les pages restent utilisables quand les utilisateurs agrandissent le texte au double de sa taille originale.
- Vérifiez que chaque élément de la page est accessible et manipulable au clavier.
- Chaque fois que c'est possible, rédigez des titres et des textes d'appel de liens qui puissent être compris hors contexte (donc, par exemple pas de liens titrés «cliquez ici»).
- Pour les daltoniens ou les malvoyants, assurez-vous de proposer un contraste suffisant entre le contenu et le fond de la page.
- N'utilisez aucun contenu qui clignote plus de trois fois par seconde.
- Ne cachez pas l'indicateur de focus. Quand un utilisateur navigue au clavier d'un élément à un autre avec des tabulations, il doit toujours savoir où ces éléments se trouvent.
- N'attendez pas des utilisateurs qu'ils perçoivent du sens grâce aux polices, aux couleurs ou à d'autres modifications de style. Par exemple, ne dites pas : «Le mot surligné dans le paragraphe précédent est le plus important», ni «Les éléments en rouge sont des erreurs qu'il faut corriger», sauf si le mot ou les éléments sont indiqués d'une autre façon.
Contenu dynamique
- N'utilisez pas d'événements JavaScript qui, en se déclenchant, altèrent totalement la page ou en chargent une nouvelle.
Images et multimédia
- Assurez-vous que toutes les images ont un attribut
alt(texte alternatif), et laissez ce texte vide pour les images décoratives (alt="") - Ajoutez toujours un texte alternatif quand les images constituent aussi des liens.
- D'une façon générale, soyez brefs dans les textes alternatifs (ex : «la statue de Christus»), mais donnez du détail dès lors qu'il y a du sens à transmettre (ex : «le fils du président Hinckley se tient près de la tombe de son père, entouré de toute sa famille»).
- Fournissez un script, des sous-titres, et/ou une traduction en langue des signes pour toutes les vidéos ou les sons contenant du discours.
- Fournissez une version «descriptive» d'une vidéo lorsqu'il est essentiel d'en comprendre le contenu pour des utilisateurs non-voyants. (La piste audio descriptive peut être distribuée soit avec le contenu vidéo, soit en fichier audio seul.)
- Assurez-vous que toutes les vidéos, si elles ne se lancent pas automatiquement, offrent au minimum une touche de lecture accessible.
- Quand du texte peut être interprété visuellement par le navigateur aussi bien que s'il s'agissait d'une image, évitez d'utiliser des images. (Les techniques de remplacement d'images constituent souvent une alternative acceptable, mais pensez aussi aux besoins de la traduction quand vous utilisez des images pour représenter du texte.)
- Évitez les Captchas (questionnaires de test visuels anti-robots) sauf si vous n’avez pas le choix, et même dans ce cas il est préférable de ne pas en utiliser. Néanmoins, si vous devez absolument y recourir, fournissez une alternative audio.
Formulaires
- Marquez tous les champs de formulaire avec la balise d'étiquetage
<label>. Si un champ de formulaire n'a pas d'étiquette de texte spécifique, ajoutez-en une, puis dissimulez-la à l'aide des CSS ou utilisez l'attributtitle. - Utilisez les regroupements de champs (
<fieldset>) avec des balises de titrage (<legend>) pour associer des demandes de saisie à des boutons radio et à des cases à cocher. Par exemple, un formulaire demande «Sexe :» et propose des boutons radio affichant «Homme» ou «Femme». Dans ce cas «Sexe :» devrait être placé dans une balise<legend>, et l'ensemble des trois éléments (<legend>ainsi que les deux boutons radio avec leurs étiquettes) dans une balise<fieldset>. - Recensez toutes les erreurs de saisie au format texte (en plus d'éventuelles images ou icônes), et placez le message d'erreur soit à côté du champ concerné, soit à un emplacement bien repérable, tel que le haut de la page avec un lien ancré vers le champ concerné.
- Offrez des liens d'aide ou des instructions en ligne pour remplir les champs si nécessaire.
- Ne laissez pas les utilisateurs effectuer des actions importantes sans leur proposer une confirmation ou un moyen d'annuler.
- Évitez d'utiliser des éléments HTML de façon non-standard (par ex. des éléments de formulaire servant à la navigation, des liens servant pour des envois de données de formulaire, etc.)
Tests
- Testez toutes vos pages pour valider le balisage (http://validator.w3.org). Si vos pages ne sont pas validées, il doit y avoir une bonne raison à cela.
- Testez l'accessibilité pour les daltoniens à l'aide de simulateurs ou de modules complémentaires pour navigateurs. (Recommandés : http://colororacle.cartography.ch ou http://www.vischeck.com)
- Testez l'accessibilité de toutes vos pages (http://wave.webaim.org), mais pas avant d'avoir fait tout ce que vous pouviez pour garantir leur accessibilité en suivant les recommandations de ce document.
- Faites vérifier vos pages par un expert de l'accessibilité.
http://northtemple.com/1608