06.10.2026 · Signal Titans Editorial

Chieko Asakawa a demandé à quoi ressemblait le Web sans la vue. Puis elle l’a fait parler.

Grand portrait de Chieko Asakawa à côté d’un graphique minimal Web-vers-voix.

Au milieu des années 1990, le Web devenait de plus en plus visuel.

Images.

Liens.

Frames.

Navigation à la souris.

Pour des millions de personnes, Internet devenait plus passionnant.

Pour Chieko Asakawa, cela révélait un autre problème.

Que se passerait-il si le Web devenait essentiel avant que les utilisateurs aveugles puissent réellement le naviguer ?

Sa réponse devint IBM Home Page Reader — l’un des premiers voice browsers pratiques pour le Web.

Asakawa connaissait personnellement le problème d’accessibilité

Asakawa a perdu la vue très jeune.

À l’époque, les technologies accessibles au Japon étaient encore limitées.

Lire un document imprimé pouvait demander une transcription en Braille.

Modifier un document Braille était difficile.

L’accès à l’information dépendait souvent d’une autre personne.

Asakawa dira plus tard que perdre son indépendance fut l’un des aspects les plus difficiles de sa cécité.

Cette expérience orienta les problèmes qu’elle choisit de résoudre.

Elle entra dans l’informatique parce que les ordinateurs pouvaient réduire la dépendance

Asakawa étudia d’abord la littérature anglaise.

Elle découvrit ensuite l’informatique grâce à un programme de formation pour étudiants aveugles.

Elle commença à voir l’ordinateur non seulement comme une machine, mais comme un moyen de contourner des barrières physiques.

En 1984, elle rejoignit IBM Tokyo Research Laboratory comme étudiante chercheuse.

Un an plus tard, elle devint chercheuse à plein temps.

Ses premiers travaux portèrent sur l’édition Braille et la distribution numérique de documents Braille.

Le motif était déjà clair :

Transformer l’information en une forme que l’utilisateur peut contrôler de façon autonome.

Puis le Web arriva et créa une nouvelle fracture

Le Web des débuts promettait un accès à une quantité immense d’information.

Mais la plupart des navigateurs supposaient un utilisateur voyant.

Déplacer la souris.

Trouver un lien visuellement.

Comprendre le layout sur l’écran.

Reconnaître boutons, images et frames.

Convertir le texte en parole ne suffisait pas.

Un utilisateur aveugle devait aussi savoir où il se trouvait, quels éléments étaient cliquables et comment parcourir efficacement la page.

Home Page Reader transforma la navigation en son et en touches

Asakawa et son équipe conçurent Home Page Reader autour d’un pavé numérique.

Au lieu de pointer avec une souris, les utilisateurs pouvaient se déplacer dans la page avec des commandes simples.

Le logiciel convertissait le texte et la structure de la page en parole.

Les liens pouvaient être lus différemment du texte ordinaire.

La structure HTML pouvait être signalée par la voix.

Les utilisateurs pouvaient avancer rapidement dans le contenu.

L’objectif n’était pas seulement de rendre le texte audible.

Il fallait rendre le Web navigable.

L’interface utilisait le son comme structure

Si toute une page est lue avec la même voix plate, l’utilisateur reçoit les mots mais perd la hiérarchie.

Home Page Reader utilisait le son pour exprimer les différences entre éléments.

Les liens pouvaient avoir une voix distincte.

Différents types de contenu pouvaient être signalés différemment.

L’utilisateur pouvait sauter, se déplacer et explorer au lieu d’écouter passivement du début à la fin.

Une interface visuelle devenait un modèle d’interaction auditif.

Le produit fut lancé au Japon en 1997

IBM lança Home Page Reader au Japon en 1997.

Il fut ensuite étendu à plusieurs langues.

IBM et le National Inventors Hall of Fame le décrivent comme le premier practical voice browser donnant un accès efficace à Internet aux utilisateurs aveugles et malvoyants.

Au début des années 2000, il était largement utilisé à l’international.

Asakawa obtint aussi un brevet américain lié à cette invention.

L’innovation importante était l’indépendance, pas la synthèse vocale

La technologie vocale existait déjà.

La percée ne consistait pas simplement à faire parler l’ordinateur.

Elle consistait à concevoir l’interaction autour de quelqu’un qui ne pouvait pas dépendre de l’écran.

C’est une leçon récurrente de l’accessibility engineering.

Ajouter une fonction n’est pas la même chose que supprimer une barrière.

L’utilisateur doit pouvoir accomplir la tâche de manière autonome.

Cela exige souvent de repenser navigation, feedback et contrôle, pas seulement d’ajouter une sortie.

L’accessibilité révélait les faiblesses du Web lui-même

Les travaux ultérieurs d’Asakawa dépassèrent l’accès des utilisateurs aveugles aux sites.

Elle développa aussi des outils aidant les designers à comprendre les problèmes d’accessibilité de leurs pages.

Un site peut respecter techniquement une guideline tout en restant difficile à utiliser.

Un alt text peut être présent mais inutile.

Une navigation peut exister mais être extrêmement lente.

La vraie question devint :

L’utilisateur peut-il réellement utiliser le site ?

Pas :

Le site passe-t-il une checklist ?

C’est pourquoi l’accessibilité améliore souvent les produits pour tous

Concevoir pour des utilisateurs contraints oblige les équipes à rendre la structure explicite.

Navigation claire.

Headings logiques.

Labels significatifs.

Contrôle clavier.

Interaction prévisible.

Ce ne sont pas seulement des fonctions d’accessibilité.

Ce sont les signes d’un produit bien structuré.

L’edge case révèle souvent une faiblesse cachée dans l’expérience par défaut.

Asakawa a ensuite appliqué le même principe au monde physique

Ses recherches ultérieures dépassèrent les sites web.

Elle travailla sur des systèmes d’IA et de navigation aidant les utilisateurs aveugles à se déplacer de manière plus autonome dans les espaces publics.

La technologie changeait.

La question restait proche :

Comment un système peut-il réduire la quantité d’aide qu’une personne doit demander à quelqu’un d’autre ?

C’est un objectif de design plus puissant que le simple confort.

La meilleure question d’accessibilité n’est pas « comment soutenir cet utilisateur ? »

C’est :

« Quelle partie de notre produit oblige actuellement cet utilisateur à dépendre de quelqu’un d’autre ? »

Home Page Reader était puissant parce qu’il répondait directement à cette question.

Le Web devenait une infrastructure essentielle d’information.

Asakawa n’a pas demandé aux utilisateurs aveugles d’attendre une version séparée.

Elle a essayé de rendre le même Web navigable de manière autonome.

Quelle partie de votre produit suppose encore que l’utilisateur peut voir, entendre, pointer, taper ou bouger exactement comme votre équipe ?