Tests de technologies d'assistance

Ce module se concentre sur l'utilisation des technologies d'assistance (AT) pour les tests d'accessibilité. Une personne handicapée peut utiliser la TA pour aider à augmenter, maintenir ou améliorer les capacités d'exécution d'une tâche.

Dans l'espace numérique, les AT peuvent être :

  • Non ou peu technique: bâtons pour la tête et la bouche, loupes portatives, appareils dotés de gros boutons
  • Haute technologie : appareils à commande vocale, dispositifs de suivi visuel, claviers et souris adaptatifs
  • Matériel : boutons de contacteur, claviers ergonomiques, dispositif braille à actualisation automatique
  • Logiciels: programmes de synthèse vocale, sous-titres instantanés, lecteurs d'écran

Nous vous encourageons à utiliser plusieurs types de TA dans votre flux de test global.

Principes de base des tests avec un lecteur d'écran

Dans ce module, nous nous concentrerons sur l'un des TA numériques les plus populaires : les lecteurs d'écran. Un lecteur d'écran est un logiciel qui lit le code sous-jacent d'un site Web ou d'une application. Il convertit ensuite ces informations en sortie vocale ou en braille pour l'utilisateur.

Les lecteurs d'écran sont essentiels pour les personnes aveugles et déficientes auditives, mais ils peuvent également être utiles aux personnes malvoyantes, aux personnes souffrant de troubles de la lecture et aux personnes ayant des troubles cognitifs.

Compatibilité du navigateur

Plusieurs options de lecteur d'écran sont disponibles. Les lecteurs d'écran les plus populaires sont JAWS, NVDA et VoiceOver pour les ordinateurs de bureau, et VoiceOver et TalkBack pour les appareils mobiles.

En fonction de votre système d'exploitation (OS), de votre navigateur préféré et de l'appareil que vous utilisez, un lecteur d'écran peut se démarquer comme la meilleure option. La plupart des lecteurs d'écran sont conçus pour des matériels et des navigateurs Web spécifiques. Lorsque vous utilisez un lecteur d'écran avec un navigateur pour lequel il n'a pas été calibré, vous pouvez rencontrer davantage de "bugs" ou de comportements inattendus. Les lecteurs d'écran fonctionnent mieux lorsqu'ils sont utilisés avec les combinaisons suivantes.

Lecteur d'écran OS Compatibilité du navigateur
Job Access With Speech (JAWS) Windows Chrome, Firefox, Edge
Non-Visual Desktop Access (NVDA) Windows Chrome et Firefox
Narrateur Windows Edge
VoiceOver macOS Safari
Orca Linux Firefox
TalkBack Android Chrome et Firefox
VoiceOver (pour mobile) iOS Safari
ChromeVox ChromeOS Chrome

Commandes du lecteur d'écran

Une fois que vous avez configuré correctement le logiciel de lecteur d'écran pour votre ordinateur de bureau ou votre appareil mobile, consultez la documentation du lecteur d'écran (dont le lien figure dans le tableau précédent) et exécutez certaines des commandes essentielles du lecteur d'écran pour vous familiariser avec la technologie. Si vous avez déjà utilisé un lecteur d'écran, essayez-en un nouveau.

Lorsque vous utilisez un lecteur d'écran pour effectuer des tests d'accessibilité, votre objectif est de détecter les problèmes de code qui interfèrent avec l'utilisation de votre site Web ou de votre application, et non d'émuler l'expérience d'un utilisateur de lecteur d'écran. Par conséquent, vous pouvez faire beaucoup de choses avec quelques connaissances de base, quelques commandes de lecteur d'écran et un peu (ou beaucoup) de pratique.

Si vous avez besoin de mieux comprendre l'expérience utilisateur des personnes qui utilisent des lecteurs d'écran et d'autres AT, vous pouvez échanger avec de nombreuses organisations et personnes pour obtenir ces informations précieuses. N'oubliez pas que l'utilisation d'un AT pour tester le code par rapport à un ensemble de règles et demander aux utilisateurs leur expérience donne souvent des résultats différents. Ces deux aspects sont importants pour créer des produits entièrement inclusifs.

