Texto a voz vs. lectores de pantalla

Tu contenido tiene voz

La tecnología de texto a voz (TTS) convierte la información escrita en audio. Ayuda a las personas con ceguera, discapacidad visual, dislexia y TDAH a consumir contenido de una manera que les funciona. El TTS también se usa ampliamente en las escuelas, por quienes aprenden idiomas y por profesionales que corrigen de oído en lugar de con la vista.

Como tanto el TTS como los lectores de pantalla producen una voz sintética, la gente suele asumir que son lo mismo, o que añadir un botón de «leer en voz alta» a un sitio web lo hace accesible para usuarios ciegos. Esa suposición es errónea, y actuar en consecuencia puede dejarte con un sitio que suena accesible pero que muchas personas no pueden usar realmente. Este artículo explica cómo funciona cada tecnología, quién depende de ella, dónde está realmente la línea que las separa y qué hace falta para desarrollar correctamente para lectores de pantalla. Si solo recuerdas una cosa, que sea esta: un widget de lectura en voz alta es una función de comodidad, no una función de accesibilidad.

¿Cómo funciona el TTS?

El TTS procesa el texto en tres grandes etapas:

Análisis del texto — determinar el tono, la gramática y la estructura, expandir números y símbolos («5 $» se convierte en «cinco dólares») y segmentar las frases.
Procesamiento lingüístico — calcular la pronunciación, el acento y el énfasis, a menudo usando un diccionario de pronunciación más reglas para palabras desconocidas.
Síntesis de audio — generar el habla a partir de modelos matemáticos de voz, cada vez más mediante redes neuronales que suenan mucho más naturales que los antiguos motores concatenativos.

Los sistemas modernos ofrecen personalización de la voz, como velocidad, tono, persona de la voz y selección de idioma. El punto crucial es qué toma el TTS como entrada: un bloque de texto que alguien ya ha seleccionado, pegado o señalado. El TTS es, en esencia, una tecnología de salida de contenido. Dice lo que se le da. No explora una interfaz, y no tiene noción de botones, campos de formulario ni estructura de página.

¿Cuáles son las limitaciones de la tecnología TTS?

El TTS es genuinamente útil, pero no es perfecto, y sus límites importan para la comparación que viene a continuación:

Lagunas de pronunciación — puede pronunciar mal palabras poco comunes, nombres propios, términos médicos o jurídicos y abreviaturas.
Soporte de idiomas desigual — muchas herramientas manejan bien los idiomas mayoritarios, pero tienen dificultades con idiomas menos comunes y dialectos regionales.
Tono y matiz — el TTS tiene problemas con el sarcasmo, el humor y las expresiones idiomáticas, por lo que el contenido puede transmitirse con el tono equivocado.
Sin modelo de interacción — y esta es la grande: el TTS lee; no te deja hacer nada. No puedes rellenar un formulario de pago, descartar una ventana modal ni moverte entre los elementos de un menú usando solo TTS.

Esa última limitación es precisamente donde empieza la confusión con los lectores de pantalla.

¿Cuál es la diferencia entre la tecnología de texto a voz y la de lector de pantalla?

Aquí es donde surge el malentendido común. El texto a voz lee texto en voz alta: esa es su función principal. Un lector de pantalla hace mucho más: permite a los usuarios navegar y operar un ordenador o dispositivo móvil completo de oído y con el teclado (o gestos táctiles).

Los lectores de pantalla anuncian las etiquetas de la interfaz, los campos de formulario, los botones y los enlaces; leen el texto alternativo de las imágenes para que los usuarios comprendan el contenido visual; y exponen el estado de los componentes: si una casilla está marcada, si un menú está desplegado, si una pestaña está seleccionada o si ha aparecido un error. Convierten una interfaz visual, manejada con el ratón, en una lineal, audible y operable.

Una forma rápida de sentir la diferencia: el TTS responde a la pregunta «¿qué dice este párrafo?» Un lector de pantalla responde «¿dónde estoy, qué puedo hacer aquí y qué acaba de pasar?» Lo primero tiene que ver con consumir contenido. Lo segundo, con controlar software.

Cómo se mueve realmente por una página un usuario de lector de pantalla

Los usuarios videntes escanean una página en segundos. Un usuario de lector de pantalla construye un modelo mental de forma secuencial y se apoya en la estructura para moverse con eficiencia. En la práctica:

Saltan entre encabezados para entender el esquema de la página (por eso una jerarquía de encabezados correcta importa tanto).
Abren una lista de todos los enlaces o de todos los campos de formulario para navegar por puntos de referencia en lugar de leer de arriba abajo.
Usan las regiones de referencia (banner, navegación, contenido principal, pie de página) para saltar directamente al contenido que quieren.
Recorren los elementos interactivos con la tecla Tab y esperan que el foco aterrice en un lugar visible y lógico.
Escuchan los anuncios en directo cuando algo cambia sin una recarga completa de la página.

