Tests d'accessibilité automatisés

Jusqu'à présent, dans ce cours, vous avez découvert les individus, les entreprises et aspects juridiques de l'accessibilité numérique et bases de l'accessibilité numérique la conformité. Vous avez exploré des sujets spécifiques liés à la conception inclusive et codage, y compris quand utiliser ARIA par rapport à HTML, comment mesurer le contraste des couleurs, lorsque JavaScript est essentiel, entre autres.

Dans les modules restants, nous passons de la conception et de la création à la vérification de l'accessibilité. Nous utiliserons un processus de test en trois étapes qui comprend des outils et des techniques de test automatisés, manuels et pour les technologies d'assistance. Nous utilisez la même démo tout au long de ces modules de test pour faire passer la page Web du inaccessibles en accessibles.

Chaque test (automatisé, manuel et technique d'assistance) est essentiel pour atteindre 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. N'oubliez pas que votre secteur, le type de produit, les lois et les règles locales et nationales, ou les objectifs d'accessibilité globaux déterminent les consignes à 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 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é, WCAG et POUR.

Comme vous le savez maintenant, la conformité aux normes d'accessibilité ne n'est pas tout ce qu'il faut savoir pour aider les personnes ayant un handicap. Mais c'est un bon point de départ car il fournit une métrique par rapport à laquelle vous pouvez effectuer des tests. Nous vous encourageons à suivre des actions supplémentaires en dehors des tests de conformité à l'accessibilité, telles que l’exécution de tests d’utilisabilité auprès de personnes handicapées, l'embauche de personnes ayant handicapés de travailler dans votre équipe, ou de consulter une personne ou une entreprise avec 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 d'identifier les problèmes d'accessibilité par rapport aux normes de conformité à l'accessibilité prédéfinies.

Avantages des tests d'accessibilité automatisés:

• Il est facile de répéter les tests à différentes étapes du cycle de vie du produit.
• Il ne vous reste plus que quelques étapes à effectuer et vous 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é de votre produit.
• Faux positifs signalés (un problème est signalé alors qu'il ne s'agit pas d'une véritable non-conformité aux WCAG)
• Plusieurs outils peuvent être nécessaires pour différents types de produits et rôles

Les tests automatisés sont un excellent premier pas 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 y reviendrons plus en détail sur la façon de vérifier l'accessibilité des éléments qui ne peuvent pas être automatisés dans le de tests manuels d'accessibilité.

Types d'outils automatisés

L'un des premiers outils automatisés de test d'accessibilité en ligne a été développé en 1996 par le Center for Applied Special Technology (CAST), appelé "The Bobby Report" Aujourd'hui, il existe plus de 100 outils de test automatisés parmi lesquels choisir.

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

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

• Sur quels niveaux et normes de conformité effectuez-vous le test ? Cela peut WCAG 2.1, WCAG 2.0, États-Unis, Section 508, 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 mobile native, PDF, kiosque ou autre.
• Quelle partie 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 mène le test: les concepteurs, les développeurs, le contrôle qualité ou quelqu'un d'autre ?
• À quelle fréquence souhaitez-vous que l'accessibilité soit vérifiée ? Quels détails devraient être incluses dans le rapport ? Les problèmes doivent-ils être directement associés à un système de gestion des tickets ?
• Quels outils fonctionnent le mieux dans votre environnement ? Pour votre équipe ?

Vous devez également prendre en compte de nombreux autres facteurs. Consultez l'article sur WAI Sélectionner les outils d'évaluation de l'accessibilité Web .

Démonstration : test automatisé

Pour la démonstration des tests d'accessibilité automatisés, nous utiliserons Phare : Lighthouse est un outil automatisé Open Source conçu pour améliorer la qualité pages Web selon différents types d'audits : performances, SEO l'accessibilité.

Notre démonstration est un site Web créé pour une organisation fictive, le Medical Mysteries Club. Ce site est intentionnellement rendu inaccessible pour la démonstration. Quelques exemples vous risquez de les rendre inaccessibles, et certains contenus (mais pas tous) seront interceptés notre test automatisé.

Étape 1

Depuis le navigateur Chrome, installez le Extension Lighthouse

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

Étape 2

Nous avons créé une démonstration dans CodePen. Affichez-le en mode débogage pour continuer les prochains tests. C'est important, car cela supprime le <iframe> qui entoure page Web de démonstration, qui peut interférer avec certains outils de test.

En savoir plus sur Mode débogage de CodePen

Étape 3

Ouvrez les outils pour les développeurs Chrome. 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 que vous utilisez sur lesquels exécuter les tests.

Étape 4

Cliquez sur 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 des problèmes détectés 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 leur résolution. 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

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

Problème 1 : Rôles ARIA

Le premier problème indique : "Éléments dotés d'un [rôle] ARIA qui exigent que les enfants contiennent un [role] spécifique n’ont pas une partie ou la totalité des enfants requis. Certains rôles ARIA parents doivent contenir des rôles enfants spécifiques pour effectuer leurs les 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>

Voyons comment résoudre ce problème.

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

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

Problème 2: ARIA masqué

Les éléments "[aria-hidden="true"] 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>

Voyons comment 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, supprimez cet attribut de l'entrée pour autoriser les utilisateurs utilisant une technologie d'assistance pour accéder aux informations et 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 comme un « bouton », le rendant inutilisable pour les utilisateurs qui s'appuient sur des lecteurs d'écran.

En savoir plus sur les règles concernant les noms de boutons

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

Voyons comment résoudre ce problème.

Si vous supprimez le rôle ARIA inexact de l'élément de bouton dans numéro 1, le mot "S'abonner" devient le bouton accessible son nom. Cette fonctionnalité est intégrée à l'élément de bouton HTML sémantique. D'autres options de modèle sont à envisager pour des situations plus complexes.

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

Problème 4 : Attributs alt des images

Les attributs [alt] sont manquants pour les éléments d'image. Les éléments informatifs doivent viser pour obtenir un texte alternatif et descriptif. L'attribut alt peut rester vide pour les éléments décoratifs. En savoir plus sur les règles concernant le texte alternatif des images

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

Voyons comment résoudre ce problème.

Comme l'image du logo est aussi un lien, vous savez module d'image qu'il s'agit d'un module image et nécessite d'autres informations textuelles concernant l'objet de l'image. Normalement, la première image de la page est un logo. Vous pouvez donc raisonnablement supposer que vos utilisateurs d'AT le sachent, et vous pouvez décider de ne pas ajouter ces informations contextuelles supplémentaires à la description de l'image.

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

Problème 5: le texte d'un 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 concernant les textes de liens

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

Voyons comment résoudre ce problème.

Toutes les images interactives de la page doivent inclure des informations sur la destination du lien. Pour résoudre ce problème, vous pouvez ajouter un texte alternatif à l'image sur l'objectif, comme vous l'avez fait pour l'image du logo dans l'exemple. Cette méthode fonctionne parfaitement pour une image utilisant une balise <img>, mais les balises <svg> ne peuvent pas utiliser cette méthode.

Pour les icônes de réseaux sociaux qui utilisent des balises <svg>, vous pouvez utiliser un un autre format de description ciblant les SVG, ajoutez les informations entre les balises <a> et <svg>, puis le masquer visuellement pour les utilisateurs, ajouter un ARIA compatible ou d'autres options. En fonction sur vos restrictions d'environnement et de code, une méthode peut être préférable une autre.

Utiliser l'option de modèle la plus simple avec la plus assistée la couverture technologique, qui consiste à ajouter une role="img" à la balise <svg> et incluant 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 d'arrière-plan et de premier plan n'est pas suffisant. Un texte à faible contraste est difficile, voire impossible à lire pour de nombreux utilisateurs. En savoir plus sur les règles de contraste des couleurs

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

</ph>

</ph> Résolvons à présent le problème.

De nombreux problèmes de contraste de 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 pixels) doit présenter un contraste des couleurs de 4,5:1, tandis que le texte est de grande taille (au moins 18 pt / 24 px ou 14 pt / 18,5 px en gras) et les icônes essentielles doivent respecter le format 3:1.

Pour le titre de la page, le texte turquoise doit correspondre au contraste des couleurs 3:1. car il s'agit d'un texte grand format (24 pixels). Cependant, les boutons bleu-vert sont est considéré comme du texte de taille standard (16 pixels en gras) et doit donc respecter la couleur 4.5:1. l'exigence de contraste.

Dans ce cas, nous avons pu trouver une couleur turquoise suffisamment sombre pour atteindre 4,5:1, ou nous pourrions augmenter la taille du texte du bouton à 18,5 pixels en gras et modifier la couleur bleu canard. L'une ou l'autre méthode reste conforme à la conception esthétiques.

Tout le texte en gris sur l'arrière-plan blanc ne fonctionne pas non plus pour le contraste des couleurs, sauf pour les deux plus grands titres de la page. Assombrissez ce texte pour respecter les exigences de contraste des couleurs 4,5:1.

Problème 7 : structure de la liste

Les éléments de liste (<li>) ne sont pas inclus dans des éléments parents <ul> ni <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 à présent le problème.

Dans cette démonstration, nous avons utilisé une classe CSS pour simuler une liste non triée au lieu de à l'aide d'une balise <ul>. Lorsque nous avons mal écrit ce code, nous avons supprimé les caractéristiques HTML sémantiques intégrées à cette balise. En remplaçant la classe par une vraie <ul> et en modifiant le code 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 techniquement valable, crée 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 tabulation

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

Résolvons à présent le problème.

Sauf si vous avez une raison spécifique de perturber l'ordre naturel de tabulation sur une page Web, vous n'avez pas besoin d'utiliser un entier positif pour un attribut tabindex. À conserver l'ordre de tabulation naturel, nous pouvons soit changer l'index de tabulation en 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 nettement mieux que lors de la première exécution.

Nous avons appliqué toutes ces mises à jour d'accessibilité automatiques CodePen :

Étape suivante

Bien joué ! Vous avez déjà accompli beaucoup de choses, mais nous ne sommes pas encore au bout ! Nous allons ensuite passer aux vérifications manuelles, comme détaillé dans le module sur les tests d'accessibilité manuels.

Vérifier vos connaissances

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