Apprentissage des bases des tests d’accessibilité
Objectifs de formation
Une fois cette unité terminée, vous pourrez :
- Reconnaître l’importance de réaliser des tests d’accessibilité
- Résumer les avantages et les inconvénients de l’automatisation des tests d’accessibilité
- Identifier les outils que vous pouvez utiliser pour automatiser les tests d’accessibilité
- Décrire des stratégies pour écrire vos propres tests d’accessibilité automatisés
Objectif des tests d’accessibilité
Les tests d’accessibilité permettent de s’assurer que les produits numériques, tels que les sites Web et les applications, sont utilisables par tous, y compris les personnes en situation de handicap. Cela signifie qu’il faut trouver et retirer les obstacles à l’accessibilité avant même que les utilisateurs ne les rencontrent. Dans l’idéal, il ne devrait exister dès le départ aucun bogue d’accessibilité, mais il se trouve que certains d’entre eux apparaissent durant le développement. Chaque fois que vous développez quelque chose, votre objectif est de vous assurer qu’aucun de ces bogues ne touche vos utilisateurs.
Dans un monde idéal, des tests d’accessibilité sont effectués tout au long du cycle de vie du développement. Cette démarche commence durant la phase de conception, se poursuit pendant le développement et est suivie même après le déploiement. Grâce à cette approche proactive, vous avez la garantie de prendre en compte et d’intégrer l’accessibilité à chaque étape.
La réalisation de tests d’accessibilité vous permet de :
- créer une expérience numérique inclusive qui assure l’égalité d’accès ;
- répondre aux exigences réglementaires et légales ;
- toucher un plus grand nombre d’utilisateurs ;
- renforcer la qualité de l’expérience utilisateur globale.
Dans ce module, nous abordons les tests automatisés et manuels, qui sont tous deux d’une importance essentielle pour mener une démarche complète en manière de tests d’accessibilité. Commençons par nous intéresser aux tests d’accessibilité automatisés.
Avantages et inconvénients de l’automatisation des tests d’accessibilité
Comme vous le savez probablement déjà, les tests d’accessibilité automatisés vous permettent d’évaluer rapidement si votre produit numérique répond aux normes en matière d’accessibilité. Par exemple, un logiciel de test automatisé peut analyser un site Web et identifier toute une série d’obstacles à l’accessibilité, qu’il s’agisse de l’absence de texte alternatif ou d’un contraste de couleur insuffisant, en passant par l’absence de titres. L’automatisation du processus de test accroît l’efficacité, améliore la cohérence et permet une plus grande évolutivité.
Bien que les tests automatisés présentent de nombreux avantages, il est important de se rappeler qu’ils peuvent passer à côté de problèmes d’accessibilité importants ainsi que d’obstacles plus subtils qui nécessitent une compréhension et un contexte humains. Par exemple, un test automatisé ne signalera pas nécessairement les images de texte utilisées comme titres. Il ne peut pas non plus évaluer l’impact réel des obstacles à l’accessibilité sur les utilisateurs. Pour obtenir l’évaluation la plus complète possible de l’accessibilité, il faut toujours effectuer des tests d’accessibilité manuels en parallèle des tests automatisés.
Lors de l’automatisation de vos propres tests d’accessibilité, utilisez une combinaison d’utilitaires de test prédéfinis et de requêtes de test client pour détecter les régressions en matière d’accessibilité dans vos interfaces utilisateur. Les cadres de test mobiles pour iOS et Android incluent des vérifications d’accessibilité de base. Si vous développez des fonctionnalités à l’aide de code natif, ajoutez des tests pour effectuer des vérifications de base prises en charge par les cadres de test. Pour plus d’informations sur les tests mobiles, consultez la section Ressources à la fin de cette unité.
Utilisation d’outils de test d’accessibilité
Il existe un certain nombre d’outils automatisés et semi-automatisés que vous pouvez utiliser pour effectuer des tests d’accessibilité. La plupart d’entre eux évaluent le contenu par rapport aux Règles pour l’accessibilité des contenus Web (WCAG) et identifient les obstacles à l’accessibilité. Voici un descriptif de quelques outils utiles.
Outil |
Partie |
Fonction |
---|---|---|
Un outil de test open-source pour les sites Web et autres interfaces utilisateur s’appuyant sur le langage HTML, qui permet de tester l’accessibilité de manière exhaustive |
Il vous permet de détecter les erreurs d’accès lors du codage et s’intègre à votre environnement de test existant afin que vous puissiez automatiser les tests d’accessibilité |
|
Une suite gratuite d’outils d’évaluation qui vous aide à identifier les obstacles courants à l’accessibilité (tels qu’un faible contraste et l’absence de texte alternatif) qui ont une incidence sur les utilisateurs en situation de handicap |
Elle a recours à des icônes et des indicateurs pour mettre en évidence de nombreux problèmes d’accessibilité et facilite l’évaluation humaine du contenu Web |
|
Un outil automatisé open-source qui vérifie les problèmes d’accessibilité, y compris les violations des Règles pour l’accessibilité des contenus Web (WCAG) |
Il effectue des audits d’accessibilité et attribue une note sur 100, qui rend compte du niveau d’accessibilité d’une page |
|
Linters |
Des outils automatisés, tels que GitHub : infofarmer / eslint-plugin-jsx-a11y et GitHub : reactjs / react-a11y qui peuvent être intégrés d’emblée dans le cycle de vie du développement afin de prévenir les problèmes d’accessibilité et les violations |
Ils analysent le code source (HTML, CSS et JavaScript) pour détecter les obstacles à l’accessibilité, tels que les problèmes de navigation au clavier et l’utilisation incorrecte des titres et des repères |
Un ensemble de bibliothèques JavaScript open-source créées par Salesforce qui vous aide à rédiger des tests d’accessibilité automatisés |
Il vous permet de détecter les problèmes d’accessibilité du DOM statique pouvant être connus du système |
Il convient de noter que les tests effectués à l’aide de ces outils ne sont pas exhaustifs. Même si votre code réussit tous les tests, cela ne garantit pas que votre produit est entièrement accessible. Toutefois, ces tests font apparaître des problèmes d’accessibilité majeurs, et leur mise en place permet de faire en sorte que votre code ne soit pas rendu inaccessible par une régression Il est recommandé de toujours effectuer simultanément des tests manuels et des tests automatisés afin de garantir une évaluation complète de l’accessibilité. Vous en apprendrez davantage sur les tests manuels ultérieurement.
Création de vos propres tests d’accessibilité
Si vous avez passé des heures à rendre un composant accessible, il convient de vous assurer qu’il le reste. Vous pouvez écrire des tests automatisés relatifs à tout un éventail de problèmes d’accessibilité, se rapportant notamment à la fonctionnalité de saisie clavier attendue par les utilisateurs et à l’exactitude des valeurs ARIA pour les éléments HTML.
Exemple : test d’un bouton Lightning
Voici un pseudo-code pour un test Jest relatif aux composants Web Lightning (LWC) qui crée un bouton Lightning et valide l’accessibilité de la structure du composant.
registerSa11yMatcher(); const element = createButton({ label: 'Submit', variant: 'brand-outline', title: 'This is a submit button', }); const button = shadowQuerySelector(element, 'button'); return Promise.resolve().then(async () => { await expect(button).toBeAccessible(); });
Dans cet exemple de code, vous enregistrez d’abord sa11y pour qu’il puisse vérifier l’accessibilité des composants. Ensuite, vous créez le bouton avec une étiquette, une variante particulière et un titre. Après cela, vous trouvez ce bouton et l’affectez à une variable. Enfin, pour introduire des contrôles d’accessibilité, vous utilisez un appel de fonction asynchrone pour vérifier l’accessibilité du bouton.
Lorsque vous vérifiez l’accessibilité d’un élément dans Jest, faites en sorte de valider la structure HTML de l’élément vérifié par rapport aux normes WCAG. Cela implique notamment de s’assurer que tous les attributs aria sont corrects pour l’élément restitué.
Il s’agit là de quelques principes de base des tests d’accessibilité. Prêt à mettre ces principes en application ? Poursuivez votre lecture pour apprendre comment effectuer des tests relatifs aux claviers et aux lecteurs d’écran.
Ressources
- Site Web : Deque : Axe
- Site Web : WAVE : outils d’évaluation de l’accessibilité du Web
- Site Web : Documentation Google Chrome : présentation de Lighthouse
- Site Web : GitHub : infofarmer/eslint-plugin-jsx-a11y
- Site Web : GitHub : reactjs/react-a11y
- Site Web : GitHub : salesforce/sa11y
- Site Web : Documentation iOS : inspecteur d’accessibilité
- Site Web : Documentation Android : test de l’accessibilité de votre application
- Site Web : GitHub : google/Accessibility-Test-Framework-for-Android
- Site Web : npm : Pa11y
- Site Web : Squizlabs : HTML CodeSniffer