Guide d’accessibilité pour développeur·euse web : ma routine accessibilité lors d’un développement
Lors du développement d’une application, la facette de l’accessibilité est souvent laissée de côté dans l’optique d’être gérée “plus tard”. Or, dans la dynamique d’un projet le “plus tard” a tendance à se transformer en “jamais”, puisqu’il y aura toujours mieux à faire lorsque le “plus tard” devient “maintenant”.
En ce qui me concerne, je considère que la place du test unitaire et celle de l’accessibilité dans le cycle de développement sont similaires. S’il n’est pas écrit durant la phase de développement, le test unitaire ne sera généralement jamais écrit du tout. La mise en place de l’accessibilité suit la même logique.
Penser accessibilité au fil de l’eau, d’accord. Mais comment faire ? Il n’y a pas de recette miracle, d’autant qu’une application n’est pas soit 100% accessible, soit 0% accessible. Il s’agit d’un curseur qui navigue entre ces deux eaux. Si les moyens mis en place sont suffisants, l’accessibilité tendra davantage vers les 100% que vers les 0%.
Les quelques gestes proposés dans la suite de l’article sont autant d’outils qui permettent de tendre vers une meilleure accessibilité, sans pour autant être une garantie d’obtenir une accessibilité totale. Ils peuvent être appliqués au fil de l’eau, ou juste avant la livraison finale d’un incrément dans le développement, par exemple. Libre à vous de piocher les gestes intéressant dans votre contexte et organisation de travail.
Tests automatisés ou semi-automatisés
Intégrer l’accessibilité dans les tests unitaires
Les tests unitaires d’une application s’appuient sur le rendu et le comportement de composants. S’assurer de la conformité d’un comportement JS et HTML via les tests unitaires permet de soulager une partie du test manuel indispensable dans l’accessibilité. Par ailleurs, ils apportent une assurance de non-régression et de couverture garantie dans le temps.
Les test unitaires permettent par exemple de s’assurer que les attributs ARIA sont correctement gérés et sont en adéquation avec le fonctionnement de l’application, ou encore que le focus est bien géré au sein des composants.
Exemple de test sur la bonne gestion d’un attribut aria-expanded au clic sur un bouton, avec vue-test-utils :
it("should have an aria-expanded attribute", async () => {
// Given
const wrapper = shallowMount(MyComponent);
const openDetailsButton = wrapper.find(`[data-testid="open-details-button"]`);
expect(openDetailsButton.attributes("aria-expanded")).toBe("false");
// When
await openDetailsButton.trigger("click");
// Then
expect(openDetailsButton.attributes("aria-expanded")).toBe("true");
});Exécuter le plugin Wave
L’initiative WebAIM (pour Web Accessibility In Mind) a développé une extension pour navigateur (Chrome, Firefox, Edge) qui permet d’effectuer en un clic une évaluation de l’accessibilité de la page actuellement ouverte dans le navigateur.
En quelques mots, l’extension est capable de mettre en lumière les défauts d’accessibilité (qui sont détectables par un outil automatisé), montre l’ordre de navigation naturelle au clavier, synthétise l’arborescence de titres… et donne des éléments intéressants pour corriger les éventuelles erreurs dans la page.
Il faut néanmoins rappeler que l’accessibilité ne peut jamais être totalement automatisée. Si l’extension Wave n’indique qu’aucune erreur n’a été détectée, il faut rester prudent sur le fait qu’il ne s’agit que des erreurs potentiellement détectables de façon automatisée.
L’extension peut être téléchargée ici pour tous les navigateur supportés
Exécuter un audit Lighthouse
Lighthouse est un second outil d’audit automatisée à exécuter dans le navigateur (ou en ligne de commande), et propose dans les grandes lignes des fonctionnalités proches de l’extension Wave. Si l’accessibilité n’est pas encore une langue naturelle pour vous, l’utilisation des deux outils en parallèle peut vous aider à monter en compétence et détecter davantage d’anomalies.
Cette extension a l’avantage de donner un score d’accessibilité sur une échelle allant de 0 à 100, qui peut être pratique pour potentiellement suivre une tendance de progression dans le temps. La contrepartie est que son exécution prend quelques secondes, là où celle de Wave est quasiment instantanée.
Néanmoins, des conseils pour corriger les erreurs d’accessibilité sont également proposés, et une bonne pédagogie est faite sur les aspects à vérifier manuellement.
Lighthouse est présent nativement dans les devtools de Chrome.
Vérifier la structure de titres avec HeadingsMap
Spécialisée dans la structuration des titrages de la page, l’extension HeadingsMap permet de générer en un clic un récapitulatif des titres présents dans la page, sous la forme d’une sorte de table des matières. L’extension Wave propose également cette fonctionnalité, mais le rendu visuel est plus lisible dans HeadingsMap.
Cette extension permet de vérifier facilement que la structure de la page est logique et cohérente. Il faut néanmoins rappeler qu’un saut de titre (par exemple un passage de h2 à h4 sans h3 intermédiaire) n’est pas problématique sur le plan de l’accessibilité. Néanmoins, avoir une structure de page bien faite aide à l’utilisabilité de la page.
HeadingsMap est disponible en tant qu’extension pour la plupart des navigateurs. Ici un lien vers l’extension Chrome.
Tests manuels
Toutes les étapes précédentes permettent de mener des tests automatisés ou semi-automatisés. Néanmoins, l’accessibilité doit malgré tout être vérifiée par un humain pour s’assurer qu’elle répondra aux besoins de tous.
S’il fallait concentrer ses efforts dans une seule direction, c’est le test manuel avant tout.
Tester au clavier sans souris
Le test au clavier revient à effectuer les parcours utilisateur·trice sans se servir de la souris. Si vous ne pouvez pas effectuer exactement les mêmes parcours en utilisant exclusivement le clavier, alors il faut adapter l’implémentation pour le permettre.
Parmi les actions à tester, on peut entre autres penser à :
- tous les liens et boutons sont-ils atteignables et activables ?
- tous les formulaires peuvent-ils être remplis ?
- y a-t-il des zones de la page qu’il est impossible d’atteindre ou de quitter ?
En résumé, l’expérience de l’application doit être (à quelques exceptions près) la même, que ce soit en utilisant le clavier ou le clavier et la souris.
Tester au lecteur d’écran (et les yeux fermés)
Le test au lecteur d’écran est le test ultime qui permet de relever bon nombre d’anomalies d’accessibilité. Par ailleurs, ce test peut tout à fait se combiner avec le test au clavier sans souris.
Pour aller plus loin, si vous êtes assez confortable avec l’outillage pour effectuer ce test les yeux fermés (ou l’écran éteint), cela poussera le test au plus proche des conditions réelles d’une part de votre audience.
Le défi est de parvenir à dérouler des parcours utilisateur·trices simplement en se laissant guider par la synthèse vocale. Ce test permet notamment de mettre en lumière les problématiques telles que :
- les boutons et liens avec des noms peu accessibles (ex: un lien “Consulter” noyé au milieu de dizaines d’autres liens intitulés “Consulter”, ou encore des boutons image sans libellé).
- des informations manquantes qui sont contenues dans des images, ou dans les couleurs seules, ou encore la mise en page. A contrario, cela permet aussi de détecter si une information arrive en doublon (par exemple avec une utilisation maladroite d’ARIA).
Conclusion
Ces mesures du quotidien sont un atout pour aider à ne pas laisser l’accessibilité se détériorer au fil du temps, mais elles doivent être complétées par quelques exercices complémentaires. Il est fortement conseillé de procéder à un audit régulièrement (par un cabinet externe, ou en interne en s’appuyant par exemple sur le RGAA) pour prendre la température et corriger le tir sur les éventuels points problématiques, mais également pour aider à sensibiliser sur les questions qui resteraient dans l’angle mort de l’équipe en charge du développement du produit.
Par ailleurs, certains aspects ont été laissés de côté, tels que les tests pour vérifier l’accessibilité à certaines déficiences visuelles ou auditives. Ces conseils sont donnés dans une approche Pareto, à savoir adresser les problèmes les plus courants avec un effort modéré, afin d’éviter que la charge ne soit décourageante et que l’accessibilité soit au final laissée de côté.
Pour aller plus loin sur la découverte et la prise en main d’un lecteur d’écran, cet article présente le B-A BA sur NVDA, et cet autre article montre comment naviguer de façon directe vers les éléments clés de la page.
