Descripción de la imagen: un smartphone apoyado en un escritorio de madera que muestra una interfaz de chat de IA con auriculares conectados — el marcador visual del diseño de prompts de IA adaptado a los lectores de pantalla.

Tiempo de lectura: 9 minutos

En los últimos dieciocho meses ha cristalizado dentro de la comunidad de accesibilidad una nueva disciplina de diseño que todavía no tiene un nombre establecido. Algunos equipos la llaman «ingeniería de prompts adaptada a la tecnología de apoyo»; otros la denominan «prompts de sistema con forma de lector de pantalla»; los profesionales que provienen del diseño de interfaces de voz tienden a llamarla «la capa de salida de voz de un LLM». Sea cual sea la etiqueta, el oficio es el mismo: redactar prompts de sistema y reglas de conformación de la salida que hagan útiles a los asistentes de IA generativa —ChatGPT, Claude, Gemini, Copilot, Be My AI— para las aproximadamente aprox. 253 millones de personas en todo el mundo que acceden a esos productos a través de un lector de pantalla.

El problema es concreto y el modo de fallo es ruidoso. Un LLM entrenado con la web pública produce, por defecto, prosa decorada con guiones largos, listas de marcadores anidadas, bloques de código, encabezados que existen solo porque el modelo consideró que la respuesta era «estructurada» y emojis decorativos. Leído en voz alta por NVDA, JAWS, VoiceOver o TalkBack, esa salida se convierte en un flujo de interjecciones «guion guion», una enumeración «viñeta viñeta viñeta» sin ninguna noción de dónde termina un elemento, anuncios de «encabezado nivel dos» que interrumpen una frase y cadenas de nombres de emojis («cara sonriente con gafas de sol») entre cada dos cláusulas. La información está ahí. El usuario no puede extraerla sin rebobinar tres veces. Este artículo es una introducción a lo que la disciplina exige a los constructores de modelos, a lo que los productos han distribuido hasta ahora y a los problemas abiertos de experiencia de usuario que nadie ha resuelto todavía.

La nueva disciplina — en qué consiste realmente

El diseño de prompts adaptado a los lectores de pantalla no es una sola regla. Es un pequeño conjunto de restricciones que, juntas, producen una salida que un sintetizador puede pronunciar de forma inteligible y por la que una tecla de navegación de lector de pantalla puede desplazarse. Las restricciones se agrupan en cuatro categorías.

Respuestas concisas con estructura semántica. La salida predeterminada de los LLM es demasiado larga para la entrega hablada: una respuesta de 600 palabras que se lee bien en el navegador de un usuario vidente se convierte en un monólogo de cuatro minutos por el que el usuario del lector de pantalla no tiene forma de avanzar. La disciplina pide respuestas más cortas, pero, más importante aún, respuestas cortas estructuradas: un resumen de apertura de una sola frase en el que el usuario puede detenerse, seguido de una estructura por la que el lector de pantalla puede navegar mediante encabezados o elementos de lista.

Evitar los guiones largos y otros signos de puntuación que los sintetizadores pronuncian mal. El guion largo, el guion corto, el paréntesis, la barra como conjunción, el separador ASCII — todos estos se leen en voz alta como silencio, un literal «guion» o una pausa confusa que parte una cláusula por la mitad. La convención que está emergiendo en los principales modelos es: preferir la coma y el punto; usar los dos puntos para el único lugar en el que realmente los merecen; nunca usar guiones largos en respuestas de contexto hablado; nunca usar separadores ASCII para dividir secciones.

Declarar qué es una lista, qué es un encabezado, qué es código. El habla sintetizada no tiene jerarquía visual. Un encabezado debe anunciarse como «encabezado», una lista debe anunciarse como «lista con N elementos, elemento uno», el código debe anunciarse como «código», y el modelo debe producir bien estructuras que el lector de pantalla reconozca (HTML, markdown correcto que la superficie de representación convierte en ARIA) o bien narrar verbalmente la propia estructura («Aquí hay tres opciones. Opción uno: …»).

Prohibición del markdown no procesado. El markdown es adecuado cuando la superficie de representación lo convierte en HTML semántico. El markdown es hostil cuando la superficie muestra los asteriscos y guiones bajos en bruto, porque el lector de pantalla anuncia entonces «asterisco asterisco» antes de cada palabra en negrita. La disciplina consiste en detectar el contexto de representación —interfaz de chat con representación markdown frente a terminal frente a interfaz de voz guiada por lector de pantalla— y conformar la salida en consecuencia. El mismo modelo necesita producir representaciones de superficie distintas de la misma respuesta.

