Synthèse vocale vs lecteurs d'écran

Votre contenu a une voix

La technologie de synthèse vocale (TTS) convertit l’information écrite en audio. Elle aide les personnes aveugles, malvoyantes, dyslexiques et atteintes de TDAH à consommer le contenu d’une manière qui leur convient. La synthèse vocale est aussi largement utilisée dans les écoles, par les apprenants en langues et par les professionnels qui relisent à l’oreille plutôt qu’à l’œil.

Parce que la synthèse vocale et les lecteurs d’écran produisent tous deux une voix synthétique, on suppose souvent qu’il s’agit de la même chose — ou qu’ajouter un bouton « lire à voix haute » à un site web le rend accessible aux utilisateurs aveugles. Cette supposition est fausse, et agir en conséquence peut vous laisser avec un site qui semble accessible mais que beaucoup de personnes ne peuvent pas réellement utiliser. Cet article explique comment fonctionne chaque technologie, qui en dépend, où se situe réellement la frontière entre les deux, et ce qu’il faut faire pour bien concevoir pour les lecteurs d’écran. Si vous ne deviez retenir qu’une chose, retenez celle-ci : un widget de lecture à voix haute est une fonctionnalité de confort, pas une fonctionnalité d’accessibilité.

Comment fonctionne la synthèse vocale ?

La synthèse vocale traite le texte en trois grandes étapes :

Analyse du texte — déterminer le ton, la grammaire et la structure, développer les nombres et les symboles (« 5 € » devient « cinq euros »), et segmenter les phrases.
Traitement linguistique — calculer la prononciation, l’accentuation et l’emphase, souvent à l’aide d’un dictionnaire de prononciation associé à des règles pour les mots inconnus.
Synthèse audio — générer la parole à partir de modèles vocaux mathématiques, en utilisant de plus en plus des réseaux de neurones qui sonnent bien plus naturels que les anciens moteurs concaténatifs.

Les systèmes modernes proposent une personnalisation de la voix telle que la vitesse, la hauteur, le profil vocal et le choix de la langue. Le point crucial est ce que la synthèse vocale prend en entrée : un bloc de texte que quelqu’un a déjà sélectionné, collé ou désigné. La synthèse vocale est fondamentalement une technologie de restitution du contenu. Elle prononce ce qu’on lui donne. Elle n’explore pas une interface et n’a aucune notion de boutons, de champs de formulaire ou de structure de page.

Quelles sont les limites de la technologie de synthèse vocale ?

La synthèse vocale est réellement utile, mais elle n’est pas parfaite, et ses limites comptent pour la comparaison qui suit :

Lacunes de prononciation — elle peut mal prononcer les mots rares, les noms propres, les termes médicaux ou juridiques et les abréviations.
Prise en charge inégale des langues — beaucoup d’outils gèrent bien les langues courantes mais peinent avec les langues moins répandues et les dialectes régionaux.
Ton et nuance — la synthèse vocale a du mal avec le sarcasme, l’humour et les expressions idiomatiques, si bien que le contenu peut être restitué avec le mauvais ton.
Pas de modèle d’interaction — et c’est le point essentiel : la synthèse vocale lit ; elle ne vous permet pas de faire quoi que ce soit. Vous ne pouvez pas remplir un formulaire de paiement, fermer une fenêtre modale ou passer d’un élément de menu à un autre avec la seule synthèse vocale.

Cette dernière limite est précisément là où commence la confusion avec les lecteurs d’écran.

Quelle est la différence entre la synthèse vocale et la technologie des lecteurs d’écran ?

C’est là que naît le malentendu courant. La synthèse vocale lit le texte à voix haute — c’est sa fonction première. Un lecteur d’écran fait bien plus : il permet aux utilisateurs de naviguer et d’utiliser tout un ordinateur ou appareil mobile à l’oreille et au clavier (ou par gestes tactiles).

Les lecteurs d’écran annoncent les étiquettes d’interface, les champs de formulaire, les boutons et les liens ; ils lisent le texte alternatif des images afin que les utilisateurs comprennent le contenu visuel ; et ils exposent l’état des composants — qu’une case soit cochée, qu’un menu soit déplié, qu’un onglet soit sélectionné ou qu’une erreur soit apparue. Ils transforment une interface visuelle pilotée à la souris en une interface linéaire, audible et utilisable.

