Tests d'accessibilité automatisés

Jusqu'à présent, vous avez découvert les aspects individuels, commerciaux et juridiques de l'accessibilité numérique, ainsi que les principes de base de la conformité de l'accessibilité numérique. Vous avez exploré des sujets spécifiques liés à la conception inclusive et au codage, y compris quand utiliser ARIA par rapport au HTML, comment mesurer le contraste des couleurs et quand JavaScript est essentiel.

Dans les autres modules, nous passerons de la conception et de la compilation aux tests d'accessibilité. Nous allons utiliser un processus de test en trois étapes qui comprend des outils et des techniques de test des technologies automatisées, manuelles et d'assistance. Nous utiliserons la même démonstration dans ces modules de test pour faire passer la page Web d'inaccessible à accessible.

Chaque test (automatisé, manuel et d'assistance) est essentiel pour obtenir le produit le plus accessible possible.

Nos tests s'appuient sur les niveaux de conformité A et AA des consignes pour l'accessibilité des contenus Web (WCAG) 2.1. N'oubliez pas que votre secteur, votre type de produit, les lois et règles locales/pays ou vos objectifs globaux d'accessibilité déterminent les consignes à suivre et les niveaux à respecter. Si vous n'avez pas besoin d'une norme spécifique pour votre projet, nous vous recommandons de suivre la dernière version des WCAG. Reportez-vous à la section Comment l'accessibilité numérique est-elle mesurée ? pour obtenir des informations générales sur les audits d'accessibilité, les types/niveaux de conformité, les WCAG et la POUR.

Comme vous le savez maintenant, la conformité avec l'accessibilité n'est pas à la base de l'aide aux personnes handicapées. Cependant, il s'agit d'un bon point de départ, car il fournit une métrique par rapport à laquelle vous pouvez tester. Nous vous encourageons à prendre des mesures supplémentaires en dehors des tests de conformité de l'accessibilité, comme exécuter des tests d'utilisabilité auprès de personnes handicapées, embaucher des personnes ayant un handicap pour travailler dans votre équipe, ou consulter une personne ou une entreprise disposant d'une expertise en accessibilité numérique pour vous aider à créer des produits plus inclusifs.

Principes de base des tests automatisés

Les tests d'accessibilité automatisés utilisent un logiciel pour analyser votre produit numérique afin de détecter les problèmes d'accessibilité en fonction des normes prédéfinies de conformité de l'accessibilité.

Avantages des tests d'accessibilité automatisés:

• Tests faciles à répéter à différentes étapes du cycle de vie du produit
• Quelques étapes seulement et des résultats très rapides
• Peu de connaissances en accessibilité sont requises pour exécuter les tests ou comprendre les résultats

Inconvénients des tests d'accessibilité automatisés:

• Les outils automatisés ne détectent pas toutes les erreurs d'accessibilité de votre produit
• Faux positifs signalés (un problème signalé ne constitue pas une véritable infraction aux WCAG)
• Plusieurs outils peuvent être nécessaires pour différents types de produits et rôles.

Les tests automatisés sont une excellente première étape pour vérifier l'accessibilité de votre site Web ou de votre application, mais toutes les vérifications ne peuvent pas être automatisées. Nous verrons plus en détail comment vérifier l'accessibilité des éléments qui ne peuvent pas être automatisés dans le module sur les tests manuels d'accessibilité.

Types d'outils automatisés

L'un des premiers outils en ligne de tests d'accessibilité automatisés a été développé en 1996 par le Center for Applied Special Technology (CAST), appelé The Bobby Report (Rapport Bobby). Il existe aujourd'hui plus de 100 outils de test automatisés.

L'implémentation automatisée des outils varie : extensions de navigateur d'accessibilité, outils de linting de code, applications de bureau et mobiles, tableaux de bord en ligne et même API Open Source que vous pouvez utiliser pour créer vos propres outils automatisés.

L'outil automatisé que vous décidez d'utiliser peut dépendre de nombreux facteurs, y compris:

• Par rapport à quelles normes et niveaux de conformité testez-vous ? Cela peut inclure les WCAG 2.1 et WCAG 2.0, la Section 508 aux États-Unis ou une liste modifiée de règles d'accessibilité.
• Quel type de produit numérique testez-vous ? Il peut s'agir d'un site Web, d'une application Web, d'une application mobile native, d'un PDF, d'un kiosque ou d'un autre produit.
• Quelle partie du cycle de développement du logiciel testez-vous votre produit ?
• Combien de temps faut-il pour configurer et utiliser l'outil ? Pour un individu, une équipe ou une entreprise ?
• Qui mène le test: concepteurs, développeurs, QA, etc.?
• À quelle fréquence souhaitez-vous que l'accessibilité soit vérifiée ? Quels détails doivent être inclus dans le rapport ? Les problèmes doivent-ils être directement liés à un système de tickets ?
• Quels outils fonctionnent le mieux dans votre environnement ? Pour votre équipe ?

Il y a également de nombreux autres facteurs à prendre en compte. Consultez l'article de WAI intitulé Selecting Web Accessibility Evaluation Tools (Sélectionner les outils d'évaluation de l'accessibilité sur le Web) pour savoir comment choisir l'outil le plus adapté à votre équipe.

Démonstration: test automatisé

Pour la démonstration des tests d'accessibilité automatisés, nous utiliserons l'outil Lighthouse de Chrome. Lighthouse est un outil automatisé Open Source créé pour améliorer la qualité des pages Web grâce à différents types d'audits, tels que les performances, le SEO et l'accessibilité.

Notre démonstration est un site Web conçu pour une organisation fictive, le Medical Mysteries Club. Ce site a été volontairement rendu inaccessible pour la démonstration. Certaines de ces inaccessibilités peuvent être visibles par vous, et certaines seront détectées (mais pas toutes) lors de notre test automatisé.

Étape 1

Dans votre navigateur Chrome, installez l'extension Lighthouse.

Il existe de nombreuses façons d'intégrer Lighthouse à votre workflow de test. Pour cette démonstration, nous allons utiliser l'extension Chrome.

Étape 2

Nous avons créé une démonstration dans CodePen. Affichez-le en mode débogage pour passer aux tests suivants. Ce point est important, car il supprime la <iframe> qui entoure la page Web de démonstration, ce qui peut interférer avec certains outils de test. Apprenez-en plus sur le mode débogage de CodePen.

Étape 3

Ouvrez les Outils pour les développeurs Chrome, puis accédez à l'onglet Lighthouse. Décochez toutes les options de catégorie, à l'exception de "Accessibilité". Conservez le mode par défaut et choisissez le type d'appareil sur lequel vous exécutez les tests.

Étape 4

Cliquez sur le bouton "Analyser le chargement de la page" et laissez à Lighthouse le temps d'exécuter ses tests.

Une fois les tests terminés, Lighthouse affiche un score indiquant l'accessibilité du produit que vous testez. Le score Lighthouse est calculé en fonction du nombre de problèmes, des types de problèmes et de leur impact sur les utilisateurs.

En plus d'un score, le rapport Lighthouse inclut des informations détaillées sur les problèmes détectés et des liens vers des ressources pour en savoir plus sur la résolution de ces problèmes. Il inclut également les tests réussis ou non applicables, ainsi qu'une liste d'éléments supplémentaires à vérifier manuellement.

Étape 5

Examinons maintenant un exemple de chaque problème d'accessibilité automatisé détecté, et corrigeons les styles et le balisage pertinents.

Problème 1: rôles ARIA

Le premier problème indique que les éléments dotés d'un [rôle] ARIA qui nécessitent que les enfants contiennent un [rôle] spécifique ne comportent pas certains ou tous les enfants requis. Certains rôles parents ARIA doivent contenir des rôles enfants spécifiques pour exécuter leurs fonctions d'accessibilité prévues. En savoir plus sur les règles de rôle ARIA

Dans notre démonstration, le bouton d'abonnement à la newsletter ne fonctionne pas:

<button role="list" type="submit" tabindex="1">Subscribe</button>

Nous allons résoudre ce problème.

Un rôle ARIA incorrect est appliqué au bouton "S'abonner" situé à côté du champ de saisie. Dans ce cas, le rôle peut être complètement supprimé.

<button type="submit" tabindex="1">Subscribe</button>

Problème 2: ARIA masquée

Les éléments "[aria-hidden="true"] contiennent des descendants sélectionnables. Les descendants sélectionnables dans un élément [aria-hidden="true"] empêchent les utilisateurs de technologies d'assistance telles que les lecteurs d'écran d'accéder à ces éléments interactifs. En savoir plus sur les règles aria-hidden

<input type="email" placeholder="Enter your e-mail address" aria-hidden="true" tabindex="-1" required>

Nous allons résoudre ce problème.

Un attribut aria-hidden="true" a été appliqué au champ de saisie. L'ajout de cet attribut masque l'élément (et tout ce qui est imbriqué en dessous) des technologies d'assistance.

<input type="email" placeholder="Enter your e-mail address" tabindex="-1" required>

Dans ce cas, vous devez supprimer cet attribut de l'entrée pour permettre aux personnes utilisant une technologie d'assistance d'accéder aux informations et de les saisir dans le champ du formulaire.

Problème 3: nom du bouton

Les boutons n'ont pas de nom accessible. Lorsqu'un bouton n'a pas de nom accessible, les lecteurs d'écran l'annoncent en tant que "bouton", ce qui le rend inutilisable pour les utilisateurs qui se servent de tels lecteurs. En savoir plus sur les règles concernant les noms de boutons

<button role="list" type="submit" tabindex="1">Subscribe</button>

Nous allons résoudre ce problème.

Lorsque vous supprimez le rôle ARIA inexact de l'élément de bouton dans le problème 1, le mot "S'abonner" devient le nom du bouton accessible. Cette fonctionnalité est intégrée à l'élément sémantique du bouton HTML. D'autres options de modèle sont à prendre en compte pour les situations plus complexes.

<button type="submit" tabindex="1">Subscribe</button>

Problème 4: attributs alt d'image

Il manque des attributs [alt] dans les éléments d'image. Les éléments informatifs doivent contenir un texte de substitution court et descriptif. Les éléments décoratifs peuvent être ignorés avec un attribut alt vide. En savoir plus sur les règles de texte alternatif pour les images

<a href="index.html">
  <img src="https://upload.wikimedia.org/wikipedia/commons/….png">
</a>

Nous allons résoudre ce problème.

Étant donné que l'image du logo est également un lien, vous savez d'après le module image qu'elle s'appelle une image exploitables et qu'elle nécessite un texte alternatif sur l'objectif de l'image. Normalement, la première image de la page est un logo. Vous pouvez donc raisonnablement supposer que vos utilisateurs TA le savent et vous pouvez décider de ne pas ajouter ces informations contextuelles supplémentaires à la description de votre image.

<a href="index.html">
  <img src="https://upload.wikimedia.org/wikipedia/commons/….png"
    alt="Go to the home page.">
</a>

Problème 5: texte des liens

Les liens n'ont pas de nom visible. Un texte de lien (et un texte alternatif pour les images, s'il est utilisé sous forme de lien) qui est visible, unique et sélectionnable améliore l'expérience de navigation pour les utilisateurs de lecteurs d'écran. En savoir plus sur les règles relatives au texte des liens