Lo que los lectores de pantalla necesitan realmente de la IA

Para concretar las restricciones anteriores, es útil observar el comportamiento real de las cuatro combinaciones de lector de pantalla y sistema operativo que dominan el campo: JAWS en Windows, NVDA en Windows, VoiceOver en macOS e iOS, y TalkBack en Android. No son intercambiables, y un prompt que produce una salida excelente para uno puede ser ilegible en otro.

Navegación por encabezados. Los cuatro lectores exponen una tecla de navegación por encabezados (H en JAWS y NVDA, el Rotor en VoiceOver, el control de lectura en TalkBack). Para que una respuesta larga de IA sea navegable, el modelo debe emitir encabezados semánticos reales: bien mediante un pipeline de representación de markdown que convierta en <h2>/<h3> con el nivel correcto de anidamiento, bien a través de la propia API de respuesta estructurada de la superficie de chat. Un modelo que «estructura» su respuesta poniendo en negrita las tres primeras palabras de cada párrafo ha producido algo que parece estructurado visualmente y es completamente plano para un lector de pantalla.

Navegación por listas. Las listas son útiles en la salida hablada precisamente porque el lector de pantalla anuncia el recuento («lista con siete elementos») y permite al usuario avanzar con la tecla de navegación de elementos de lista (I en NVDA, L en JAWS). Pero esto solo funciona si la lista es un <ul> o <ol> real. Una «lista» producida emitiendo caracteres de viñeta al principio de cada línea, sin contenedor de lista, se lee como prosa ordinaria con una interjección inexplicable de «círculo negro» o «viñeta» en cada línea.

Saltar por secciones. Las respuestas largas de IA —explicaciones, comparaciones, código con comentarios, instrucciones de varios pasos— necesitan una forma de que el usuario del lector de pantalla salte a la sección que le interesa sin escuchar el preámbulo. Este es el aspecto más difícil de diseñar bien, porque el modelo tiene que producir una estructura navegable y la superficie de chat tiene que representarla de forma que el sistema operativo la exponga a la tecnología de apoyo, y el lector de pantalla tiene que estar configurado para usar la tecla de navegación por encabezados en esa superficie. Los tres factores fallan en la práctica; habitualmente es el del medio.

Indicaciones de pronunciación. Las voces sintéticas tropiezan con términos técnicos, acrónimos con letras mixtas, URL, identificadores de código, notación matemática y nombres no ingleses. Un modelo bien diseñado, en las respuestas de contexto de lector de pantalla, deletreará los acrónimos en su primera aparición («WCAG, las Pautas de Accesibilidad para el Contenido Web»), expandirá los inicialísmos que el sintetizador no puede pronunciar y evitará incrustar URL en bruto en el flujo de prosa, donde el sintetizador leerá las barras en voz alta. En 2026, ninguno de los principales productos hace esto de forma coherente.

Cómo lo están gestionando los productos

A mediados de 2026, los principales productos de IA generativa han adoptado posiciones visiblemente diferentes respecto a la salida adaptada a los lectores de pantalla. Ninguno lo ha logrado plenamente. La evolución es más rápida que hace doce meses, pero la brecha entre el mejor y el peor sigue siendo amplia.

ChatGPT (OpenAI). El cliente web incorpora ahora un interruptor de «modo conciso» que acorta las respuestas predeterminadas y reduce la decoración con markdown. El modo de voz introducido en 2024 —y mejorado sustancialmente en 2025— es lo más parecido que ha ofrecido ningún producto importante a una interfaz nativa de lector de pantalla, porque omite el chat visual por completo y entrega una respuesta hablada con un gesto de parar, reproducir y «repite eso». El campo de instrucciones personalizadas permite a los usuarios de lectores de pantalla declarar sus preferencias una vez y aplicarlas en todas las sesiones, que es la solución de usuario que la comunidad ha adoptado. Los puntos pendientes: los modelos GPT siguen produciendo por defecto prosa con abundantes guiones largos a menos que se les indique lo contrario, y el nivel de encabezado emitido en markdown no siempre se corresponde limpiamente con ARIA en la superficie de chat.

Claude (Anthropic). La disciplina de prompts de sistema de Claude es la que más se ha acercado a las convenciones descritas anteriormente. El modelo es notablemente menos propenso a los guiones largos que la línea GPT en 2026, produce por defecto respuestas más cortas y responde bien a instrucciones de prompt de sistema como «estás hablando con un usuario de lector de pantalla; no uses guiones largos, prefiere párrafos cortos y usa encabezados reales o listas numeradas cuando se necesite estructura». La superficie de chat de Claude.ai representa el markdown en HTML semántico con niveles de encabezado correctos, lo que hace que la tecla de navegación por encabezados funcione. La salida de voz a través de integraciones de terceros existe pero está menos desarrollada que el modo de voz propio de ChatGPT.