Nada de esto funciona a menos que el marcado subyacente describa la página con honestidad. Una función de «leer en voz alta» no proporciona ninguna de estas ayudas de navegación: simplemente narra el texto que haya en pantalla, en orden visual, sin forma de operar los controles.

Quién usa cada una y por qué importa

El TTS lo usa un público amplio, a menudo de forma situacional: personas con dislexia, TDAH o baja visión; quienes hacen varias tareas a la vez; quienes aprenden idiomas; y cualquiera que simplemente prefiera escuchar. La mayoría de estos usuarios todavía pueden ver la pantalla y usar un ratón.

Los usuarios de lectores de pantalla incluyen a personas ciegas o con discapacidad visual grave, así como a algunas personas con discapacidades cognitivas o motoras, que dependen de la tecnología para poder usar un dispositivo siquiera. Para ellos no es una capa de preferencia sobre una interfaz utilizable: es la interfaz. Las herramientas más comunes son NVDA y JAWS en Windows, VoiceOver en los dispositivos de Apple y TalkBack en Android. Cada una interpreta la misma página web de forma ligeramente distinta, lo cual es una de las razones por las que probar en todas ellas importa.

Por qué los widgets de lectura en voz alta no sustituyen a la accesibilidad

Un número creciente de sitios web añade un botón de «escuchar esta página» o un widget de terceros que resalta y lee el texto. Estas herramientas pueden ayudar a algunos lectores, y no hay nada malo en ofrecer una como comodidad. El problema es tratarla como un sustituto del soporte real para lectores de pantalla. No lo es, por varias razones concretas.

Solo leen; no operan. Un widget de lectura en voz alta narrará tu tabla de precios, pero no puede permitir que un usuario ciego seleccione un plan, abra el carrito, introduzca los datos de pago y complete la compra. Las tareas reales requieren controles operables, no narración.
No pueden exponer el estado ni los roles. Si un botón está pulsado, si un campo es obligatorio, si una sección está plegada o si acaba de aparecer un mensaje de error: nada de eso se transmite al leer el texto visible. Los lectores de pantalla se basan en los roles, los nombres y los estados del marcado para anunciarlo.
Los usuarios de lectores de pantalla ya tienen una herramienta. Los usuarios ciegos traen su propio lector de pantalla, finamente ajustado a sus preferencias y a su memoria muscular. Un widget a nivel de página compite con él, a veces interfiere con él y no hace nada para arreglar el marcado defectuoso con el que su lector de pantalla se atasca.
Enmascaran los problemas en lugar de arreglarlos. Si un campo de formulario no tiene etiqueta, el widget lo saltará igual que lo haría un lector de pantalla, pero ahora la etiqueta que falta queda oculta tras una función que parece útil. El defecto subyacente permanece.

Esta misma lógica se aplica, con aún más fuerza, a las llamadas capas de accesibilidad (overlays): scripts que prometen un cumplimiento instantáneo superponiendo correcciones automatizadas y una barra de herramientas a un sitio existente. No reparan el código subyacente, a menudo entran en conflicto con la propia tecnología de asistencia de los usuarios y no pueden lograr una conformidad genuina. El camino fiable es arreglar la fuente. Para una explicación más completa de por qué las correcciones superficiales se quedan cortas, consulta nuestra guía sobre la verdadera accesibilidad digital.

Un ejemplo concreto: el pago que «habla»

Imagina una tienda online que ha añadido un widget de lectura en voz alta y está convencida de que el sitio ya es accesible. Una clienta ciega llega con su propio lector de pantalla en funcionamiento. La descripción del producto se lee bien: esa parte es solo texto. Pero el control de «Añadir al carrito» es un div con estilo y un controlador de clic en lugar de un botón real, así que el lector de pantalla nunca lo anuncia como botón y el teclado no puede alcanzarlo. El selector de cantidad actualiza un total sin región en directo, por lo que el cambio es silencioso. El campo del código promocional tiene texto de marcador de posición pero ninguna etiqueta asociada, así que se anuncia solo como «editar texto». El formulario de envío muestra un error en rojo visualmente, pero el error no está vinculado al campo y no se anuncia en absoluto. El widget de lectura en voz alta narra alegremente el texto visible y no cambia nada de esto. La clienta puede oír el texto de marketing pero no puede completar una compra. Esa brecha —entre oír el contenido y operar un producto— es toda la diferencia entre una función de comodidad y la accesibilidad.

Qué exige realmente desarrollar para lectores de pantalla

Dar soporte a los lectores de pantalla no consiste en añadir una función, sino en construir tus páginas de modo que el significado, la estructura y el comportamiento estén disponibles para el software, no solo para el ojo humano. Los ingredientes clave:

HTML semántico y estructurado

Usa encabezados reales (h1–h6) en un orden lógico, botones y enlaces nativos para los fines adecuados, listas para las listas y elementos de referencia para las regiones de la página. El HTML semántico transmite información de accesibilidad gratis; un muro de contenedores genéricos no transmite ninguna.

Alternativas textuales para el contenido no textual

