Tests d'accessibilité automatisés

Jusqu'à présent dans cette formation, vous avez découvert les aspects individuels, commerciaux et juridiques de l'accessibilité numérique, ainsi que les bases de la conformité en matière d'accessibilité numérique. Vous avez exploré des sujets spécifiques liés à la conception et au codage inclusifs, y compris quand utiliser ARIA par rapport à HTML, comment mesurer le contraste des couleurs, quand JavaScript est essentiel, entre autres.

Dans les modules restants, nous allons passer de la conception et de la création aux tests d'accessibilité. Nous allons vous présenter un processus de test en trois étapes qui inclut des outils et des techniques de test automatisés, manuels et de technologies d'assistance. Nous utiliserons la même démo tout au long de ces modules de test pour rendre la page Web accessible.

Chaque test (automatisé, manuel et de technologies d'assistance) est essentiel pour obtenir le produit le plus accessible possible. Nos tests reposent sur les niveaux de conformité A et AA des Règles pour l'accessibilité des contenus Web (WCAG) 2.1 comme normes.

N'oubliez pas que votre secteur d'activité, le type de produit, les lois et les règles locales et nationales, ou les objectifs d'accessibilité généraux déterminent les règles à suivre et les niveaux à atteindre. 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 mesurer l'accessibilité numérique ?" pour obtenir des informations générales sur les audits d'accessibilité, les types/niveaux de conformité, WCAG et POUR.

Comme vous le savez maintenant, la conformité en matière d'accessibilité ne suffit pas à prendre en charge les personnes handicapées. Cependant, il s'agit d'un bon point de départ, car elle fournit une métrique que vous pouvez tester. Nous vous encourageons à effectuer les actions suivantes en plus des tests de conformité pour vous aider à créer des produits plus inclusifs :

• Effectuez des tests d'utilisabilité auprès de personnes handicapées.
• Embauchez des personnes handicapées dans votre équipe.
• Consultez une personne ou une entreprise spécialisée dans l'accessibilité numérique.

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é par rapport à des normes de conformité prédéfinies.

Avantages des tests d'accessibilité automatisés :

• Répétez rapidement les tests à différentes étapes du cycle de vie du produit.
• Exécutez les tests en quelques étapes et obtenez des résultats très rapidement.
• Peu de connaissances en matière d'accessibilité sont nécessaires 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é dans votre produit.
• Faux positifs signalés (un problème est signalé, mais il ne s'agit pas d'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 constituent 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 vous expliquerons 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 d'accessibilité manuels.

Types d'outils automatisés

L'un des premiers outils de test d'accessibilité automatisé en ligne a été développé en 1996 par le Center for Applied Special Technology (CAST). Il s'appelait "The Bobby Report." Aujourd'hui, vous avez le choix entre plus de 100 outils de test automatisés à choisir parmi !

L'implémentation des outils automatisés varie, allant des extensions de navigateur d'accessibilité aux analyseurs de code, en passant par les applications de bureau et mobiles, les tableaux de bord en ligne et même les 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 quels niveaux de conformité effectuez-vous les tests ? Il peut s'agir des WCAG 2.2, des WCAG 2.1, de la section 508 de la loi américaine, ou d'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'une borne ou d'un autre produit.
• À quelle étape du cycle de vie du développement logiciel testez-vous votre produit ?
• Combien de temps faut-il pour configurer et utiliser l'outil ? Pour une personne, une équipe ou une entreprise ?
• Qui effectue le test : des concepteurs, des développeurs, des responsables de l'assurance qualité ou quelqu'un d'autre ?
• À quelle fréquence souhaitez-vous vérifier l'accessibilité ? 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 ?

De nombreux autres facteurs sont également à prendre en compte. Consultez l'article de la WAI sur "la sélection d'outils d'évaluation de l'accessibilité Web" pour en savoir plus sur la sélection de l'outil le plus adapté à vous et à votre équipe.

Démo : test automatisé

Pour la démo de test d'accessibilité automatisé, nous allons utiliser Lighthouse de Chrome. Lighthouse est un outil Open Source automatisé créé pour améliorer la qualité des pages Web grâce à différents types d'audits, tels que les performances, le référencement et l'accessibilité.

Notre démo est un site Web conçu pour une organisation fictive, le Medical Mysteries Club. Ce site est intentionnellement rendu inaccessible pour la démo. Vous pouvez constater une partie de cette inaccessibilité, et une partie (mais pas la totalité) sera détectée 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émo, nous utilisons l'extension Chrome.

Étape 2

Nous avons créé une démo dans CodePen. Affichez-la en mode débogage pour passer aux tests suivants. Cette étape est importante, car elle supprime l'élément <iframe> qui entoure la page Web de démonstration et qui peut interférer avec certains outils de test.

En savoir plus sur le mode débogage de CodePen.

Étape 3

Ouvrez les outils pour les développeurs Chrome et accédez à l'onglet Lighthouse. Effacez 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 Analyze page load (Analyser le chargement de la page) et laissez Lighthouse exécuter ses tests.

Une fois les tests terminés, Lighthouse affiche un score qui mesure 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 l'impact sur les utilisateurs des problèmes détectés.

Au-delà 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 façon de les résoudre. Le rapport inclut également les tests réussis ou non applicables, ainsi qu'une liste d'éléments supplémentaires à vérifier manuellement.

Étape 5

Examinez maintenant un exemple de chaque problème d'accessibilité automatisé découvert et corrigez les styles et le balisage pertinents.

Problème 1 : rôles ARIA

Le premier problème indique : "Les éléments ayant un ARIA [role] qui exigent que les enfants incluent un [role] spécifique ne possèdent pas certains ou l'ensemble des enfants requis. Certains rôles ARIA parents doivent contenir des rôles enfants spécifiques afin de remplir correctement leurs fonctions d'accessibilité." En savoir plus sur les règles des rôles ARIA.

Dans notre démo, le bouton d'abonnement à la newsletter échoue :

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

Résolvons ce problème.

Un rôle ARIA incorrect est appliqué au bouton "S'abonner" à 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é

"[aria-hidden="true"] éléments contiennent des descendants sélectionnables. La présence de descendants sélectionnables dans un élément [aria-hidden="true"] empêche les utilisateurs de technologies d'assistance, telles que des lecteurs d'écran, de se servir de 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>

Résolvons 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 au champ de formulaire et d'y saisir des informations.

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 annoncent simplement qu'il s'agit d'un "bouton", ce qui le rend inutilisable pour les personnes qui se servent de tels outils.

En savoir plus sur les règles de nommage des boutons.

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

Résolvons 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 de bouton accessible. Cette fonctionnalité est intégrée à l'élément de bouton HTML sémantique. 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 des images

Les éléments d'image ne comportent pas d'attributs [alt]. Les éléments informatifs doivent contenir un texte de substitution court et descriptif. L'attribut alt peut rester vide pour les éléments décoratifs. En savoir plus sur les règles de texte de substitution des images.

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

Résolvons ce problème.

Étant donné que l'image du logo est également un lien, vous savez grâce au module d'image qu'il s'agit d'une image cliquable et qu'elle nécessite des informations de texte de substitution 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 de technologies d'assistance 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 de lien

Les liens n'ont pas de nom visible. Rédigez du texte visible et unique pour les liens (et pour le texte de substitution des images, si vous vous en servez dans des liens), afin que les utilisateurs de lecteurs d'écran puissent facilement positionner le curseur dessus et bénéficient d'une meilleure expérience de navigation. En savoir plus sur les règles de texte de lien.

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

Résolvons ce problème.

Toutes les images cliquables de la page doivent inclure des informations sur la destination du lien. Pour résoudre ce problème, vous pouvez ajouter un texte de substitution à l'image concernant l'objectif, comme vous l'avez fait sur l'image du logo dans l'exemple. Cette méthode est idéale 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 modèle de description alternative ciblant les SVG, ajouter les informations entre les balises <a> et <svg>, puis les masquer visuellement aux utilisateurs, ajouter un ARIA compatible ou d'autres options. Selon votre environnement et les restrictions de code, une méthode peut être préférable à une autre.

Utilisez l'option de modèle la plus simple avec la couverture de technologie d'assistance la plus large, qui consiste à 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

Les couleurs d'arrière-plan et de premier plan ne sont pas suffisamment contrastées. Un texte faiblement contrasté est difficile, voire impossible à lire pour de nombreux utilisateurs. En savoir plus sur les règles de contraste des couleurs.

Deux exemples ont été signalés.

La valeur hexadécimale du texte du syndrome de la sirène est

Résolvons 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 sur les couleurs et le contraste, le texte de taille normale (moins de 18 pt / 24 px) doit présenter un rapport de 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 de 3:1.

Pour le titre de la page, le texte de couleur bleu-vert doit respecter l'exigence de rapport de contraste des couleurs de 3:1, car il s'agit d'un texte de grande taille de 24 px. Toutefois, les boutons bleu-vert sont considérés comme du texte de taille normale en gras de 16 px. Ils doivent donc respecter l'exigence de rapport de contraste des couleurs de 4.5:1.

Dans ce cas, nous pouvons trouver une couleur bleu-vert suffisamment foncée pour atteindre 4.5:1, ou augmenter la taille du texte du bouton à 18,5 px en gras et modifier légèrement la valeur de la couleur bleu-vert. Les deux méthodes sont conformes à l'esthétique de la conception.

Tout le texte gris sur l'arrière-plan blanc échoue également en termes de contraste des couleurs, à l'exception des deux titres les plus grands de la page. Ce texte doit être assombri pour respecter les exigences de rapport de contraste des couleurs de 4.5:1.

Problème 7 : structure de la liste

Les éléments de liste (<li>) ne sont pas contenus dans des éléments parents <ul> ou <ol>. Les lecteurs d'écran requièrent que les éléments de liste (<li>) soient contenus dans un élément parent <ul> ou <ol> pour les énoncer 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>

Résolvons ce problème.

Nous avons utilisé une classe CSS dans cette démo pour simuler la liste non ordonnée au lieu d' utiliser une balise <ul>. Lorsque nous avons mal écrit ce code, nous avons supprimé les fonctionnalités HTML sémantiques inhérentes intégrées à cette balise. En remplaçant la classe par une véritable <ul> balise et en modifiant le CSS associé, nous résolvons ce problème d'accessibilité.

<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 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 valide d'un point de vue technique, cela crée souvent une expérience frustrante pour les utilisateurs qui s'appuient sur des technologies d'assistance. En savoir plus sur les règles de tabindex.

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

Résolvons ce problème.

Sauf 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 sur un attribut tabindex. Pour conserver l'ordre de tabulation naturel, nous pouvons soit remplacer le tabindex par 0, soit supprimer complètement l'attribut.

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

Étape 6

Maintenant que vous avez corrigé tous les problèmes d'accessibilité automatisés, ouvrez une nouvelle page en mode débogage. Exécutez à nouveau l'audit d'accessibilité Lighthouse. Votre score devrait être bien meilleur qu'au premier essai.

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 nous n'avons pas encore terminé. Nous allons maintenant passer aux vérifications manuelles, comme indiqué dans le module sur les tests d'accessibilité manuels.