Une façon rapide de saisir la différence : la synthèse vocale répond à la question « Que dit ce paragraphe ? » Un lecteur d’écran répond à « Où suis-je, que puis-je faire ici et que vient-il de se passer ? » La première concerne la consommation de contenu. La seconde concerne le contrôle d’un logiciel.

Comment un utilisateur de lecteur d’écran parcourt réellement une page

Les utilisateurs voyants parcourent une page en quelques secondes. Un utilisateur de lecteur d’écran construit un modèle mental de manière séquentielle et s’appuie sur la structure pour se déplacer efficacement. En pratique, il :

Saute d’un titre à l’autre pour comprendre le plan de la page (c’est pourquoi une hiérarchie de titres correcte compte tant).
Affiche une liste de tous les liens ou de tous les champs de formulaire pour naviguer par repère plutôt que de lire de haut en bas.
Utilise les régions de repère (bannière, navigation, contenu principal, pied de page) pour aller directement au contenu souhaité.
Parcourt les éléments interactifs avec la touche Tab et s’attend à ce que le focus se pose à un endroit visible et logique.
Écoute les annonces en direct lorsqu’un changement survient sans rechargement complet de la page.

Rien de tout cela ne fonctionne si le balisage sous-jacent ne décrit pas honnêtement la page. Une fonctionnalité de lecture à voix haute ne fournit aucun de ces repères de navigation — elle se contente de réciter le texte présent à l’écran, dans l’ordre visuel, sans aucun moyen d’actionner les commandes.

Qui utilise quoi, et pourquoi c’est important

La synthèse vocale est utilisée par un large public, souvent de manière situationnelle : personnes dyslexiques, atteintes de TDAH ou malvoyantes ; multitâches ; apprenants en langues ; et quiconque préfère simplement écouter. La plupart de ces utilisateurs peuvent encore voir l’écran et utiliser une souris.

Les utilisateurs de lecteurs d’écran comprennent les personnes aveugles ou atteintes de déficiences visuelles sévères, ainsi que certaines personnes ayant un handicap cognitif ou moteur, qui dépendent de cette technologie pour pouvoir utiliser un appareil tout court. Pour elles, ce n’est pas une couche de préférence ajoutée sur une interface déjà utilisable — c’est l’interface elle-même. Les outils les plus courants sont NVDA et JAWS sous Windows, VoiceOver sur les appareils Apple et TalkBack sous Android. Chacun interprète la même page web légèrement différemment, ce qui est l’une des raisons pour lesquelles tester avec chacun d’eux est important.

Pourquoi les widgets de lecture à voix haute ne remplacent pas l’accessibilité

Un nombre croissant de sites web ajoutent un bouton « écouter cette page » ou un widget tiers qui surligne et lit le texte. Ces outils peuvent aider certains lecteurs, et il n’y a rien de mal à en proposer un par commodité. Le problème est de le considérer comme un remplacement d’une véritable prise en charge des lecteurs d’écran. Il ne l’est pas, pour plusieurs raisons concrètes.

Ils ne font que lire ; ils n’actionnent rien. Un widget de lecture à voix haute récitera votre grille tarifaire, mais il ne peut pas permettre à un utilisateur aveugle de choisir une formule, d’ouvrir le panier, de saisir ses informations de paiement et de finaliser l’achat. Les vraies tâches exigent des commandes actionnables, pas une narration.
Ils ne peuvent pas exposer les états ni les rôles. Qu’un bouton soit enfoncé, qu’un champ soit obligatoire, qu’une section soit repliée ou qu’un message d’erreur vienne d’apparaître — rien de tout cela n’est transmis par la lecture du texte visible. Les lecteurs d’écran s’appuient sur les rôles, les noms et les états du balisage pour l’annoncer.
Les utilisateurs de lecteurs d’écran disposent déjà d’un outil. Les utilisateurs aveugles apportent leur propre lecteur d’écran, finement réglé selon leurs préférences et leur mémoire musculaire. Un widget au niveau de la page entre en concurrence avec lui, l’entrave parfois et ne fait rien pour corriger le balisage défectueux sur lequel leur lecteur d’écran bute.
Ils masquent les problèmes au lieu de les corriger. Si un champ de formulaire n’a pas d’étiquette, le widget l’ignorera tout comme le ferait un lecteur d’écran — mais désormais l’étiquette manquante est dissimulée derrière une fonctionnalité qui paraît utile. Le défaut sous-jacent demeure.