Cada imagen significativa necesita un texto alternativo preciso, y las imágenes decorativas deben marcarse para que se omitan. Los iconos que actúan como botones necesitan nombres accesibles. Los gráficos y las infografías necesitan un equivalente textual que transmita la misma información.

Nombres, roles y estados accesibles

Los campos de formulario necesitan etiquetas asociadas mediante programación. Los componentes personalizados —pestañas, acordeones, cuadros combinados, ventanas modales— necesitan los roles y estados correctos para que el lector de pantalla anuncie qué son y cómo se comportan. Donde el HTML nativo no basta, ARIA llena el hueco, pero debe usarse con precisión; un ARIA incorrecto es peor que ninguno.

Operabilidad por teclado y gestión del foco

Todo lo que funciona con el ratón debe funcionar con el teclado, el orden del foco debe ser lógico, el indicador de foco debe ser visible, y los cambios dinámicos (abrir un diálogo, revelar un error) deben mover o anunciar el foco de forma apropiada. El soporte de teclado y el soporte de lector de pantalla están profundamente entrelazados.

Anunciar los cambios dinámicos

Cuando el contenido se actualiza sin recargar la página —un mensaje de validación de formulario, un contador del carrito, un estado de carga— usa regiones en directo para que el lector de pantalla le diga al usuario que ha pasado algo. Las actualizaciones silenciosas son invisibles para quienes no pueden ver la pantalla.

Todas estas expectativas están codificadas en los criterios de éxito de WCAG 2.2, que constituyen la columna vertebral técnica de la European Accessibility Act y de la ADA aplicada a la web. Si quieres el detalle práctico, nuestra guía de pruebas con lectores de pantalla recorre paso a paso cómo verificar cada uno de estos comportamientos con herramientas reales.

Por qué «a mí se me lee bien» es engañoso

Un desarrollador vidente puede activar una función de lectura en voz alta, oír frases limpias y concluir que la página es accesible. La trampa es que la lectura en voz alta reproduce el orden de lectura visible y el texto visible, ambos cosas que ya tienen sentido para quien mira la pantalla. No te dice nada sobre si un desplegable personalizado anuncia sus opciones, si el foco queda atrapado dentro de un diálogo abierto, si un botón compuesto solo por un icono tiene nombre o si el orden de tabulación coincide con la disposición visual. Esas son precisamente las cosas que fallan para los usuarios de lectores de pantalla y precisamente las cosas que una demostración de lectura en voz alta no puede revelar. La única forma de saberlo es probar como lo hacen los usuarios reales.

Cómo probar para ambos, y por qué la automatización por sí sola no basta

No puedes confirmar que una página funciona para los usuarios de lectores de pantalla escuchando un botón de lectura en voz alta. Lo confirmas comprobando la estructura, los nombres, los roles, los estados, el manejo por teclado y la experiencia real con lector de pantalla en varias herramientas y plataformas.

Un proceso sólido combina tres capas:

Escaneo automatizado para detectar los problemas de gran volumen y detectables por máquina: texto alternativo ausente, etiquetas vacías, referencias ARIA rotas, fallos de contraste. Nuestro software de escaneo de accesibilidad y un escaneo de accesibilidad gratuito son una forma rápida de establecer un punto de partida.
Pruebas manuales por expertos para evaluar todo lo que la automatización no puede juzgar: si un nombre es significativo, si el orden del foco tiene sentido, si un widget personalizado es genuinamente operable. El razonamiento detrás de esta capa se aborda en nuestra guía de auditorías manuales de accesibilidad.
Pruebas con tecnología de asistencia real y usuarios reales. Nada sustituye al manejo de la página con NVDA, JAWS, VoiceOver y TalkBack, y, lo ideal, a la observación de personas que usan estas herramientas a diario. Nuestras auditorías realizadas por personas con discapacidad aportan exactamente esa experiencia vivida.

Las herramientas automatizadas suelen detectar solo una parte de los criterios de éxito de WCAG 2.2; el resto requiere criterio humano. Tratar un escaneo automatizado superado como prueba de accesibilidad es el mismo tipo de error que tratar un widget de lectura en voz alta como soporte de lector de pantalla.

Dónde encaja QualiBooth

QualiBooth pone a prueba tu sitio web frente a los casos de uso tanto de TTS como de lector de pantalla, para que tu contenido sea accesible a los usuarios que dependen de cualquiera de las dos tecnologías, y para que las personas que dependen de un lector de pantalla no solo puedan oír tu contenido, sino operar realmente tu producto. Nuestro kit de herramientas de accesibilidad y la plataforma Agora combinan el escaneo con una revisión manual estructurada, y nuestro equipo de consultoría de accesibilidad te ayuda a remediar lo que las pruebas descubren y a cumplir los requisitos de WCAG 2.2, la EAA y la ADA.

La conclusión es sencilla. Dar voz a tu contenido es un detalle agradable. Hacer que tu contenido sea navegable, operable y se anuncie correctamente a un lector de pantalla es accesibilidad, y solo una de esas cosas satisface a la ley y a las personas a quienes protege.