• 6 heures
  • Facile

Ce cours est visible gratuitement en ligne.

course.header.alt.is_video

course.header.alt.is_certifying

J'ai tout compris !

Mis à jour le 26/01/2024

Créez des tests d'accessibilité

Optez pour une approche holistique d'évaluation de l'accessibilité

Une bonne méthodologie de test de l'accessibilité associe différentes techniques de test. Aucune approche unique ne peut mettre à jour tous les problèmes. En fonction du critère WCAG que vous évaluerez, vous aurez besoin d'utiliser différents outils.

Pour une évaluation minutieuse, utilisez une combinaison de tests automatisés, manuels, et reposant sur les technologies d'assistance. Le guide de test disponible dans les supports du cours fournit des instructions détaillées étape par étape concernant les éléments à rechercher pour tester chaque critère. Dans la section Procédure de test du guide, vous verrez qu'il existe trois méthodes. Certains critères peuvent être testés à l'aide des trois, tandis que d'autres peuvent uniquement être évalués à l'aide d'une d'entre elles. Vous serez probablement amené à alterner entre ces méthodes. Si un problème survient pendant un contrôle automatisé, ou si vous rencontrez un comportement étrange en utilisant les technologies d'assistance, vous devrez creuser un peu plus en inspectant manuellement le code. Considérez ces méthodes comme autant de facettes qui se complètent pour fournir une vue d'ensemble plus précise.

Les outils de test d'accessibilité

Avant de commencer les tests, téléchargez les outils de test suivants.

Vérificateurs automatisés

Il existe de nombreux outils de test automatisés. La plupart d'entre eux identifient les mêmes types de problèmes, mais peuvent les présenter de différentes manières. Certains les affichent visuellement sur la page, d'autres les présentent sous forme de liste. Le plus important, c'est de trouver celui que vous aimerez utiliser.

HeadingsMap

HeadingsMap génère une carte de rubriques semblable au volet de navigation dans Microsoft Word. Il vous permet de voir rapidement la structure des rubriques de la page. Il identifie les instances de niveaux de titre omis et vous donne une bonne idée générale de la pertinence de la structure de la page.

Extension Chrome HeadingsMap qui montre la structure des titres de la page Wikipedia sur l'accessibilité, présentée sous forme d'une liste testée.
Extension Chrome HeadingsMap

TPG Color Contrast Analyzer

TPG Color Contrast Analyzer est un outil formidable pour tester le contraste. Vous pouvez l'utiliser dans n'importe quel environnement, peu importe que vous évaluiez une maquette ou testiez une page web ou un document.

Un outil d'analyse de contrast qui montre du texte bleu clair sur un fond gris foncé. Le ratio de contrast est de 4,57:1, validant les prérequis pour un texte classique de niveau AA et pour du texte en grand et gras pour les niveau AA et AAA.
TPG Colour Contrast Analyser

Vous pouvez utiliser l'outil Eye Dropper ou saisir les valeurs hexadécimales exactes de vos couleurs pour obtenir les résultats les plus précis. Cet outil vous fournit le rapport de contraste exact et vous montre rapidement s'il répond aux exigences des critères AA et AAA relatives au texte ordinaire et au texte agrandi.

Lecteurs d'écran

Pour les tests, si vous travaillez sur Mac, vous pouvez utiliser l'outil VoiceOver intégré. Si vous travaillez sous Windows, vous pouvez utiliser NVDA. Même si JAWS est le lecteur d'écran le plus courant, son coût est élevé, ce qui est préjudiciable non seulement pour votre portefeuille, mais aussi pour vos conclusions. Votre objectif étant d'identifier les problèmes d'accessibilité, il n'est pas souhaitable d'utiliser un lecteur d'écran perfectionné tel que JAWS qui est très performant pour corriger certains problèmes afin de créer une meilleure expérience pour l'utilisateur. NVDA est gratuit et vous êtes plus susceptible de détecter les erreurs en l'utilisant. De plus, il se classe deuxième en termes de nombre d'utilisateurs.

Vous pouvez également effectuer des tests de lecteur d'écran sur mobile. Tous les smartphones sont équipés d'un lecteur d'écran intégré : VoiceOver avec iOS, TalkBack sur la plupart des appareils Android et VoiceAssistant pour Samsung. Les lecteurs d'écran fonctionnant différemment avec les commandes tactiles, c'est un bon moyen de tester un mode d'interaction différent.

À vous de jouer : préparez votre session de test

