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.
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.
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>
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>
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>
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>
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>
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>
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>
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é ?
Quel est l'objectif des tests avec une technologie d'assistance ?