<a href="#!"><svg><path>...</path></svg></a>

Nous allons résoudre ce problème.

Toutes les images exploitables sur la page doivent inclure des informations sur la destination du lien. Une méthode pour résoudre ce problème consiste à ajouter un texte alternatif à l'image à propos de l'objectif, comme vous l'avez fait pour l'image du logo dans l'exemple ci-dessus. Cela fonctionne très bien pour une image utilisant une balise <img>, mais les balises <svg> ne peuvent pas l'utiliser.

Pour les icônes de réseaux sociaux qui utilisent des balises <svg>, vous pouvez utiliser un autre format de description ciblant les SVG, ajouter les informations entre les balises <a> et <svg>, puis les masquer visuellement pour les utilisateurs, ajouter une ARIA compatible ou d'autres options. Selon votre environnement et les restrictions liées à votre code, une méthode peut être préférable à une autre. Utilisons l'option de modèle la plus simple avec la couverture la plus complète des technologies d'assistance, à savoir ajouter un role="img" à la balise <svg> et inclure un élément <title>.

<a href="#!">
  <svg role="img">
    <title>Connect on our Twitter page.</title>
    <path>...</path>
  </svg>
</a>

Problème 6: contraste des couleurs

Le rapport de contraste des couleurs de l'arrière-plan et du premier plan n'est pas suffisant. Un texte à faible contraste est difficile, voire impossible, pour de nombreux utilisateurs. En savoir plus sur les règles de contraste des couleurs

