Tests de technologies d'assistance

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

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

  • Aucune technologie/technologie faible: sticks pour la tête/bouche, loupes portatives, appareils dotés de gros boutons
  • Haute technologie: appareils à commande vocale, outils de suivi oculaire, claviers/souris adaptatifs
  • Matériel: boutons de commutation, claviers ergonomiques, plage 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 des lecteurs d'écran

Dans ce module, nous nous concentrerons sur l'un des lecteurs d'écran numériques les plus populaires. Un lecteur d'écran est un logiciel qui lit le code sous-jacent d'un site Web ou d'une application, puis convertit ces informations en contenus vocaux ou en braille.

Les lecteurs d'écran sont essentiels pour les personnes non-voyantes et sourdes aveugles, mais ils peuvent également être bénéfiques pour les personnes malvoyantes, souffrant de troubles de la lecture ou de troubles cognitifs.

Compatibilité du navigateur

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

En fonction de votre système d'exploitation (OS), de votre navigateur favori et de l'appareil que vous utilisez, un seul lecteur d'écran peut se démarquer comme la meilleure option. La plupart des lecteurs d'écran sont conçus pour un matériel et des navigateurs Web spécifiques. Lorsque vous utilisez un lecteur d'écran avec un navigateur pour lequel il n'a pas été calibré, il est possible que vous rencontriez 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
JAWS (Job Access With Speech) Windows Chrome, Firefox, Edge
NVDA (Non-Visual Desktop Access) Windows Chrome et Firefox
Narrateur Windows Périphérie
VoiceOver macOS Safari
Orque Linux Firefox
TalkBack Android Chrome et Firefox
VoiceOver (pour mobile) iOS Safari
ChromeVox ChromeOS Chrome

Commandes du lecteur d'écran

Une fois que votre logiciel de lecteur d'écran est correctement configuré pour votre ordinateur de bureau ou votre appareil mobile, vous devez consulter la documentation du lecteur d'écran (en lien dans le tableau précédent) et exécuter certaines commandes essentielles du lecteur d'écran pour vous familiariser avec la technologie. Si vous avez déjà utilisé un lecteur d'écran, envisagez d'en essayer un nouveau.

Lorsque vous utilisez un lecteur d'écran pour effectuer des tests d'accessibilité, votre objectif est de détecter les problèmes dans votre 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. Ainsi, vous pouvez faire beaucoup de choses avec des 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 lecteurs d'écran et autres TA, vous pouvez collaborer avec de nombreuses organisations et individus pour obtenir ces informations précieuses. N'oubliez pas que l'utilisation d'une TA pour tester du 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 totalement inclusifs.

Commandes principales pour les lecteurs d'écran d'ordinateur

Élément NVDA (Windows) VoiceOver (macOS)
Commande Insérer (clé NVDA) Ctrl + Option (touche VO)
Arrêter la lecture de l'audio Contrôle Contrôle
Lire l'élément suivant/précédent ↓ ou ↑ VO+→ ou ←
Commencer la lecture NDVA + ↓ VO + A
Liste des éléments/Rotor NVDA + F7 VO + U
Points de repère D VO + U
Headings H VO+Cmd+H
Liens K VO+Cmd+L
Commandes de formulaire F. VO+Cmd+J
Tables T VO+Cmd+T
Dans les tableaux NDVA + Alt + ↓ ↑ ← → VO + ↓ ↑ ← →

Commandes principales pour les lecteurs d'écran mobiles

É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/bas Balayez l'écran vers le haut ou le bas avec deux doigts Balayez l'écran vers le haut ou le bas avec trois doigts
Changer de page Balayez l'écran vers la gauche ou la droite avec deux doigts Balayer l'écran vers la gauche/droite avec trois doigts
Suivant/Précédent Balayer l'écran vers la gauche ou la droite avec un doigt Balayer l'écran vers la gauche ou la droite avec un doigt

Démonstration des tests du lecteur d'écran

Pour tester notre démonstration, nous avons utilisé Safari sur un ordinateur portable fonctionnant sous macOS et filmé le son. Vous pouvez suivre cette procédure avec 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, sur lequel toutes les mises à jour d'accessibilité automatiques et manuelles sont appliquées.

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 2

Activez le lecteur d'écran de votre choix et accédez à la page de démonstration. Vous pouvez parcourir toute 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émo. Nous vous encourageons à parcourir la démonstration avec votre propre lecteur d'écran.

Problème 1: structure du contenu

Les en-têtes et les points de repère sont l'un des principaux moyens utilisés par les internautes pour naviguer à l'aide de lecteurs d'écran. En leur absence, l'utilisateur de lecteur d'écran doit lire la page entière pour comprendre le contexte. Cela peut prendre beaucoup de temps et causer de la frustration. Si vous essayez de naviguer dans l'un ou l'autre des éléments dans la démo, vous découvrirez rapidement qu'ils n'existent pas.

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

