Stratégie de tests a11y (pour l’accessibilité web)

L’accessibilité est une exigence forte pour les sites et applications web, qui s’impose légalement en France à travers le RGAA (Référentiel Général d’Amélioration de l’Accessibilité). Cependant, contre-intuitivement, ne foncez pas sur un audit RGAA ! S’il permet d’établir la conformité finale, l’audit n’est pas adapté pour guider l’implémentation de l’accessibilité. Il existe d’autres façons de vérifier, plus opérationnelles et plus simples.

La réussite de l’accessibilité web (a11y) se jouant lors de la fabrication, il est indispensable de tester régulièrement, au plus tôt. L’inspection humaine est incontournable, mais des outils existent qui aident à tester et même monitorer l’accessibilité. Une approche efficace alliera donc tests techniques et manuels, de manière complémentaire et progressive.

Erreurs courantes à éviter

L’approche de l’accessibilité n’étant pas toujours intuitive, commençons par éviter quelques fausses bonnes idées et erreurs courantes :

Demander aux handicapés de tester

Le premier réflexe, légitime, des designers, est de se tourner vers les personnes handicapées pour leur demander de tester le produit, souvent de but en blanc. Réaliser des tests d’utilisabilité auprès du public concerné est toujours une bonne idée… à condition d’avoir préalablement vérifié le bon fonctionnement du produit !

En l’occurrence — de la même façon qu’on n’engage pas de tests d’utilisabilité sans avoir d’abord vérifié le bon déroulé des parcours de navigation et le respect minimal des règles d’ergonomie — on n’invite pas une personne aveugle à tester… sans avoir d’abord vérifié le parcours en synthèse vocale ! N’oubliez pas qu’il existe une norme d’accessibilité, à respecter pour que ça fonctionne.