Deux exemples ont été présentés.

Nous allons corriger ce problème.

De nombreux problèmes de contraste des couleurs ont été détectés sur la page Web. Comme vous l'avez appris dans le module Couleur et contraste, le texte de taille standard (moins de 18 pt / 24 px) doit exiger un contraste des couleurs de 4,5:1, tandis que le texte de grande taille (au moins 18 pt / 24 px ou 14 pt / 18,5 px en gras) et les icônes essentielles doivent respecter l'exigence 3:1.

Pour le titre de la page, le texte turquoise doit respecter les exigences de contraste des couleurs de 3:1, car il s'agit d'un texte de grande taille avec 24 pixels. Toutefois, les boutons bleu-vert sont considérés comme du texte de taille standard avec 16 pixels de gras.Ils doivent donc respecter l'exigence de contraste des couleurs de 4, 5:1.

Dans ce cas, nous pourrions trouver une couleur turquoise suffisamment foncée pour correspondre à 4,5:1, ou augmenter la taille du texte du bouton à 18,5 pixels en gras et modifier légèrement la valeur de la couleur turquoise. Chacune de ces deux méthodes est conforme aux esthétiques de la conception.

Tout le texte gris sur fond blanc échoue également pour le contraste des couleurs, à l'exception des deux plus grands titres de la page. Ce texte doit être assombré pour respecter les exigences de contraste des couleurs de 4,5:1.