Cette même logique s’applique, de manière encore plus marquée, aux soi-disant surcouches d’accessibilité — des scripts qui promettent une conformité instantanée en superposant des corrections automatisées et une barre d’outils à un site existant. Ils ne réparent pas le code sous-jacent, entrent fréquemment en conflit avec la propre technologie d’assistance des utilisateurs et ne peuvent pas offrir une conformité authentique. La voie fiable consiste à corriger la source. Pour une explication plus complète des raisons pour lesquelles les correctifs superficiels sont insuffisants, consultez notre guide sur la vraie accessibilité numérique.

Un exemple concret : le paiement qui « parle »

Imaginez une boutique en ligne qui a ajouté un widget de lecture à voix haute et qui est convaincue que le site est désormais accessible. Un client aveugle arrive avec son propre lecteur d’écran en fonctionnement. La description du produit se lit sans problème — cette partie n’est que du texte. Mais la commande « Ajouter au panier » est un div stylisé doté d’un gestionnaire de clic au lieu d’un véritable bouton, si bien que le lecteur d’écran ne l’annonce jamais comme un bouton et que le clavier ne peut pas l’atteindre. Le sélecteur de quantité met à jour un total sans région live, donc le changement est silencieux. Le champ du code promo a un texte d’invite mais aucune étiquette associée, il n’est donc annoncé que comme « zone de texte ». Le formulaire de livraison affiche visuellement une erreur en rouge, mais l’erreur n’est pas reliée au champ et n’est pas du tout annoncée. Le widget de lecture à voix haute récite volontiers le texte visible et ne change rien à tout cela. Le client peut entendre le discours marketing mais ne peut pas finaliser un achat. Cet écart — entre entendre le contenu et utiliser un produit — constitue toute la différence entre une fonctionnalité de confort et l’accessibilité.

Ce qu’exige réellement la conception pour les lecteurs d’écran

Prendre en charge les lecteurs d’écran ne consiste pas à ajouter une fonctionnalité — il s’agit de construire vos pages de sorte que le sens, la structure et le comportement soient disponibles pour le logiciel, et pas seulement pour l’œil humain. Les ingrédients essentiels :

Un HTML sémantique et structuré

Utilisez de vrais titres (h1–h6) dans un ordre logique, des boutons et des liens natifs pour les bons usages, des listes pour les listes, et des éléments de repère pour les régions de la page. Le HTML sémantique transporte gratuitement l’information d’accessibilité ; un amas de conteneurs génériques n’en transporte aucune.

Des alternatives textuelles pour le contenu non textuel

Chaque image porteuse de sens a besoin d’un texte alternatif exact, et les images décoratives doivent être marquées pour être ignorées. Les icônes qui jouent le rôle de boutons ont besoin de noms accessibles. Les graphiques et infographies ont besoin d’un équivalent textuel qui transmet la même information.

Des noms, rôles et états accessibles

Les champs de formulaire ont besoin d’étiquettes associées programmatiquement. Les composants personnalisés — onglets, accordéons, listes déroulantes combinées, fenêtres modales — ont besoin des rôles et états corrects pour que le lecteur d’écran annonce ce qu’ils sont et comment ils se comportent. Là où le HTML natif ne suffit pas, ARIA comble le manque, mais il doit être utilisé avec précision ; un ARIA incorrect est pire que pas d’ARIA du tout.

Utilisabilité au clavier et gestion du focus

Tout ce qui fonctionne à la souris doit fonctionner au clavier, l’ordre de focus doit être logique, l’indicateur de focus doit être visible, et les changements dynamiques (ouverture d’une boîte de dialogue, apparition d’une erreur) doivent déplacer ou annoncer le focus de manière appropriée. La prise en charge du clavier et celle des lecteurs d’écran sont profondément liées.

Annoncer les changements dynamiques

