06.10.2026 · Signal Titans Editorial
Chieko Asakawa preguntó cómo era la Web si no podías verla. Luego hizo que hablara.
A mediados de los años noventa, la Web se estaba convirtiendo en un lugar cada vez más visual.
Imágenes.
Enlaces.
Frames.
Navegación con ratón.
Para millones de personas, eso hacía Internet más emocionante.
Para Chieko Asakawa, revelaba otro problema.
¿Qué pasaba si la Web se volvía esencial antes de que los usuarios ciegos pudieran navegarla realmente?
Su respuesta fue IBM Home Page Reader — uno de los primeros voice browsers prácticos para la Web.
Asakawa conocía personalmente el problema de accesibilidad
Asakawa perdió la vista cuando era joven.
En aquel momento, la tecnología accesible en Japón todavía era limitada.
Leer material impreso podía requerir transcripción a Braille.
Editar documentos Braille era difícil.
Acceder a información a menudo dependía de otra persona.
Asakawa describiría después la pérdida de independencia como una de las partes más duras de quedarse ciega.
Esa experiencia moldeó los problemas que decidió resolver.
Entró en informática porque los ordenadores podían reducir la dependencia
Asakawa estudió literatura inglesa en la universidad.
Más tarde conoció la informática mediante un programa de formación para estudiantes ciegos.
Empezó a ver el ordenador no solo como una máquina, sino como una forma de superar barreras físicas.
En 1984 se incorporó a IBM Tokyo Research Laboratory como estudiante investigadora.
Un año después pasó a ser investigadora a tiempo completo.
Su trabajo inicial se centró en edición Braille y distribución digital de documentos Braille.
El patrón ya era claro:
Convertir información en una forma que el usuario pudiera controlar de manera independiente.
Entonces llegó la Web y creó una nueva brecha
La Web temprana prometía acceso a una enorme cantidad de información.
Pero la mayoría de navegadores asumían un usuario vidente.
Mover el ratón.
Encontrar enlaces visualmente.
Entender el layout desde la pantalla.
Reconocer botones, imágenes y frames.
Convertir texto en voz no era suficiente.
Un usuario ciego también necesitaba saber dónde estaba, qué era clicable y cómo moverse por la página con rapidez.
Home Page Reader convirtió la navegación en sonido y teclas
Asakawa y su equipo diseñaron Home Page Reader alrededor de un teclado numérico.
En lugar de apuntar con un ratón, los usuarios podían desplazarse mediante comandos simples.
El software convertía texto y estructura de página en voz.
Los enlaces podían sonar distintos del texto normal.
La estructura HTML podía representarse mediante señales de voz.
Los usuarios podían avanzar rápidamente por el contenido.
El objetivo no era solo hacer audible el texto.
Era hacer navegable la Web.
La interfaz usaba el sonido para comunicar estructura
Si toda una página se lee con la misma voz plana, el usuario recibe palabras pero pierde jerarquía.
Home Page Reader utilizaba sonido para comunicar diferencias entre elementos.
Los links podían tener una voz distinta.
Otros tipos de contenido podían señalarse de otra manera.
El usuario podía saltar, moverse y explorar en vez de escuchar pasivamente desde arriba hasta abajo.
Convertía una interfaz visual en un modelo de interacción auditivo.
El producto apareció en Japón en 1997
IBM lanzó Home Page Reader en Japón en 1997.
Después se amplió a varios idiomas.
IBM y National Inventors Hall of Fame lo describen como el primer practical voice browser que proporcionó acceso efectivo a Internet a usuarios ciegos y con baja visión.
A comienzos de los años 2000 se utilizaba ampliamente en distintos países.
Asakawa también recibió una patente estadounidense relacionada con la invención.
La innovación importante era independencia, no speech synthesis
La tecnología de voz ya existía.
El avance no era simplemente hacer hablar al ordenador.
Era diseñar el modelo de interacción alrededor de alguien que no podía depender de la pantalla.
Esta es una lección recurrente en accessibility engineering.
Añadir una función no es lo mismo que eliminar una barrera.
El usuario debe poder completar la tarea por sí mismo.
Eso suele exigir rediseñar navegación, feedback y control, no solo añadir output.
La accesibilidad reveló debilidades de la propia Web
El trabajo posterior de Asakawa fue más allá de ayudar a consumir páginas.
También desarrolló herramientas para que los diseñadores entendieran problemas de accesibilidad.
Un sitio podía cumplir técnicamente una guideline y seguir siendo difícil de usar.
El alt text podía existir pero ser inútil.
La navegación podía existir pero ser dolorosamente lenta.
La pregunta más profunda pasó a ser:
¿Puede el usuario utilizar realmente el sitio?
No:
¿Pasa el checklist?
Por eso la accesibilidad suele mejorar productos para todos
Diseñar para usuarios con restricciones obliga a hacer explícita la estructura.
Navegación clara.
Headings lógicos.
Labels significativos.
Control por teclado.
Interacción predecible.
No son solo features de accesibilidad.
Son señales de un producto bien estructurado.
El edge case suele revelar una debilidad oculta en la experiencia por defecto.
Asakawa llevó el mismo principio al mundo físico
Su investigación posterior fue más allá de sitios web.
Trabajó en IA y sistemas de navegación para ayudar a personas ciegas a moverse por espacios públicos con mayor independencia.
La tecnología cambió.
La pregunta siguió siendo parecida:
¿Cómo puede un sistema reducir la ayuda que una persona debe pedir a otra?
Ese es un objetivo de diseño más poderoso que simplemente añadir comodidad.
La mejor pregunta de accesibilidad no es “¿cómo damos soporte a este usuario?”
Es:
“¿Qué parte de nuestro producto obliga actualmente a este usuario a depender de otra persona?”
Home Page Reader fue poderoso porque respondió directamente a esa pregunta.
La Web se estaba convirtiendo en infraestructura esencial de información.
Asakawa no pidió a los usuarios ciegos que esperaran una versión separada.
Intentó hacer navegable la misma Web de forma independiente.
¿Qué parte de tu producto todavía supone que el usuario puede ver, oír, apuntar, escribir o moverse exactamente como lo hace tu equipo?
Fuentes
- IBM History — Chieko Asakawa
- National Inventors Hall of Fame — Chieko Asakawa
- IBM Research — User Interface of a Home Page Reader, 1998
- IBM History — A Commitment to Accessibility
- National Inventors Hall of Fame — Ensuring Access Through Innovation
- Retrato de la imagen destacada — Chieko Asakawa durante un experimento de campo en 2017, IBM Research, CC BY-SA 3.0 vía Wikimedia Commons. El gráfico mínimo web-a-voz es original; el derivado mantiene la misma licencia.
SIGNAL TITANS.jpg){kind=link}