Tri au clavier

Le mot sur cette image est écrit en braille. Il est invisible pour un utilisateur voyant. 

Pour le lire, utilisez un lecteur d’écran comme NVDA (gratuit, sur Windows)ou  VoiceOver (intégré à Mac).

Une fois activé, naviguez jusqu’à l’image, puis laissez l’outil lire son alternative textuelle.

Vous êtes dans la peau d’un utilisateur aveugle. Sans lecteur d’écran, ce mot reste inaccessible.

Principe

Pour s’assurer qu’un module est vraiment accessible, il faut tester la lecture de tous les contenus, titres, boutons et interactions avec un lecteur d’écran (NVDA).

Cette étape clé permet de vérifier que tout ce qui compte est bien annoncé à l’oral, que les éléments essentiels sont compris, et que rien d’inutile ne vient perturber la lecture.

Explication audio (transcription disponible)

Transcription

Tester avec un lecteur d’écran, c’est une étape exigeante : il faut que l’outil auteur soit compatible, conforme aux normes, et puisse s’adapter aux dispositifs des utilisateurs.

Ce test n’a de sens que si les autres aspects d’accessibilité visuelle ont déjà été pris en compte : structure des titres, ordre du focus, textes alternatifs…

Le lecteur d’écran restitue uniquement ce qui a été structuré correctement ; il ne compense aucun oubli.

Pour valider, il est pertinent d’écouter ce que le lecteur d’écran annonce réellement, et, si possible, de recueillir un retour auprès d’une personne utilisatrice habituelle.

Ce test permet de contrôler l’ensemble du parcours dans des conditions d’usage réelles. 

À vérifier

  • Vérifier que tous les textes et éléments essentiels sont correctement lus par le lecteur d’écran.
  • Vérifier que les boutons, liens et contrôles sont bien identifiés (nom, rôle, valeur).
  • Tester la compatibilité avec les lecteurs d’écran principaux (JAWS, NVDA…).
  • S’assurer que le parcours utilisateur reste logique et compréhensible à l’oral, sans repère visuel.

Pour qui ?

  • Personnes aveugles ou malvoyantes utilisant un lecteur d’écran (JAWS, NVDA, VoiceOver…)
  • Équipes de conception souhaitant valider l’accessibilité réelle d’un module

Pourquoi c’est important ?

Un module accessible aux lecteurs d’écran assure une expérience équitable à tous, respecte la loi et évite des exclusions massives. C’est aussi une garantie de robustesse pour tous les dispositifs d’assistance (trackball, commandes vocales…).

Comment réussir

  • Utilisez un lecteur d’écran (NVDA gratuit, JAWS en démo) pour tester chaque étape du module
  • Vérifiez que le contenu suit un ordre logique à l’oral, et que rien d’inutile n’est lu
  • Respectez les autres checkpoints : arborescence, focus, titres, alternatives textuelles…
  • Demandez un retour à un utilisateur ou expert si possible (ils ont des usages et un rythme différents)

Lecteurs d’écran et accessibilité : guide d’usage et de conception

Navigation clavier et lecteur vocal vont de pair.

Les lecteurs d’écran, comme NVDA, ajoutent leurs propres raccourcis pour naviguer plus vite dans le contenu (titres, liens, champs…). Il faut donc connaître à la fois les commandes du clavier et celles du lecteur d’écran.

Voir la fiche 5. Navigation clavier et focus pour les raccourcis clavier de base (Tab, Entrée…) et le comportement du focus (prérequis).

ActionRaccourci
Lecture automatique du contenu
NVDA
NVDA + Flèche bas
Arrêter la lecture vocaleCtrl
Quitter NVDANVDA + Q
Liste des liens/titresNVDA + F7
Aller au titre suivantH
Aller au lien suivantK
Aller au bouton suivantB
Aller à la case à cocher suivanteX
Aller au champ de formulaire suivantF

NVDA (Windows)

Gratuit, open source, utilisé par la majorité des testeurs pros et des utilisateurs non-voyants en France. NVDA permet de simuler la quasi-totalité des usages sur PC.

Cette vidéo explique l’installation, les bases de la navigation et la logique du lecteur d’écran NVDA (orientée développeur mais utile)

Jaws (Windows)

Référence pro du marché, payant (version démo limitée dans le temps).

  • Très utilisé en entreprise ou en univers institutionnel.
  • Quelques différences de comportement avec NVDA : pour un audit complet, il est pertinent de tester au moins avec NVDA et, si possible, avec JAWS.

Narrateur (Windows)

Lecteur d’écran intégré à Windows, utile pour un test rapide.

Peut dépanner pour une première vérification, mais ne reflète pas toujours le comportement “pro” des utilisateurs NVDA ou JAWS.

VoiceOver (Mac/iOS) & TalkBack (Android)

Lecteurs d’écran intégrés sur tous les Mac, iPhone/iPad (VoiceOver) et Android (TalkBack).

Indispensables pour tester le rendu réel sur mobile et tablette.

Fonctionnement spécifique : navigation par balayage, activation par double-tap, gestion des feedbacks et de la structure.

Point d’attention :
Certains outils intègrent une “voix” ou un lecteur d’écran simplifié dans le module. Cela ne remplace jamais les lecteurs d’écran, et ne doit ni les bloquer, ni empêcher les utilisateurs de conserver leurs propres réglages (voix, vitesse, préférences…).

Le WCAG exige la compatibilité avec les outils et les paramétrages personnalisés de chaque utilisateur (NVDA, JAWS, VoiceOver…).

Vidéo : navigation au lecteur d’écran sur mobile

Cette vidéo montre comment une personne aveugle navigue avec un lecteur d’écran sur mobile. Les utilisateurs expérimentés “scannent” l’information à l’oreille, souvent bien plus vite qu’on ne l’imagine.