Lorsque le contenu se met à jour sans rechargement de page — un message de validation de formulaire, un compteur de panier, un état de chargement — utilisez des régions live pour que le lecteur d’écran signale à l’utilisateur que quelque chose s’est passé. Les mises à jour silencieuses sont invisibles pour les personnes qui ne peuvent pas voir l’écran.

Toutes ces attentes sont codifiées dans les critères de succès des WCAG 2.2, qui forment l’ossature technique de l’European Accessibility Act et de l’ADA appliqués au web. Si vous voulez le détail pratique, notre guide de test des lecteurs d’écran explique pas à pas comment vérifier chacun de ces comportements avec de vrais outils.

Pourquoi « ça se lit bien pour moi » est trompeur

Un développeur voyant peut activer une fonctionnalité de lecture à voix haute, entendre des phrases nettes et conclure que la page est accessible. Le piège, c’est que la lecture à voix haute reproduit l’ordre de lecture visible et le texte visible, qui ont déjà tous deux du sens pour quelqu’un qui regarde l’écran. Cela ne vous dit rien sur le fait qu’une liste déroulante personnalisée annonce ses options, que le focus est piégé à l’intérieur d’une boîte de dialogue ouverte, qu’un bouton à icône seule possède un nom, ou que l’ordre de tabulation correspond à la disposition visuelle. Ce sont précisément les choses qui dysfonctionnent pour les utilisateurs de lecteurs d’écran, et précisément les choses qu’une démonstration de lecture à voix haute ne peut pas révéler. Le seul moyen de savoir est de tester comme le font les utilisateurs réels.

Comment tester pour les deux — et pourquoi l’automatisation seule ne suffit pas

Vous ne pouvez pas confirmer qu’une page fonctionne pour les utilisateurs de lecteurs d’écran en écoutant un bouton de lecture à voix haute. Vous le confirmez en vérifiant la structure, les noms, les rôles, les états, le fonctionnement au clavier et l’expérience réelle du lecteur d’écran avec plusieurs outils et plateformes.

Un processus solide combine trois niveaux :

L’analyse automatisée pour repérer les problèmes en grand volume, détectables par machine — textes alternatifs manquants, étiquettes vides, références ARIA cassées, défauts de contraste. Notre logiciel d’analyse d’accessibilité et une analyse d’accessibilité gratuite sont un moyen rapide d’établir un point de départ.
Les tests manuels par des experts pour évaluer tout ce que l’automatisation ne peut pas juger : si un nom est pertinent, si l’ordre de focus a du sens, si un widget personnalisé est réellement utilisable. Le raisonnement derrière ce niveau est abordé dans notre guide des audits d’accessibilité manuels.
Les tests avec de vraies technologies d’assistance et de vrais utilisateurs. Rien ne remplace le pilotage de la page avec NVDA, JAWS, VoiceOver et TalkBack — et, idéalement, l’observation de personnes qui utilisent ces outils au quotidien. Nos audits réalisés par des personnes en situation de handicap apportent exactement cette expertise vécue.

Les outils automatisés ne détectent généralement qu’une partie des critères de succès des WCAG 2.2 ; le reste exige le jugement humain. Considérer une analyse automatisée réussie comme une preuve d’accessibilité relève de la même catégorie d’erreur que de considérer un widget de lecture à voix haute comme une prise en charge des lecteurs d’écran.

Où QualiBooth intervient

QualiBooth teste votre site web pour les scénarios d’usage de la synthèse vocale comme des lecteurs d’écran, afin que votre contenu soit accessible aux utilisateurs qui s’appuient sur l’une ou l’autre technologie — et afin que les personnes qui dépendent d’un lecteur d’écran puissent non seulement entendre votre contenu mais aussi réellement utiliser votre produit. Notre boîte à outils d’accessibilité et la plateforme Agora combinent l’analyse avec une revue manuelle structurée, et notre équipe de conseil en accessibilité vous aide à corriger ce que les tests révèlent et à vous aligner sur les exigences des WCAG 2.2, de l’EAA et de l’ADA.

La conclusion est simple. Donner une voix à votre contenu est une attention agréable. Rendre votre contenu navigable, utilisable et correctement annoncé à un lecteur d’écran, c’est l’accessibilité — et une seule de ces options satisfait la loi et les personnes qu’elle protège.