Ce module se concentre sur l'utilisation des technologies d'assistance pour les tests d'accessibilité. Une personne ayant un handicap peut utiliser des AT pour augmenter, maintenir ou améliorer ses capacités à accomplir une tâche.
Dans l'espace numérique, les AT peuvent être :
- Aucune technologie ou technologie basique: bâtons pour la tête et la bouche, loupes, appareils avec 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 d'AT dans votre workflow de test global.
Principes de base des tests avec un lecteur d'écran
Dans ce module, nous nous concentrons sur l'une des solutions d'AT 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, puis convertit ces informations en sortie vocale ou en braille pour l'utilisateur.
Les lecteurs d'écran sont essentiels pour les personnes aveugles et sourdes aveugles, mais ils peuvent également être utiles aux personnes malvoyantes, présentant des troubles de la lecture et 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 dans 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. 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 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 des aspects importants pour créer des produits totalement 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 | Insertion↓ | Ctrl+Option+A |
Liste des éléments/Rotor | NVDA + F7 | Ctrl+Option+U |
Points de repère | D | Ctrl+Option+U |
Headings | H | Ctrl+Option+Cmd+H |
Liens | K | Ctrl+Option+Cmd+L |
Commandes de formulaire | V | Ctrl+Option+Cmd+J |
Tables | T | Ctrl+OptionCmd+T |
Dans les tableaux | InsertionAlt+↓ ↑ ← → | Ctrl+Option+↓ ↑ ← → |
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 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 avec n'importe quel lecteur d'écran, mais la manière dont vous rencontrerez 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 naviguer par l'un de ces éléments dans la démonstration, vous découvrirez 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.
Certains éléments inaccessibles ne peuvent pas être observés simplement en consultant 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 repère :
<main>...</main>
- Exemple de titre:
<h1>Join the Club</h1>
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.
Problème 2 : Lien de contexte
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>
Pour résoudre ce problème pour les utilisateurs de lecteurs d'écran, nous avons modifié le code pour ajouter plus d'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.
Nous pouvons prendre en compte de nombreux modèles différents 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>
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 le trouve et l'annonce comme "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>
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é pour l'image (image informative) ou masquer l'image pour les utilisateurs de lecteur d'écran (image décorative).
Nous avons pesé les avantages et les inconvénients de la meilleure façon de catégoriser l'image et avons décidé qu'elle était décorative. Cela signifie que nous souhaitons 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>
Problème 4: Décoration des puces
Vous avez peut-être remarqué que le lecteur d'écran lit l'image à puce CSS dans 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>
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"
peut fonctionner. Veillez simplement à ne pas utiliser aria-hidden: true
, sinon les utilisateurs de lecteur d'écran ne verront pas toutes les informations du paragraphe.
<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>
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é 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>
Conclusion
Félicitations ! Vous avez terminé tous les tests de cette démonstration. Vous pouvez examiner 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 est parfaitement accessible une fois que vous avez terminé. Pour obtenir les meilleurs résultats, concevez votre site Web ou votre application en tenant compte de l'accessibilité tout au long du processus, et intégrez 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é ?
Quel est l'objectif des tests avec des technologies d'assistance ?