Commandes principales pour les lecteurs d'écran pour ordinateur

Élément NVDA (Windows) VoiceOver (macOS)
Commandes générales Insertion Ctrl+Option
Arrêter la lecture de l'audio Contrôle Contrôle
Lire le suivant/précédent ou Ctrl+Option+ ou
Commencer la lecture Insérer Ctrl+Option+A
Liste des éléments/Rotor NVDA + F7 Ctrl+Option+U
Points de repère D Ctrl+Option+U
Headings C Ctrl+Option+Cmd+H
Liens K Ctrl+Option+Cmd+L
Commandes de formulaire V Ctrl+Option+Cmd+J
Tables T Ctrl+OptionCmd+T
Dans des tables InsertionAlt+ Ctrl+Option+

Commandes principales pour les lecteurs d'écran pour mobile

Élément TalkBack (Android) VoiceOver (iOS)
Explorer Faites glisser un doigt sur l'écran. Faites glisser un doigt sur l'écran.
Sélectionner ou activer Appuyer deux fois Appuyer deux fois
Déplacer vers le haut ou le bas Balayez l'écran vers le haut ou le bas avec deux doigts Balayez l'écran vers le haut ou vers le bas avec trois doigts
Changer de page Balayer l'écran vers la gauche ou la droite avec deux doigts Balayez l'écran vers la gauche ou droite avec trois doigts
Suivant/Précédent Balayez l'écran vers la gauche ou la droite avec un doigt Balayez l'écran vers la gauche ou la droite avec un doigt

Démonstration de test avec un lecteur d'écran

Pour tester notre démonstration, nous avons utilisé Safari sur un ordinateur portable exécutant macOS et capturé du son. Vous pouvez suivre ces étapes à l'aide de n'importe quel lecteur d'écran, mais la façon dont vous rencontrez certaines erreurs peut être différente de celle décrite dans ce module.

Étape 1

Accédez au CodePen mis à jour, qui applique toutes les mises à jour d'accessibilité automatisées et manuelles.

Affichez-le en mode débogage pour passer aux tests suivants. Cette étape est importante, car elle supprime le <iframe> qui entoure la page Web de démonstration, ce qui peut interférer avec certains outils de test. En savoir plus sur le mode débogage de CodePen

Étape 2

Activez le lecteur d'écran de votre choix et accédez à la page de démonstration. Vous pouvez parcourir l'intégralité de la page de haut en bas avant de vous concentrer sur des problèmes spécifiques.

Nous avons enregistré notre lecteur d'écran pour chaque problème, avant et après l'application des correctifs à la démonstration. Nous vous encourageons à suivre la démonstration avec votre propre lecteur d'écran.

Problème 1 : Structure du contenu

Les titres et les repères sont l'un des principaux moyens de navigation des utilisateurs avec les lecteurs d'écran. Si ces éléments ne sont pas présents, un utilisateur de lecteur d'écran doit lire la page entière pour comprendre le contexte. Cela peut prendre beaucoup de temps et être source de frustration.

Si vous essayez de parcourir l'un ou l'autre des éléments dans la démonstration, vous constaterez rapidement qu'ils n'existent pas.

  • Exemple de repère : <div class="main">...</div>
  • Exemple de titre: <p class="h1">Join the Club</p>

Si vous avez tout mis à jour correctement, aucun changement visuel ne devrait se produire, mais votre expérience avec le lecteur d'écran sera considérablement améliorée.

Écoutez le lecteur d'écran naviguer dans ce problème.
Résolvons le problème.

Certains éléments inaccessibles ne peuvent pas être observés simplement en regardant le site. Vous vous souvenez peut-être de l'importance des niveaux de titres et du code HTML sémantique du module Structure du contenu. Un élément de contenu peut ressembler à un titre, mais il est en fait encapsulé dans un <div> stylisé.

Pour résoudre le problème lié aux titres et aux repères, vous devez d'abord identifier chaque élément qui doit être marqué comme tel et mettre à jour le code HTML associé. Veillez également à mettre à jour le CSS associé.

  • Exemple de point de repère: <main>...</main>
  • Exemple de titre: <h1>Join the Club</h1>

