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.
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
Commandes principales pour les lecteurs d'écran mobiles
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.
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.
Problème 2: Lien vers le contexte
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>
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>
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>
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>
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>
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>
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>
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é ?
Quel est l'objectif des tests effectués avec une technologie d'assistance ?