Ma checklist de revue d'accessibilité

Outils de vérification d'accessibilité

Tester est la partie la plus importante. Même si vous ne connaissez pas tout de l'accessibilité, vous saurez ce qui ne va pas et ce que vous avez réellement fait, et vous pourrez commencer à améliorer les choses quelque part.

Il existe de nombreux outils qui permettent de tester correctement votre code et de vous donner des indications sur la règle et/ou le code à modifier.

Il y a plusieurs façons de tester un site. D'abord, il y a les outils de vérification d'accessibilité. Vous pouvez les utiliser via une extension de navigateur, directement via leur site, ou les intégrer comme outil dans votre projet.

N'oubliez pas que vous pouvez aussi utiliser les outils de développement, qui proposent certaines vérifications liées à l'accessibilité. Par exemple, vous pouvez forcer les couleurs du thème pour voir les changements. Personnellement, j'utilise l'extension de navigateur Accessibility Insights. Elle répond à mes besoins la plupart du temps et c'est un outil très complet.

Pour éviter de réinventer la roue, je vous conseille d'en apprendre plus sur la façon de commencer à tester l'accessibilité avec l'article de a11y.coffee.

Si vous voulez automatiser certains tests, c'est aussi possible.

« 57,38 % du total des problèmes ont été détectés lors de tests automatisés », selon Deque, vous trouverez plus d'informations sur leur site.

Pa11y est un excellent outil pour automatiser vos tests d'accessibilité : il existe Pa11y CI, conçu pour fonctionner en intégration continue. Vous pouvez trouver de nombreux tutoriels sur Pa11y sur leur site.

Balisage HTML

C'est quelque chose auquel on pense rarement, mais ça a un impact sur l'accessibilité. Les balises div et span n'ont aucune signification sémantique, et c'est vraiment important. Les éléments sémantiques sont reconnus par les navigateurs, mais aussi par les lecteurs d'écran et les autres technologies d'assistance. Je crois que je ne pourrais pas expliquer mieux leur importance que l'article Semantic Code. Why meaning is important d'accessibiltywise.info, par Edward Haynes.

Par exemple, pour décrire une liste non ordonnée, au lieu d'utiliser ce code :

<div>
   <span>Coffee</span>
   <span>Tea</span>
   <span>Water</span>
</div>

Vous pourriez utiliser ces éléments HTML spécifiques :

<ul>
   <li>Coffee</li>
   <li>Tea</li>
   <li>Water</li>
</ul>

Texte alternatif

Les images et les icônes sont jolies et esthétiques, mais elles n'ont aucun sens pour les personnes malvoyantes ou aveugles.

Beaucoup d'outils et de sites intègrent un texte alternatif pour que les personnes qui ne voient pas l'image, ou qui ont du mal à la voir, aient au moins sa description. La plupart du temps, c'est une courte description, mais c'est mieux que rien.

Sur le site, vérifiez que chaque média, en particulier les images, a un attribut alt.

Par exemple, pour ajouter la photo de l'entreprise sur une page, vous pourriez faire quelque chose comme ceci :

<img
   src="/path/to/img"
   alt="Photo of the Company Staff holding a flag"
>

Pour prendre un vrai cas d'usage, j'ai pris une image de mon blog ci-dessous : si l'image n'est pas accessible ou si le lien est simplement cassé, on obtient ce résultat, comme vous pouvez le voir ci-dessous :

Rendu d'une image cassée avec un texte alternatif

Labels

Souvent, les gens aiment se passer des labels ou les supprimer. Pour le design ou pour une autre raison, vous ne devriez pas le faire. Les labels visibles aident à savoir ce que représente un élément. C'est particulièrement important dans un formulaire, par exemple. Un exemple concret est le placeholder d'un champ de carte bancaire :

Utiliser un placeholder sans label sur le champ de la carte bancaire, par exemple, fait dire au lecteur d'écran « kisses kisses kisses kisses » (car le placeholder est xxxx-xxxx-xxxx-xxxx) au lieu de « numéro de carte bancaire »

L'enregistrement du lecteur d'écran est disponible.

Dans ce cas, le mieux serait d'ajouter un label relié au champ avec l'attribut for, comme ceci :

<label for="cardNumber">Card Number</label>
<input
   id="cardNumber"
   type="text"
   inputmode="numeric"
   pattern="[0-9]*"
/>

Il est possible d'ajouter une indication si besoin avec une balise span. Les gens devraient pouvoir saisir leur numéro de carte bancaire dans le format qui leur est familier. Cela veut dire pouvoir ajouter des espaces, des traits d'union et des tirets, tout en permettant de valider le bon format du champ.

Navigation au clavier

Naviguer sur un site peut être difficile si on n'aide pas les lecteurs et lectrices, surtout quand ils utilisent uniquement un clavier et/ou un lecteur d'écran. C'est pourquoi il faut utiliser le bon balisage HTML et réfléchir à la navigation. Le meilleur moyen est d'essayer de naviguer comme le ferait quelqu'un d'autre.

Vous remarquerez aussi l'importance de l'indicateur de focus dans ce type de navigation, pour savoir sur quel élément vous vous trouvez. Si vous avez un jour supprimé l'outline des éléments en CSS sans définir de nouvel indicateur, reconsidérez-le maintenant que vous savez ça.

Voici les étapes pour naviguer sur un site :

1. Parcourez votre page avec la touche Tab
2. Assurez-vous que chaque élément interactif peut être atteint.
3. Assurez-vous que chaque élément interactif peut être utilisé.
4. Assurez-vous que l'ordre est logique.
5. Assurez-vous que le focus est visible, non masqué et suffisamment contrasté.
6. Faites la même chose dans l'autre sens avec Maj + Tab
7. Assurez-vous qu'il n'y a pas de piège au focus