Si vous avez tout mis à jour correctement, il ne devrait y avoir aucun changement visuel, mais l'expérience de lecteur d'écran sera considérablement améliorée.

Maintenant que nous avons corrigé la structure du contenu, écoutez le lecteur d'écran naviguer à nouveau dans la démonstration.

Il est important de fournir aux utilisateurs de lecteurs d'écran des informations sur l'objectif d'un lien et si le lien les redirige vers une nouvelle destination en dehors du site Web ou de l'application.

Dans notre démonstration, nous avons corrigé la plupart des liens lorsque nous avons mis à jour le texte alternatif de l'image active. Toutefois, quelques liens supplémentaires sur les différentes maladies rares pourraient bénéficier d'un contexte supplémentaire, en particulier s'ils redirigent vers un nouvel emplacement.

<a href="https://rarediseases.org/rare-diseases/maple-syrup-urine-disease">
  Maple syrup urine disease (MSUD)
</a>
Écoutez les explications du lecteur d'écran pour résoudre ce problème.
Résolvons le problème.

Afin de résoudre ce problème pour les utilisateurs de lecteurs d'écran, nous mettons à jour le code afin d'ajouter des informations, sans affecter l'élément visuel. Pour aider encore plus de personnes, comme celles qui souffrent de troubles de la lecture et cognitifs, nous pouvons choisir d'ajouter du texte visuel supplémentaire.

De nombreux modèles différents peuvent être envisagés pour ajouter des informations supplémentaires sur les liens. Étant donné que notre environnement ne prend en charge qu'une seule langue, un libellé ARIA est une option simple dans cette situation. Vous remarquerez peut-être que le libellé ARIA remplace le texte du lien d'origine. Veillez donc à inclure ces informations dans votre mise à jour.

<a href="https://rarediseases.org/rare-diseases/maple-syrup-urine-disease"
  aria-label="Learn more about Maple syrup urine disease on the Rare Diseases website.">
  Maple syrup urine disease (MSUD)
</a>
Maintenant que nous avons corrigé le contexte des liens, écoutez le lecteur d'écran parcourir à nouveau la démonstration.

Problème 3 : Image décorative

Dans notre module de test automatisé, Lighthouse n'a pas pu détecter le SVG intégré qui sert d'image de démarrage principale sur notre page de démonstration. Cependant, le lecteur d'écran la trouve et l'annonce "image" sans informations supplémentaires. Cela est vrai, même sans ajouter explicitement l'attribut role="img" au SVG.

<div class="section-right">
  <svg>...</svg>
</div>
Écoutez le lecteur d'écran parcourir ce problème.
Je vais vous aider à le résoudre.

Pour résoudre ce problème, nous devons d'abord déterminer si l'image est informative ou décorative. Sur la base de cette décision, nous devons ajouter le texte alternatif approprié (image informative) ou masquer l'image aux utilisateurs de lecteurs d'écran (image décorative).

Nous avons évalué les avantages et les inconvénients de la meilleure façon de catégoriser l'image et nous avons décidé qu'elle était décorative, ce qui signifie que nous voulons ajouter ou modifier le code pour masquer l'image. Une méthode rapide consiste à ajouter directement un role="presentation" à l'image SVG. Cela envoie un signal au lecteur d'écran pour qu'il ignore cette image et ne la liste pas dans le groupe d'images.

<div class="section-right">
  <svg role="presentation">...</svg>
</div>
Maintenant que nous avons corrigé l'image décorative, écoutez le lecteur d'écran naviguer dans la démonstration.

Problème 4: Décoration de balle

Vous avez peut-être remarqué que le lecteur d'écran lit l'image de puce CSS sous les sections sur les maladies rares. Bien qu'il ne s'agisse pas du type d'image traditionnel que nous avons abordé dans le module Images, l'image doit tout de même être modifiée, car elle perturbe le flux du contenu et peut distraire ou perturber un utilisateur de lecteur d'écran.

<p class="bullet">...</p>
Écoutez le lecteur d'écran parcourir ce problème.
Résolvons le problème.