Si vous avez tout mis à jour correctement, il ne devrait y avoir aucune modification visuelle, mais votre expérience de lecteur d'écran se sera considérablement améliorée.

Écoutez le lecteur d'écran naviguer dans le problème.
Nous allons résoudre ce problème.

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

Pour résoudre les problèmes liés aux en-têtes et aux points de repère, vous devez d'abord identifier chaque élément à baliser en tant que tel et mettre à jour le code HTML correspondant. 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 aucune modification visuelle, mais votre expérience de lecteur d'écran se sera considérablement améliorée.

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

Il est important de fournir du contenu aux utilisateurs de lecteurs d'écran sur l'objectif d'un lien et s'il les redirige vers un nouvel emplacement en dehors du site Web ou de l'application.

Dans notre démonstration, nous avons corrigé la plupart des liens lors de la mise à jour du texte alternatif de l'image active. Toutefois, il existe quelques liens supplémentaires sur les diverses maladies rares qui pourraient bénéficier d'un contexte supplémentaire, notamment parce qu'ils redirigent vers un nouvel emplacement.

<a href="https://rarediseases.org/rare-diseases/maple-syrup-urine-disease">
  Maple syrup urine disease (MSUD)
</a>
Écoutez le lecteur d'écran naviguer dans le problème.
Nous allons résoudre ce problème.

Pour résoudre ce problème pour les utilisateurs de lecteurs d'écran, nous mettons à jour le code pour ajouter d'autres informations, sans affecter l'élément visuel. Pour aider encore plus de personnes, comme celles souffrant de troubles cognitifs ou de la lecture, par exemple, nous pouvons ajouter un texte visuel supplémentaire.

Il existe de nombreux modèles que nous pouvons envisager d'ajouter des informations supplémentaires sur les liens. Étant donné la simplicité de notre environnement qui n'accepte qu'une seule langue, le libellé ARIA constitue une option simple dans cette situation. Vous remarquerez peut-être que le libellé ARIA remplace le texte d'origine du lien. Veillez donc à inclure cette information 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 du lien, écoutez le lecteur d'écran parcourir à nouveau la démo.

Problème 3: image décorative

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

<div class="section-right">
  <svg>...</svg>
</div>
Écoutez le lecteur d'écran naviguer dans le problème.
Nous allons résoudre ce problème.

Pour résoudre ce problème, nous devons d'abord déterminer si l'image est informative ou décorative. Par conséquent, nous devons ajouter le texte alternatif approprié pour l'image (image informative) ou masquer l'image pour les utilisateurs de lecteurs d'écran (décoratif).

Après avoir évalué les avantages et les inconvénients de la meilleure catégorisation de l'image, 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 répertorie 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 parcourir la démonstration.

Problème 4: décoration des puces

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

<p class="bullet">...</p>
Écoutez le lecteur d'écran naviguer dans le problème.
Nous allons résoudre ce problème.

Comme pour l'exemple d'image décorative abordé précédemment, vous pouvez ajouter un role="presentation" au code HTML avec la classe à puces pour le masquer pour le lecteur d'écran. De même, un role="none" fonctionnerait. Assurez-vous simplement de ne pas utiliser aria-hidden: true. Sinon, les informations de paragraphe seront masquées pour les utilisateurs de lecteurs d'écran.

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

Problème 5: champ de formulaire

Dans le module Forms, nous avons appris que tous les champs de formulaire doivent également comporter un libellé visuel et programmatique. Ce libellé doit rester visible à tout moment.

Dans notre démonstration, il manque un libellé visuel et programmatique dans le champ de l'adresse e-mail d'inscription à la newsletter. Il y a un élément d'espace réservé pour du texte, mais cela 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 le lecteur d'écran naviguer dans le problème.
Nous allons résoudre ce problème.

Pour résoudre ce problème, remplacez l'espace réservé au texte par un élément de libellé similaire. Cet élément de libellé est connecté par programmation 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 découvrir toutes ces modifications dans la version mise à jour de Codepen 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 un maximum de problèmes qu'un utilisateur peut rencontrer. Toutefois, cela ne signifie pas que votre site Web ou votre application seront parfaitement accessibles lorsque vous aurez terminé. Pour obtenir les meilleurs résultats, vous devez concevoir votre site Web ou votre application de façon accessible tout au long du processus et intégrer ces tests à vos autres tests pré-lancement.

Testez vos connaissances

Tester 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 devez utiliser un autre outil.
Orque
Orca est destiné aux utilisateurs de Firefox Linux, ce qui peut signifier que 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. Par conséquent, la meilleure solution dépend de la façon dont vous effectuez les tests. Si vous disposez de données analytiques ou de recherches qui en disent plus sur les utilisateurs de lecteurs d'écran, il peut être utile d'effectuer des tests avec les mêmes lecteurs d'écran.

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

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