Quand on teste soi-même, la navigation peut sembler complexe ou lente, mais pour ceux qui pratiquent au quotidien, c’est un usage naturel et efficace.

Les limites ressenties par un testeur ne sont pas celles d’un utilisateur formé.

S’appuyer sur les standards du web, c’est justement ce qui permet d’assurer la compatibilité : une activité accessible au clavier fonctionnera aussi sur mobile, avec les gestes tactiles ou d’autres dispositifs. C’est un vrai repère pour créer des contenus accessibles, même sans tout maîtriser.

Pour mieux comprendre, rien ne vaut d’observer directement les utilisateurs.

Pour en savoir plus sur l’accessibilité des activités interactives, voir la fiche 16. Activité accessible sans souris.

Réalité du terrain

Pour beaucoup de personnes aveugles ou en situation de handicap, la formation en ligne est une vraie opportunité d’accès, d’autonomie et de montée en compétences.

Mais dans la pratique, les besoins des utilisateurs de lecteurs d’écran restent souvent sous-estimés dans la conception.

  • Beaucoup sont peu ou pas formés aux outils, faute de ressources, formation ou accompagnement.
  • Les politiques d’accessibilité ne garantissent pas l’accès réel. Sans pratique, tests et retours, les besoins restent invisibles.
  • Seule la prise en compte du vécu, des retours d’expérience, et la participation des usagers dès la conception permet de garantir une accessibilité effective.
  • Le “droit à la compensation” en France est inscrit dans la loi depuis 2005 : si un parcours n’est pas accessible, l’organisme doit proposer une alternative. S’il n’existe pas d’alternative, ou si elle tarde à être transmise, ce n’est ni la motivation, ni le handicap qui bloquent l’apprenant, mais bien le manque d’accompagnement, d’anticipation et d’accessibilité.

L’accessibilité d’un module ne se limite pas à un ou deux critères : elle s’évalue dans la globalité du parcours utilisateur.

Le test avec un lecteur d’écran est un pilier essentiel de cette démarche : il permet de vérifier concrètement la robustesse, la cohérence et l’efficacité des contenus pour les utilisateurs non-voyants, et il révèle aussi des points d’amélioration qui profitent à l’ensemble des utilisateurs.

Pourquoi tester avec un lecteur d’écran ? (Ce qui est vraiment vérifié)

Tester avec un lecteur d’écran n’est ni un bonus, ni une option.
C’est le seul moyen de valider toute la chaîne accessibilité :

  • Structure logique des titres et contenus
  • Présence et pertinence des textes alternatifs
  • Ordre du focus et navigation
  • Feedbacks et transcriptions lisibles à l’oral

En accessibilité, chaque maillon compte. Vous pouvez renseigner tous les textes alternatifs que vous voulez : si l’outil ne gère pas la structure et l’ordre de lecture, cela restera quasi inutile, car l’utilisateur ne pourra pas naviguer dans le contenu.

Comment tester et progresser ? (c’est accessible à tous, pas réservé aux experts)

Tester un module avec un lecteur d’écran demande un peu de prise en main,
mais c’est abordable pour tous les concepteurs, même débutants.
L’essentiel est de s’autoriser à manipuler l’outil, d’écouter ce qui est restitué, et de repérer les éventuels blocages.

Pratiquez, échangez, formez-vous :

  • Testez vos modules avec NVDA, VoiceOver…
  • Comparez ce que vous entendez et ce que vous voyez
  • Demandez des retours d’utilisateurs ou d’experts, participez à des ateliers ou des formations
  • Plus vous testez tôt, plus vous évitez les surcoûts et les corrections en urgence

Agir, anticiper, contribuer

L’accessibilité ne peut pas reposer sur un seul expert : c’est une démarche collective où le concepteur a un vrai rôle à jouer.

  • Identifier les limites des outils utilisés
  • Repérer les activités ou contenus non accessibles
  • Mettre en place ou proposer des alternatives
  • Documenter ce qui n’est pas conforme pour que l’équipe puisse progresser
  • Conseiller et alerter aux besoins le commanditaires et les parties prenantes du projet
  • Faire appel à un expert

Anticiper, c’est clé : plus l’accessibilité est intégrée tôt, plus la mise en conformité sera simple, efficace et moins coûteuse.

La démarche se construit sur la durée, en impliquant tous les acteurs (concepteurs, experts, utilisateurs).

Encourager l’innovation et l’engagement, y compris pour les personnes en situation de handicap

L’enjeu n’est pas seulement de « rendre le contenu accessible », mais aussi de permettre à chacun de vivre des expériences formatives engageantes, interactives et, si possible, innovantes (pas simplement de proposer une transcription textuelle en alternative).

Parfois, il faut trouver le bon équilibre : si l’interactivité n’est pas accessible, prévoir une alternative claire (transcription, version textuelle…), mais ne pas renoncer à imaginer des expériences accessibles et stimulantes pour tous.

Des exemples venus du jeu vidéo, comme The Last of Us Part II salué pour son accessibilité poussée, montrent que concevoir des expériences immersives et inclusives est possible et reconnu.

Au final, la démarche se construit sur la durée, en impliquant tous les acteurs (concepteurs, experts, utilisateurs), et peut aussi porter les valeurs et l’ambition d’un projet.

  • Testez systématiquement vos modules avec un lecteur d’écran.
  • Agissez tôt, formez-vous et souvenez-vous : chaque action, même simple, fait progresser l’accessibilité pour tous.

Aller plus loin

Outils pour tester avec un lecteur d’écran

Articles

Guide et inspirations immersives

Suivre ma progression :