Problème n° 7 : structure de liste

Les éléments de liste (<li>) ne sont pas inclus dans des éléments parents <ul> ou <ol>. Les lecteurs d'écran nécessitent que les éléments de liste (<li>) soient contenus dans un élément parent <ul> ou <ol> pour être annoncé correctement.

En savoir plus sur les règles de liste

<div class="ul">
  <li><a href="#">About</a></li>
  <li><a href="#">Community</a></li>
  <li><a href="#">Donate</a></li>
  <li><a href="#">Q&A</a></li>
  <li><a href="#">Subscribe</a></li>
</div>

Nous allons résoudre ce problème.

Dans cette démonstration, nous avons utilisé une classe CSS pour simuler la liste à puces au lieu d'utiliser une balise <ul>. Lorsque nous avons écrit ce code de manière incorrecte, nous avons supprimé les fonctionnalités HTML sémantiques inhérentes à cette balise. Nous résolvons ce problème d'accessibilité en remplaçant la classe par une véritable balise <ul> et en modifiant le CSS associé.

<ul>
  <li><a href="#">About</a></li>
  <li><a href="#">Community</a></li>
  <li><a href="#">Donate</a></li>
  <li><a href="#">Q&A</a></li>
  <li><a href="#">Subscribe</a></li>
</ul>

Problème n° 8 : tabindex

Certains éléments ont une valeur [tabindex] supérieure à 0. Une valeur supérieure à 0 implique un ordre de navigation explicite. Bien que cela soit techniquement valide, cela crée souvent des expériences frustrantes pour les utilisateurs qui s'appuient sur des technologies d'assistance. En savoir plus sur les règles d'index de la touche de tabulation

<button type="submit" tabindex="1">Subscribe</button>

Nous allons résoudre ce problème.

À moins qu'il n'y ait une raison spécifique de perturber l'ordre de tabulation naturel sur une page Web, il n'est pas nécessaire d'avoir un entier positif dans un attribut tabindex. Pour conserver l'ordre de tabulation naturel, nous pouvons soit définir l'index de tabulation sur 0, soit supprimer complètement l'attribut.

<button type="submit">Subscribe</button>

Étape 6

Maintenant que vous avez résolu tous les problèmes d'accessibilité automatisés, ouvrez une nouvelle page du mode débogage. Exécutez à nouveau l'audit d'accessibilité Lighthouse. Votre score devrait être nettement supérieur à celui de la première course.

Nous avons appliqué toutes ces mises à jour d'accessibilité automatisées à un nouveau CodePen.

Étape suivante

Bon travail ! Vous avez déjà accompli beaucoup de choses, mais ce n'est pas encore fini ! Nous allons ensuite passer aux vérifications manuelles, comme indiqué dans le module sur les tests manuels d'accessibilité.

Testez vos connaissances

Tester vos connaissances sur les tests d'accessibilité automatisés