Comme le rappelle ce verbatim : « Comprenez qu’on n’en peut plus d’attendre. Les WCAG [norme ISO d'accessibilité] ont 23 ans. La loi française a 17 ans. Plus de 97 % des sites web sont inaccessibles. Pourquoi encore exiger de nous qu’on remonte gentiment et gratuitement les problèmes ? » (Julie Moynat).

Commencer par un audit d’accessibilité

Puisqu’il existe une norme d’accessibilité, la tentation est forte de s’y mesurer en commençant par « un audit pour savoir où on en est ». Mais si aucune action particulière n’a été entreprise, l’audit ne vous apprendra rien. En effet, l’accessibilité n’est pas une bonne surprise qui se découvrirait au hasard d’un audit, mais le résultat d’une démarche volontaire incluant des gestes de fabrication précis. En l’absence de démarche, l'inaccessibilité est certaine ; pas besoin d’audit pour le découvrir.

Pire, un audit à ce stade peut s’avérer contre-performant : la quantité d’erreurs soudainement révélées, bien que même pas exhaustive, peut décourager durablement les équipes à l’œuvre. À plus forte raison, l’approche corrective, hélas si courante, à coup d’audits seulement, est douloureuse pour les équipes, peu pérenne et onéreuse. Il existe d’autres façons d’évaluer, plus simples et progressives.

Se contenter de tests automatisés

Vous utilisez un outil de test des pages web qui incorpore un score d’accessibilité et vous pensez que votre produit est accessible lorsque ce score atteint 100 % ? C’est bien, mais ça ne teste pas tout, car seule une partie des critères d’accessibilité sont testables de façon automatisée. Aucun outil n’est suffisant à lui seul pour déterminer si un site web respecte les standards d’accessibilité.

Vérifier l’accessibilité, c’est avant tout s’assurer que l’expérience utilisateur est possible pour tous et toutes : ça se teste humainement. La majorité des tests d’accessibilité sont fonctionnels et s’effectuent par des manipulations. Mais savez-vous que plusieurs sont particulièrement faciles à réaliser ?

Déployez les tests progressivement

Une bonne stratégie de tests d’accessibilité allie donc tests techniques et manuels de façon complémentaire. Pour être efficace, elle se déploie progressivement et par degrés successifs, c’est-à-dire que chaque étape prépare la suivante. Corollaire : inutile de s’engager dans une étape tant que les tests de l’étape précédente ne sont pas positifs.

Ce schéma résume la démarche (décrite ci-après) et permet aussi de situer votre avancement, pour savoir quelle typologie de tests adopter pour améliorer votre accessibilité : inutile d’envisager l’audit si vos tests manuels échouent. Ni d’inspecter manuellement en l’absence de tests techniques.

1. Tests auto (TA)

La majorité des critères d’accessibilité concernent le code développé. Heureusement, la vérification d’une partie d’entre eux est automatisable et peut même être prise en charge dans la chaîne d’intégration continue.

1.a Validation HTML

Avant toute chose, assurez-vous de produire un code exempt d’erreurs ! La validité du code HTML, en particulier, est exigée au critère 8.2 du RGAA 4 : ce langage qui structure toute page web doit respecter les standards internationaux spécifiés par le W3C. C’est essentiel pour que votre site soit correctement exploité par les différents outils : navigateurs, plugins divers, synthèse vocale et autres assistances techniques.

Vous pouvez tester cela très facilement — essayez-vous même ! — avec le validateur HTML mis à disposition par le W3C. Les développeurs et développeuses web doivent donc s’en servir quotidiennement.

La validité du code HTML est aussi un prérequis au bon fonctionnement des outils de tests qui suivent.

1.b Tests a11y automatiques

Le sujet n’étant pas nouveau, il existe de nombreux outils automatisant les tests d’accessibilité, qui sont recensés par le W3C : Web Accessibility Evaluation Tools List. Ceux-ci peuvent être utilisés ponctuellement (sous forme de plugin navigateur ou de service web) ou mieux : être déployés dans votre chaîne d’intégration continue (CI/CD). Parmi ceux-ci, les plus connus sont Wave et Axe, outils historiques que nous utilisons avec satisfaction. Pour les sites web publics, citons aussi Tanaguru et Asqatasun qui supportent plus spécifiquement le RGAA.

Ces outils couvrant un quart des critères d’accessibilité, la réussite de ces tests permet d’atteindre environ 25 % de conformité. C’est un objectif raisonnable pour débuter en accessibilité, mais aussi pour les MVP, POC et prototypes. Ces tests restent indispensables quel que soit le projet et son avancement, afin d’éviter d'engranger trop de dette technique d'accessibilité, si coûteuse à résorber. Autre avantage : le score délivré par ce type d’outils fournit un indicateur, certes insuffisant, mais simple à suivre.

2. Tests manuels « Easy Checks »

Vérifier l’accessibilité, c’est avant tout s’assurer que l’expérience utilisateur est possible pour tous et toutes : ça se teste humainement. Aucun outil n’est donc suffisant à lui seul pour vérifier l’accessibilité : des vérifications manuelles doivent venir compléter. Parmi celles-ci, une dizaine de tests simples, comme naviguer au clavier ou grossir les caractères, peut s’effectuer rapidement — 10 tests en 10 minutes — et s’insérer donc facilement dans les recettes de chaque itération.

Consistant à simuler divers cas d’usage, ces tests ne nécessitent pas de connaissances techniques. Nul besoin d’expertise ni de logiciels payants pour y arriver : n’importe qui peut faire ces tests. Aussi simplement que réduire la fenêtre du navigateur pour vérifier le responsive est désormais un réflexe pour tout le monde. Par exemple :

• Ouvrir plusieurs pages d’un site web dans différents onglets pour s’assurer que leurs titres sont distincts les uns des autres et permettent d’identifier chaque page.
• Cacher la souris et naviguer seulement à l’aide du clavier (touches Tab, Maj+Tab, flèches, Enter...) : tout ce qui est faisable à la souris doit l’être au clavier également.

Chaque membre de l’équipe s’approprie aisément ces tests, vérifiant l’accessibilité à chaque étape de fabrication, sous la houlette du PO : le graphiste s’assurera que les contrastes sont suffisants, la développeuse que les titres sont correctement balisés, les rédacteurs et rédactrices que les images et vidéos sont dûment pourvues d’alternatives textuelles, etc.

Le protocole de ces tests est décrit (en anglais) par le W3C : Easy Checks – A First Review of Web Accessibility et un résumé est disponible en français : 10 choses faciles à vérifier pour un site plus accessible. Si besoin, une formation permettra d’apprendre à les effectuer : Techniques de vérification d’accessibilité.

L’expérience nous a appris que la pratique régulière de ces tests manuels permet d’ambitionner environ 50 % de conformité . Leur régularité, a minima tous les 15 jours, avant chaque mise en service, évite les régressions majeures d’accessibilité, autrement coûteuses à résorber.

3. Audit de conformité

Quand vous commencez à vous ennuyer avec ces Easy Checks, parce qu’ils ne vous révèlent plus de défaut d’accessibilité, c’est que le temps est venu de faire appel à un regard extérieur expert et de vous confronter à la norme d’accessibilité. Pas avant.

La conformité à la norme s’évalue via un audit. Celui-ci porte sur un échantillon de pages représentatif du service, passé au crible de quelques centaines de critères et tests, définis en France par le RGAA (Référentiel Général d’Amélioration de l’Accessibilité) dont le site officiel met méthodologie de test et kit d’audit à disposition. Cet audit expert est généralement suivi de vos correctifs et d’une contre-visite afin de tenir compte de ceux-ci pour établir le taux de conformité à indiquer dans vos mentions légales d’accessibilité.

Vos actions correctives à la suite de l’audit seront d’autant moins nombreuses et laborieuses que les tests précédents auront été faits avec régularité. Validité HTML, tests auto et Easy Checks constituent donc un prérequis qui prépare l’audit de conformité.

4. Tests d’utilisabilité (TU)

Lorsque les tests techniques et fonctionnels sont satisfaisants et que l’audit révèle un taux de conformité avoisinant 75 %, il devient possible de conduire des tests d’utilisabilité. Ceux-ci permettront enfin d’améliorer l’expérience (UX) des utilisateurs et utilisatrices concerné·es.

4.a Tests avec lecteur d’écran

Les personnes aveugles et malvoyantes, mais aussi dyslexiques, utilisent différents lecteurs d’écrans, comme VoiceOver sur Safari dans iOS ou Jaws sur Internet Explorer dans Windows : ces cas d’usages doivent donc être testés, tout comme vous vérifiez la compatibilité avec différents navigateurs. Voici comment utiliser un lecteur d'écran pour tester votre site et les environnements de tests à privilégier. Cela permet aussi de préparer les TU en repérant les scénarios à tester.

4.b Tests avec des personnes handicapées

Faites appel à un·e designer UX expert·e en accessibilité pour organiser ces tests : définir la cible en termes de couple navigateur et aide technique, identifier les scénarios afférents et constituer un panel de 4 à 5 utilisateurs d’aides techniques, afin de recueillir l’appréciation ergonomique, mais aussi le ressenti d’accessibilité après interaction. Pour ce faire, suivons les bons conseils partagés en ligne : Méthode de test d’accessibilité avec des utilisateurs et Mettre en place des tests utilisateurs en accessibilité.

En résumé

1. D’abord automatiser autant que possible, en s’appuyant sur des « moulinettes » qui ont fait leurs preuves, installées par les dev dans la CI — soit environ « 0 % d’effort pour 25 % de conformité » ;
2. puis compléter par une inspection manuelle régulière en 10 Easy Checks, guidée par les PO — soit environ « 25 % d’effort pour 50 % de conformité ».
3. Ceci prépare efficacement l’audit de conformité, réalisé par un·e expert·e tiers, pour aider à identifier les derniers défauts.
4. Enfin, à partir de 75 % de conformité, des tests d’utilisabilité, conduit par un UX designer, permettront d’améliorer l’expérience utilisateur.

Alors, où en êtes-vous de vos pratiques de tests d’accessibilité ?

Pour aller plus loin, le site du W3C offre de nombreuses ressources (Évaluer l'accessibilité Web - Vue d'ensemble) et nos prochains articles détaillerons l’implémentation de tests techniques d’accessibilité. L’accessibilité, on s’en fait toute une montagne, mais ce n’est pas si compliqué, suivez le guide : consultez notre RefCard dédiée à l'accessibilité !