Avant de commencer à tester, il est recommandé de configurer votre session :

  1. Sélectionnez le contenu que vous allez tester. Lorsque vous testez un site web, vous n'avez généralement pas besoin d'étudier chaque page pour avoir une idée de son niveau d'accessibilité. Vous pouvez sélectionner un échantillon de quelques pages qui couvre l'étendue des fonctionnalités offertes. Vous devez vous assurer que cet échantillon est représentatif et comprend différents types de contenu, tels qu'une page d'accueil, une page de contenu ordinaire, un formulaire interactif, du contenu multimédia, etc. Je constitue généralement un échantillon de 10 à 15 pages pour un site web standard, mais cela dépend du projet sur lequel vous travaillez. Ouvrez chaque page dans son propre onglet dans différents navigateurs. La plupart des plug-ins de test que nous utilisons dans ce cours sont disponibles dans Chrome. Si vous utilisez un PC, ouvrez Firefox pour utiliser le lecteur d'écran NVDA. Si vous êtes sur Mac, ouvrez Safari pour utiliser VoiceOver.

  2. Gardez la documentation de référence à portée de main. Je garde toujours le document WCAG ouvert pour m'y référer, ainsi que d'autres ressources telles que le guide de test disponible dans les supports du cours.

  3. Créez un document dans lequel vous résumerez vos conclusions. Je trouve que la meilleure approche consiste à utiliser un modèle de rapport qui organise les conclusions par critère de succès WCAG. Mais vous pouvez utiliser une solution aussi simple qu'un document Word vierge, dans lequel vous noterez vos conclusions point par point.

Maintenant que vous avez terminé la configuration de votre session, réfléchissez à la manière dont vous allez communiquer vos conclusions.

Générez un rapport contenant vos conclusions

Vous devrez partager vos conclusions avec d'autres personnes, au sein de votre équipe ou avec d'autres. Selon moi, deux approches fonctionnent bien pour résumer les conclusions.

Rapport basé sur les règles WCAG

Si vous évaluez un site dans son ensemble, il peut être utile d'organiser vos conclusions en vous basant sur les critères de succès WCAG. Vous pouvez créer un tableau comportant les colonnes suivantes :

  • nom et numéro du critère de succès : identifiez le critère par son nom et son numéro de référence, et incluez un lien pointant vers le document WCAG pour plus de commodité ;

  • statut général : je suggère d'utiliser « Répond aux attentes/Exige des corrections mineures/Exige des corrections majeures » (comme je l'ai mentionné au chapitre 1.3, l'utilisation de termes tels que Validé/Rejeté promeut l'idée selon laquelle les règles WCAG pourraient être utilisées en tant que liste de contrôle) ;

  • commentaires : détaillez vos conclusions en leur ajoutant des exemples spécifiques, des captures d'écran et des recommandations, dans la mesure du possible. Vous ne pourrez pas toujours formuler de recommandations, soit parce que vous n'avez pas rencontré un problème auparavant, soit par qu'il est si complexe qu'il exige de repenser complètement le design. Ne vous sentez pas obligé de trouver une solution à chaque problème. En cas de doute, décrivez simplement le problème rencontré et précisez qui il concerne, selon vous. 

Vous pouvez utiliser des tableaux distincts pour chaque principe, voire pour chaque règle.

Rapport basé sur les tâches

Si vous cherchez à évaluer l'accessibilité de tâches ou de workflows spécifiques, il peut être plus utile d'effectuer les tests d'accessibilité tâche par tâche. Identifiez les étapes, puis suivez-les en prenant note des obstacles à l'accessibilité susceptibles d'empêcher les utilisateurs de réaliser ces tâches. Le contexte de la tâche peut aider les membres de l'équipe à comprendre la gravité des problèmes et la manière dont ils peuvent impacter les utilisateurs. Par exemple, si vous testez un formulaire d'inscription à une newsletter comportant un bouton Envoyer qui n'est pas accessible avec un clavier, vous pouvez indiquer que ce problème empêchera les utilisateurs de solutions de navigation alternative, de lecteurs d'écran et de transcripteurs en Braille de s'inscrire à la newsletter.

En résumé 

  • Appliquez une stratégie de tests d'accessibilité holistique associant des tests automatisés, des tests manuels et des tests au moyen de technologies d'assistance.

  • Le plug-in HeadingsMap de Chrome peut rapidement vous présenter la structure des rubriques de votre page, comme le fait le volet de navigation dans Microsoft Word.

  • TPG Colour Contrast Analyser est un outil formidable pour tester le contraste dans n'importe environnement.

  • L'utilisation de lecteurs d'écran moins perfectionnés est préférable pour révéler les problèmes d'accessibilité.

Vous êtes prêt à commencer vos tests ! Intéressons-nous tout d'abord à quelques outils automatisés.

Exemple de certificat de réussite
Exemple de certificat de réussite