La navigation est censée suivre un ordre logique entre les éléments. Si vous voyez quelque chose qui ne va pas, vous pouvez chercher comment le corriger. Cette partie est plus facile quand vous avez des retours ou que vous demandez à d'autres personnes de vérifier que tout est correct.

Couleurs et contraste

Les couleurs et le contraste ont un impact sur beaucoup d'utilisateurs et d'utilisatrices : handicaps, confort de lecture la nuit, basse vision, etc. C'est important, car c'est la première chose qu'on voit en plus du contenu. Un faible contraste rend les choses difficiles à distinguer et à lire, en particulier pour les personnes ayant une faible acuité visuelle ou un daltonisme.

Il existe de nombreuses façons de s'assurer que le contraste est suffisant et que tout le monde peut lire. Les devtools de votre navigateur vous aident à vérifier directement les éléments qui ont une couleur et/ou un arrière-plan.

Contraste des couleurs d'un texte de la barre latérale avec les devtools de Chrome sur djangoproject.com

Vous pouvez aussi ajouter une extension à votre navigateur pour vérifier les couleurs et le contraste. Par exemple, j'utilise personnellement colorblindly sur Chrome pour voir les différences entre les types de vision des couleurs qui peuvent exister.

Enfin, il existe des sites ou des outils dédiés qui vous aident à vérifier le contraste pour des cas précis. J'aime beaucoup whocanuse.com pour voir les différents types de vision entre une couleur et la couleur d'arrière-plan associée.

Si vous voulez comparer deux couleurs avec une matrice, contrast-grid d'eightshapes.com est mon outil de référence.

Il existe des outils spécifiques qui vous aident à adapter la couleur en fonction de l'image, par exemple. On le voit sur les réseaux sociaux, comme Instagram : le texte sur un arrière-plan sera blanc ou noir selon la couleur, pour garantir un contraste correct.

Attributs ARIA

ARIA est l'abréviation d'Accessible Rich Internet Applications. C'est utile pour fournir des informations accessibles en complément de la sémantique HTML, mais ça ne doit être utilisé que lorsque c'est nécessaire.

Par exemple, c'est quelque chose à utiliser pour indiquer l'élément courant : page, section... Un bon exemple est le fil d'Ariane :

<nav aria-label="breadcrumbs">
   <ol>
      <li>
         <a href="/">Home</a>
      </li>
      <li>
         <a href="/blog">Blog</a>
      </li>
      <li>
         <a
            href="/blog/accessibility"
            aria-current="page"
         >
            Accessibility
         </a>
      </li>
   </ol>
</nav>

Le risque avec ARIA, c'est que les gens pensent qu'il faut à chaque fois ajouter un attribut, et ce n'est pas le cas. La sémantique HTML peut suffire dans certains cas. Par exemple, une balise button n'a pas besoin d'avoir un rôle, elle a automatiquement le rôle button. Vous trouverez plus d'informations sur les rôles ARIA sur le site MDN.

Landmarks

Les landmarks (ou points de repère) sont les « sections » qui structurent le site : header, main, footer, nav...

Ils peuvent être définis via les balises HTML : main a sa propre balise, ce qui permet de définir le contenu principal de la page.

Les landmarks sont particulièrement utiles pour structurer la page, mais aussi pour passer facilement d'une section à l'autre avec un lecteur d'écran.

Landmarks affichés avec des carrés sur djangoproject.com avec Accessibility Insights*

Une chose à ne pas oublier : si un même type de landmark est utilisé plusieurs fois, par exemple <nav> pour le landmark de navigation, chaque occurrence a besoin d'un aria-label pour les distinguer.

Lecteurs d'écran

Les lecteurs d'écran sont très utiles pour les personnes en situation de handicap ou qui préfèrent les utiliser pour se faciliter la vie. Beaucoup pensent que c'est uniquement pour les personnes aveugles, mais ce n'est pas le cas. Une personne dyslexique peut utiliser un lecteur d'écran sur son ordinateur, tout comme une personne ayant des troubles de la motricité, même temporaires par exemple. Le lecteur d'écran annonce le contenu d'un site via la synthèse vocale ou sur une plage braille. Il propose aussi plusieurs façons d'interagir avec le site au clavier, il ne s'agit pas seulement de lire le contenu : remplir un formulaire, interagir avec le navigateur, etc.

Il existe différents lecteurs d'écran selon l'appareil ou le navigateur pris en charge et les fonctionnalités. JAWS et NVDA sont les plus populaires. VoiceOver est celui installé par défaut sur les appareils Apple. Les systèmes d'exploitation Microsoft utilisent le Narrateur. Les appareils Android proposent le lecteur d'écran TalkBack ou VoiceView par défaut. Pour les systèmes Linux et Unix, il y a Orca ou SpeakUp. Vous devriez pouvoir trouver un lecteur d'écran pour votre appareil.

Il suffit d'essayer de vous mettre à la place de quelqu'un qui ne voit pas parfaitement le site et de le parcourir avec l'outil.

Conclusion

Pour résumer, cette checklist de revue d'accessibilité est un bon moyen d'initier les gens à l'accessibilité et de relire vos propres sites pour corriger les erreurs qui pourraient empêcher des personnes de les utiliser. C'est ma propre checklist, mais il en existe beaucoup d'autres très bien, vous pouvez jeter un œil à la liste ci-dessous.

Un grand merci aux personnes qui ont relu cet article, elles se reconnaîtront. Merci pour votre soutien 💚

-- Que le futur soit accessible grâce à ces checklists ⭐