Ce module se concentre sur l'utilisation de technologies d'assistance pour les tests d'accessibilité. Une personne handicapée peut utiliser une technologie d'assistance pour l'aider à augmenter, maintenir ou améliorer ses capacités à effectuer une tâche.
Dans l'espace numérique, les technologies d'assistance peuvent être les suivantes :
- Technologies simples ou peu sophistiquées : baguettes buccales ou frontales, loupes manuelles, appareils avec de gros boutons
- Technologies sophistiquées : appareils à activation vocale, appareils de suivi oculaire, claviers et souris adaptatifs
- Matériel : boutons-poussoirs, claviers ergonomiques, appareils braille à actualisation automatique
- Logiciels : programmes de synthèse vocale, sous-titres en direct, lecteurs d'écran
Nous vous encourageons à utiliser plusieurs types de technologies d'assistance dans votre workflow de test global.
Principes de base des tests de lecteurs d'écran
Dans ce module, nous nous concentrons sur l'une des technologies d'assistance 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 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, souffrant de troubles de la lecture et de handicaps cognitifs.
Compatibilité du navigateur
Plusieurs options de lecteurs d'écran sont disponibles. Les lecteurs d'écran les plus populaires sont JAWS, NVDA et VoiceOver pour les ordinateurs de bureau, ainsi que VoiceOver et Talkback pour les appareils mobiles.
Selon votre système d'exploitation, votre navigateur préféré et l'appareil que vous utilisez, un lecteur d'écran peut être la meilleure option. La plupart des lecteurs d'écran sont conçus pour des navigateurs Web et du matériel 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 |
| Narrator | 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 votre 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 quelques commandes essentielles pour vous familiariser avec cette technologie. Si vous avez déjà utilisé un lecteur d'écran, essayez-en un nouveau.
Lorsque vous utilisez un lecteur d'écran pour tester l'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'imiter 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 technologies d'assistance, vous pouvez vous rapprocher de nombreuses organisations et personnes pour obtenir ces informations précieuses. N'oubliez pas que l'utilisation d'une technologie d'assistance pour tester le code par rapport à un ensemble de règles et l'interrogation des utilisateurs sur leur expérience donnent souvent des résultats différents. Les deux aspects sont importants pour créer des produits entièrement inclusifs.
Commandes principales pour les lecteurs d'écran de bureau
| Élément | NVDA (Windows) | VoiceOver (macOS) |
|---|---|---|
| Touches de commande générales | Insertion | Contrôle+Option |
| Arrêter la lecture de l'audio | Contrôle | Contrôle |
| Lire suivant/précédent | ↓ ou ↑ | Contrôle+Option+→ ou ← |
| Commencer la lecture | Insertion↓ | Contrôle+Option+A |
| Liste des éléments/Rotor | NVDA + F7 | Contrôle+Option+U |
| Points de repère | D | Contrôle+Option+U |
| Titres | H | Contrôle+Option+Commande+H |
| Liens | K | Contrôle+Option+Commande+L |
| Éléments de contrôle de formulaire | V | Contrôle+Option+Commande+J |
| Tables | T | Contrôle+OptionCommande+T |
| Dans les tables | Insertion Alt + ↓ ↑ ← → | Contrôle+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 |
| Monter ou descendre | 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 | Balayez l'écran vers la gauche ou la 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 de lecteur d'écran
Pour tester notre démonstration, nous avons utilisé Safari sur un ordinateur portable exécutant macOS et nous avons capturé le son. Vous pouvez suivre ces étapes 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 à la version mise à jour de CodePen, qui contient toutes les mises à jour d'accessibilité automatisées et manuelles.
Affichez-la 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 envisager de 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 à exécuter la démonstration avec votre propre lecteur d'écran.
Problème 1 : Structure du contenu
Les titres et les points de repère sont l'un des principaux moyens de navigation pour les personnes qui utilisent des lecteurs d'écran. S'ils ne sont pas présents, un utilisateur de lecteur d'écran doit lire l'intégralité de la page pour comprendre le contexte. Cela peut prendre beaucoup de temps et être frustrant.
Si vous essayez de naviguer par élément dans la démonstration, 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 pas y avoir de modifications visuelles, mais votre expérience de lecteur d'écran aura été considérablement améliorée.
Résolvons ce problème.
Certains éléments inaccessibles ne peuvent pas être observés en regardant simplement le site. Vous
vous souvenez peut-être de l'importance des niveaux de titre et du HTML sémantique du
module Structure du contenu. Un 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 points de repère, vous devez d'abord identifier chaque élément qui doit être balisé comme tel et mettre à jour le code HTML associé. Veillez également à mettre à jour le code 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 pas y avoir de modifications visuelles, mais votre expérience de lecteur d'écran aura été considérablement améliorée.
Problème 2 : Contexte du lien
Il est important de fournir aux utilisateurs de lecteurs d'écran des informations sur l'objectif d'un lien et sur le fait qu'il les redirige ou non vers un nouvel emplacement 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, mais il existe quelques liens supplémentaires sur les différentes maladies rares qui pourraient bénéficier d'un contexte supplémentaire, en particulier 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 afin d'ajouter des informations, sans affecter l'élément visuel. Ou, pour aider encore plus de personnes, comme celles souffrant de troubles de la lecture et cognitifs, nous pouvons choisir d'ajouter du texte visuel supplémentaire.
Nous pouvons envisager de nombreux modèles différents pour ajouter des informations de lien supplémentaires. Dans notre environnement qui n'est compatible qu'avec une seule langue, un libellé ARIA est une option simple dans cette situation. Vous remarquerez peut-être que le libellé ARIA remplace le texte de 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'illustration
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. Toutefois, 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" à
le 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. En fonction de cette décision, nous devons ajouter le texte alternatif d'image approprié (image informative) ou masquer l'image aux utilisateurs de lecteurs d'écran (décorative).
Nous avons pesé le pour et le contre de la meilleure façon de catégoriser l'image et avons décidé qu'elle était décorative. Nous devons donc ajouter ou modifier le code pour masquer l'image. Une méthode rapide consiste à ajouter un role="presentation" directement à 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 puce
Vous avez peut-être remarqué que le lecteur d'écran lit l'image de puce CSS sous les sections sur les maladies rares. Bien que cette image ne soit pas la même que celle dont nous avons parlé dans le module Images, elle doit quand même être modifiée, car elle perturbe le flux du contenu et peut distraire ou dérouter un utilisateur de lecteur d'écran.
<p class="bullet">...</p>
Comme dans 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 à tout moment.
Dans notre démonstration, nous manquons à la fois un libellé visuel et programmatique dans le champ d'e-mail d'inscription à notre newsletter. Il existe un élément d'espace réservé de 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é de texte par un élément de libellé similaire. Cet élément de libellé est connecté de manière programmatique au champ de formulaire, et un 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 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 autant de problèmes que possible qu'un utilisateur pourrait rencontrer. Toutefois, cela ne signifie pas que votre site Web ou votre application est parfaitement accessible une fois que vous avez terminé. Vous obtiendrez les meilleurs résultats en concevant votre site Web ou votre application avec l'accessibilité tout au long du processus et en intégrant ces tests à vos autres tests de pré-lancement.