Tout comme pour l'exemple d'image décorative abordé précédemment, vous pouvez ajouter un role="presentation" au code HTML avec la classe de puce pour le masquer au lecteur d'écran. De même, un role="none" fonctionnerait. Veillez simplement à ne pas utiliser aria-hidden: true, sinon vous masquerez toutes les informations du paragraphe aux utilisateurs de lecteurs d'écran.

<p class="bullet" role="none">...</p>

Problème 5: champ de formulaire

Dans le module Formulaires, nous avons appris que tous les champs de formulaire doivent également comporter un libellé visuel et programmatique. Ce libellé doit rester visible en permanence.

Dans notre démonstration, il manque un libellé visuel et programmatique dans le champ d'adresse e-mail pour l'inscription à la newsletter. Il existe un élément d'espace réservé au texte, mais celui-ci ne remplace pas le libellé, car il n'est pas visuellement persistant et n'est pas entièrement compatible avec tous les lecteurs d'écran.

<form>
  <div class="form-group">
    <input type="email" placeholder="Enter your e-mail address" required>
    <button type="submit">Subscribe</button>
  </div>
</form>
Écoutez les explications du lecteur d'écran pour résoudre ce problème.
Résolvons le problème.

Pour résoudre ce problème, remplacez l'espace réservé de texte par un élément de libellé semblable. Cet élément de libellé est connecté de manière programmatique au champ de formulaire et le mouvement a été ajouté avec JavaScript pour que le libellé reste visible même lorsque du contenu est ajouté au champ.

<form>
  <div class="form-group">
    <input type="email" required id="youremail" name="youremail" type="text">
    <label for="youremail">Enter your e-mail address</label>
    <button type="submit" aria-label="Subscribe to our newsletter">Subscribe</button>
  </div>
</form>
Maintenant que nous avons corrigé le formulaire, écoutez le lecteur d'écran parcourir la démonstration.

Conclusion

Félicitations ! Vous avez terminé tous les tests de cette démonstration. Vous pouvez consulter toutes ces modifications dans le Codepen mis à jour pour cette démonstration.

Vous pouvez maintenant utiliser ce que vous avez appris pour examiner l'accessibilité de vos propres sites Web et applications.

L'objectif de tous ces tests d'accessibilité est de résoudre autant de problèmes qu'un utilisateur peut potentiellement rencontrer. Toutefois, cela ne signifie pas que votre site Web ou votre application sont parfaitement accessibles une fois que vous avez terminé. Vous obtiendrez les meilleurs résultats en concevant un site Web ou une application accessible tout au long du processus, et en intégrant ces tests à vos autres tests pré-lancement.

Vérifier vos connaissances

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

Quel est le meilleur lecteur d'écran à utiliser pour tester l'accessibilité ?

JAWS
Bien que JAWS soit l'un des lecteurs d'écran les plus populaires, ce n'est pas nécessairement le meilleur choix.
VoiceOver
VoiceOver est un outil destiné aux utilisateurs de macOS et d'iOS. Si vous utilisez un PC Windows, vous devrez utiliser un autre outil.
Orca
Orca est destiné aux utilisateurs de Firefox sur Linux. Vous devrez peut-être utiliser un autre outil.
Il n'y en a pas
Chaque lecteur d'écran est conçu pour un appareil, un système d'exploitation ou un navigateur spécifique. Le lecteur qui vous convient le mieux dépend donc de la façon dont vous effectuez les tests. Si vous disposez de données analytiques ou de recherches qui vous en disent plus sur les utilisateurs de lecteurs d'écran, il peut être judicieux d'effectuer les tests avec les mêmes lecteurs d'écran.

Quel est l'objectif des tests avec une technologie d'assistance ?

Pour avoir la même expérience que les personnes qui utilisent des technologies d'assistance.
Vous ne pouvez pas vraiment émuler l'expérience d'une personne qui utilise des AT. Un test dans une situation donnée ne sera pas le même que les autres expériences.
Pour détecter les failles de votre site Web ou de votre application.
Les tests d'accessibilité aident les développeurs à identifier et à résoudre les problèmes que les utilisateurs d'AT peuvent rencontrer sur leur site Web ou dans leur application.