Gemini (Google). La estrecha integración con TalkBack en Android es la ventaja estructural de Gemini; el modelo puede transferir el control al lector de pantalla a nivel de sistema operativo a través de los servicios de accesibilidad de Android de una forma que los competidores en iOS y web no pueden. El flujo «Ok Google, pregúntale a Gemini…» en dispositivos Android accesibles es, para algunos usuarios, la experiencia de IA más natural disponible junto a un lector de pantalla. Los puntos pendientes: la interfaz web sigue sobre-decorando las respuestas, la jerarquía de encabezados en las respuestas web de Gemini es inconsistente, y el modelo es más propenso a producir emojis decorativos que sus competidores.

Be My AI (Be My Eyes + OpenAI). Este es el más limitado en alcance de los cuatro —un asistente de descripción visual que utiliza modelos de visión de clase GPT-4 para describir imágenes y entornos a usuarios ciegos y con baja visión—. Es también el único producto de esta lista diseñado desde el primer día para un usuario de lector de pantalla como audiencia principal. El diseño de prompts de Be My AI es la demostración más clara del campo sobre cómo es la salida adaptada a la tecnología de apoyo en la práctica: las descripciones se abren con un resumen de una frase en el que el usuario puede detenerse, continúan con detalles estructurados solo si se solicitan, y evitan el lenguaje espacial («a la izquierda», «arriba») que requiere contexto visual para interpretarse. En 2026, el producto sigue siendo lo más parecido que tiene el campo a una implementación de referencia.

La observación transversal es que los cuatro productos han avanzado en las partes fáciles —respuestas más cortas, menos guiones largos, un campo de instrucciones personalizadas— y apenas han empezado con las partes difíciles. Las partes difíciles se detallan a continuación.

Problemas abiertos de experiencia de usuario que nadie ha resuelto

La literatura sobre diseño de prompts adaptado a los lectores de pantalla converge en cuatro problemas abiertos de experiencia de usuario en los que la respuesta correcta aún no se conoce. Ninguno de ellos es un problema de capacidad del modelo; todos son problemas de diseño de interacción que se sitúan entre el LLM, la superficie de chat, el sistema operativo y el lector de pantalla.

Capacidad de interrumpir. Un usuario vidente puede recorrer visualmente una respuesta de LLM en aprox. dos segundos y decidir si la lee. Un usuario de lector de pantalla no puede. Si la respuesta es incorrecta o no pertinente, el usuario tiene que escuchar suficiente parte de ella para saberlo y luego interrumpir. Los modos de voz tienen un botón de parar. Los modos de texto generalmente no: la respuesta llega en flujo continuo y el lector de pantalla la anuncia como nuevo contenido a medida que llega, y el usuario no tiene una forma limpia de decir «deja de generar, esto no es lo que pedí». La aplicación Be My AI lo gestiona mejor; los clientes de chat web, peor.

Repetir la última respuesta con granularidad seleccionable. Pedir a un lector de pantalla que relea la última respuesta es sencillo si la respuesta es corta. Es inutilizable si la respuesta tiene seis párrafos y el usuario solo quiere escuchar de nuevo el tercer párrafo. La interacción que la comunidad solicita es «repite el último elemento de la lista», «repite la última sección de encabezado», «repite el último bloque de código». Eso requiere que la superficie de chat exponga la estructura al lector de pantalla de forma que los propios comandos de relectura del lector de pantalla puedan direccionarla. En 2026, ninguno de los principales productos lo hace; el usuario tiene que usar la propia navegación línea a línea del lector de pantalla, lo que resulta laborioso.

Navegación por secciones en la salida hablada. Los modos de voz no tienen una tecla de navegación por encabezados. El usuario escucha una respuesta de cuatro minutos de forma lineal, sin posibilidad de saltar de la sección de «resumen» a la de «detalles» sin rebobinar en el tiempo. Los diseños de interacción que se están prototipando —una «lista de secciones» hablada por la que el usuario puede navegar con las teclas de cursor, un comando de voz «ir a la sección tres», un modo «dame solo los encabezados»— son incipientes. La función de seguimiento «más detalles sobre los colores» de la aplicación Be My AI es la versión funcional más cercana en un producto distribuido.

La pregunta de la transferencia a la tecnología de apoyo: ¿cuándo habla la IA frente a cuándo lee el contenido en voz alta? Esta es la pregunta de diseño más profunda. Si un usuario de lector de pantalla abre un asistente de IA en una página web, ¿quién habla: la propia voz de la IA (capa TTS), o el lector de pantalla instalado del usuario leyendo la salida de texto de la IA? Los dos sistemas de voz tienen configuraciones diferentes, velocidades de habla diferentes, indicaciones de pronunciación diferentes y gestos de parar y reproducir diferentes. Dos sistemas intentando hablar el mismo contenido al mismo tiempo no produce nada utilizable. La convención que está emergiendo es: las interacciones en modo de voz usan el propio TTS de la IA y suprimen explícitamente el lector de pantalla; las interacciones en modo de texto emiten HTML semántico y dejan que el lector de pantalla hable. Pero el límite entre los dos modos no siempre es nítido —la descripción de imágenes, la generación de código, la notación matemática y las respuestas multimodales se sitúan incómodamente entre voz y texto—, y ese límite es donde viven la mayoría de los problemas activos de experiencia de usuario.

Hacia dónde se dirige

La disciplina está aproximadamente donde estaba la accesibilidad web en aprox. 2002: superada la fase de «¿es esto un problema real?», superada la fase de «¿quién es el responsable?», en la fase de «¿cuáles son las reglas concretas?». Es probable que sucedan tres cosas a lo largo de 2026 y 2027.

Primero, los constructores de modelos codificarán sus prompts internos para lectores de pantalla y los publicarán, de la misma manera que Anthropic publica los prompts de sistema de Claude en declaraciones de accesibilidad al estilo VPAT y que OpenAI ha empezado a documentar los valores predeterminados de comportamiento de GPT. La comunidad solicita el equivalente a una ficha de modelo: una «ficha de salida para lectores de pantalla» que nombre las convenciones que un modelo determinado ha sido entrenado o se le ha indicado por prompt de sistema que siga.

Segundo, las superficies de chat —clientes web, aplicaciones móviles, integraciones en IDE— obtendrán pipelines de representación de HTML semántico correctos y una exposición ARIA adecuada para el historial del chat, con las teclas de navegación asignadas al lector de pantalla a nivel del sistema operativo. Este es un trabajo sin glamour, y es el trabajo que más mejorará la situación de los usuarios diarios.

Tercero, los propios proveedores de lectores de pantalla —Vispero (JAWS), NV Access (NVDA), Apple (VoiceOver), Google (TalkBack)— empezarán a distribuir funciones adaptadas a la IA: navegación nativa por encabezados dentro de las superficies de chat de IA, un gesto estandarizado de «dejar de generar», comandos de relectura más inteligentes que conozcan la estructura de las respuestas de LLM. El ecosistema de complementos de código abierto de NVDA ya está produciendo versiones tempranas de estos. Los lectores propietarios son más lentos, pero la dirección es la misma.

La observación de fondo es que el diseño de prompts adaptado a los lectores de pantalla ha dejado de ser una preocupación de nicho de un puñado de desarrolladores ciegos y se ha convertido en una expectativa básica de cualquier equipo de producto de IA que quiera distribuir en mercados regulados. El European Accessibility Act (EAA) se aplica a los «terminales de autoservicio interactivos» y a los «equipos terminales de consumo con capacidad informática interactiva», una categoría que casi con toda seguridad captura a los principales asistentes de IA en un teléfono. La capa de salida adaptada a la tecnología de apoyo ya no es una función opcional: es vinculante a efectos de contratación pública. Los equipos que descifren las reglas ahora distribuirán los productos que sobrevivan a partir del 28 de junio de 2025. Los equipos que lo traten como una reflexión tardía serán el próximo lote de casos de aplicación del EAA.

Reflexiones finales

El oficio es pequeño, los riesgos son grandes y las reglas siguen escribiéndose. Si se desarrolla con LLMs y todavía no se ha mantenido una conversación con un usuario de lector de pantalla sobre cómo suena el producto cuando lo usa, eso es lo que corresponde hacer a continuación. La mayor parte de lo que está mal con la IA para los usuarios de lectores de pantalla en 2026 no es un problema de capacidad del modelo; es un problema de diseño de prompts y de superficie que cualquier equipo de producto puede resolver en un sprint, si decide hacerlo.

La comunidad ha sido generosa con su tiempo, sus pruebas y su paciencia. También está perdiendo la paciencia más rápido que antes, porque los productos son ahora de uso generalizado y la excusa de «todavía lo estamos resolviendo» ha dejado de ser válida. La disciplina está aquí. Las convenciones están convergiendo. Los próximos dieciocho meses distinguirán a los equipos que escucharon de los que no lo hicieron.