Screen Reader: qué es, tipos de lectores de pantalla y principio de funcionamiento

¿Qué es un Screen Reader?

Screen Reader (lector de pantalla) es una tecnología de asistencia (Assistive Technology, AT) que interpreta la interfaz gráfica de usuario y la presenta en forma no visual: mediante voz sintetizada o una pantalla Braille táctil. Los lectores de pantalla son el principal medio de acceso a computadoras y dispositivos móviles para personas con pérdida total o parcial de la visión.

Los primeros lectores de pantalla aparecieron a finales de la década de 1980 para MS-DOS (por ejemplo, Vocal-Eyes) y posteriormente para Windows (JAWS, NVDA). En plataformas móviles, los lectores de pantalla se integraron a nivel de sistema: Apple incorporó VoiceOver en el iPhone 3GS en 2009, Google incorporó TalkBack en Android 1.6 ese mismo año. Para 2025, prácticamente todos los smartphones modernos tienen un lector de pantalla integrado que no requiere instalación de software adicional.

Un lector de pantalla no solo lee texto de la pantalla: analiza la jerarquía de la interfaz, determina los tipos de elementos (botón, enlace, encabezado, campo de entrada), sus estados (activado/desactivado, seleccionado/no seleccionado) y relaciones (padre-hijo, grupo). Esta información se transmite al usuario mediante indicaciones de voz o sensaciones táctiles de una pantalla Braille, que actualiza las celdas en tiempo real según la posición del foco.

¿Cómo funciona un Screen Reader?

Un lector de pantalla trabaja en estrecha colaboración con el sistema operativo, obteniendo acceso a su representación interna de la interfaz: el árbol de accesibilidad (Accessibility Tree). Este mecanismo es el mismo en iOS y Android, aunque los nombres de las API difieren.

Conversión de texto a voz (TTS)

El canal de salida principal de un lector de pantalla es un sintetizador de voz (Text-To-Speech, TTS). Cuando el foco de accesibilidad se posiciona sobre un elemento, el lector de pantalla extrae su contenido textual (o la descripción proporcionada por el desarrollador) y lo envía al motor TTS. Los motores TTS modernos, como Apple Speech Synthesis y Google Text-to-Speech, utilizan redes neuronales para generar voz natural con entonación, pausas y énfasis correctos según la puntuación y el tipo de contenido.

El usuario puede ajustar la velocidad del habla (generalmente 60–80% del máximo para una percepción cómoda), el tono y el volumen. Algunos lectores de pantalla admiten varias voces y cambian entre ellas según el tipo de contenido, por ejemplo, una voz más lenta para leer texto y una más rápida para la navegación por la interfaz. Las pantallas Braille se conectan mediante Bluetooth y muestran hasta 40–80 caracteres a la vez, actualizando la línea con cada cambio de foco.

Gestión del foco y navegación

Un lector de pantalla utiliza el concepto de Foco de Accesibilidad (Accessibility Focus), que difiere del foco de entrada estándar. El usuario mueve el foco de accesibilidad mediante gestos (toque, deslizamiento), y el lector de pantalla anuncia el elemento bajo el foco. El orden de navegación por defecto sigue el orden visual: de izquierda a derecha, de arriba abajo. El desarrollador puede redefinir este orden para diseños complejos.

El lector de pantalla también admite varios modos de navegación que el usuario cambia mediante el rotor (VoiceOver) o el menú (TalkBack): por encabezados, enlaces, caracteres, palabras, formularios. En el modo de encabezados, el lector de pantalla se mueve solo entre H1–H6, lo que es fundamental para una navegación eficiente por páginas y documentos largos. El modo de caracteres ayuda al introducir códigos de confirmación o contraseñas complejas, pronunciando cada carácter individualmente.

Principales lectores de pantalla para plataformas móviles

Dos lectores de pantalla dominan las plataformas móviles: VoiceOver en iOS y TalkBack en Android. Tienen diferentes API, gestos y capacidades, pero el principio común es la lectura del árbol de accesibilidad y el control por gestos.

VoiceOver (iOS)

VoiceOver es el lector de pantalla de Apple, integrado en iOS, iPadOS y macOS. Utiliza la API UIAccessibility para obtener información sobre los elementos y admite el rotor para cambiar los modos de navegación. VoiceOver está integrado con iCloud (la configuración se sincroniza entre dispositivos), Apple Pay (confirmación de pago mediante Touch ID o Face ID) y Texto Dinámico (la fuente se adapta a la configuración del usuario).

Los gestos de VoiceOver difieren de los de TalkBack: utiliza la rotación con dos dedos (rotor), triple toque para Screen Curtain y doble toque con dos dedos para cancelar una acción. VoiceOver admite rotores personalizados que el desarrollador añade mediante UIAccessibilityCustomRotor, por ejemplo, para una navegación rápida por las secciones de la aplicación sin seguir el orden estándar.

TalkBack (Android)

TalkBack es el lector de pantalla de Google, parte de Android Accessibility Suite. Utiliza AccessibilityService y AccessibilityNodeInfo para acceder a la interfaz. TalkBack admite un menú global mediante deslizamiento en forma de L, acciones personalizadas para elementos y LiveRegion para actualizaciones dinámicas. A partir de Android 14, TalkBack incorporó soporte para gestos con una sola mano y una mejor integración con Google Assistant.

TalkBack tiene un sistema de gestos más flexible que VoiceOver: el usuario puede asignar prácticamente cualquier gesto a cualquier acción. TalkBack también admite entrada Braille en pantalla (BrailleBack): el usuario introduce texto con caracteres Braille directamente en la pantalla táctil en una disposición especial de 3×2 por dedo, lo que acelera significativamente la escritura en comparación con el teclado en pantalla.

Además de VoiceOver y TalkBack, existen lectores de pantalla móviles menos comunes: Select to Speak (Android, vocaliza el área seleccionada), Samsung Voice Assistant (reemplaza TalkBack en dispositivos Samsung con One UI) y soluciones de terceros para nichos específicos, como para usuarios de smartphones chinos sin servicios de Google.

Cómo interactúa un Screen Reader con la aplicación

Un lector de pantalla no tiene acceso directo a los componentes de la interfaz de la aplicación. En su lugar, funciona a través de una capa: la API de accesibilidad del sistema operativo. El sistema operativo construye un árbol de accesibilidad (Accessibility Tree) que el lector de pantalla recorre y analiza.

Árbol de accesibilidad en iOS y Android

En iOS, el árbol de accesibilidad se construye a partir de objetos UIAccessibilityElement correspondientes a cada vista en pantalla. Cada elemento contiene una etiqueta (texto principal), traits (tipo de elemento: botón, encabezado, enlace), hint (información sobre herramientas), value (valor actual para controles deslizantes e indicadores) y frame (área táctil). El sistema crea automáticamente elementos para los componentes de interfaz estándar, pero el desarrollador puede añadirlos y personalizarlos.

En Android, el árbol de accesibilidad se construye a partir de objetos AccessibilityNodeInfo. Cada nodo contiene: text (texto o contentDescription), className (tipo de elemento), contentDescription (descripción), stateDescription (estado), isEnabled, isChecked, isClickable y otros indicadores. Android también admite AccessibilityAction: una lista de acciones que el lector de pantalla puede realizar en nombre del usuario: clic, pulsación larga, desplazamiento, establecer foco, establecer texto.

Eventos de accesibilidad

Cuando se produce un cambio en la interfaz (aparece un nuevo elemento, cambia el texto, un elemento se vuelve visible o invisible), el sistema operativo envía un AccessibilityEvent. El lector de pantalla se suscribe a estos eventos y reacciona a ellos: por ejemplo, cuando aparece un cuadro de diálogo, el lector de pantalla mueve automáticamente el foco a su título y anuncia el contenido.

// Escucha de eventos de accesibilidad en Android
class CustomAccessibilityService : AccessibilityService() {
    override fun onAccessibilityEvent(event: AccessibilityEvent?) {
        event ?: return
        when (event.eventType) {
            TYPE_VIEW_CLICKED ->
                handleClick(event)
            TYPE_WINDOW_STATE_CHANGED ->
                handleWindowChange(event)
            TYPE_VIEW_TEXT_CHANGED ->
                handleTextChange(event)
        }
    }
}

En iOS, los eventos similares se gestionan mediante UIAccessibility.Notification: layoutChanged (cambió el diseño), screenChanged (pantalla completamente nueva), announcement (anuncio personalizado), pageScrolled (desplazamiento de página). El desarrollador envía estos eventos a través de UIAccessibility.post para que el lector de pantalla responda correctamente a los cambios. Por ejemplo, al abrir una ventana modal, es necesario enviar screenChanged con el nuevo título; de lo contrario, VoiceOver permanece en el elemento anterior debajo de la ventana.

Desarrollo de aplicaciones para Screen Reader

Crear una aplicación accesible no consiste en añadir contentDescription a cada elemento, sino en diseñar la experiencia de usuario para la interacción no visual. Las reglas básicas son las mismas para ambas plataformas, aunque la implementación varía.

Reglas básicas de accesibilidad

Todos los elementos interactivos deben tener una descripción significativa: un botón “Enviar” debe describirse como “Enviar mensaje”, no solo “Botón”. Los elementos decorativos (separadores, imágenes de fondo, iconos no funcionales) deben ocultarse al lector de pantalla. El orden de navegación debe seguir el flujo lógico de la pantalla, no la disposición visual. El contraste del texto debe ser de al menos 4.5:1 para texto normal y 3:1 para texto grande (WCAG AA).

// iOS: configuración correcta para un elemento complejo
let customControl = UIControl()
customControl.isAccessibilityElement = true
customControl.accessibilityLabel = "Volumen de sonido"
customControl.accessibilityValue = "75 por ciento"
customControl.accessibilityTraits = [
    .adjustable,
    .button
]
customControl.accessibilityHint =
    "Aumenta o disminuye el volumen"

// Actualización al cambiar el valor
func didChangeVolume(newValue: Float) {
    customControl.accessibilityValue =
        "\(Int(newValue)) por ciento"
    UIAccessibility.post(
        notification: .layoutChanged,
        argument: customControl
    )
}

En iOS, el indicador isAccessibilityElement activa el soporte de VoiceOver para elementos personalizados. La combinación de traits (.adjustable + .button) indica a VoiceOver que el elemento se puede ajustar deslizando hacia arriba/abajo y activar con doble toque. Después de cambiar el valor, se debe enviar una notificación layoutChanged; de lo contrario, VoiceOver seguirá anunciando el valor anterior.

Recomendaciones específicas para cada plataforma

Para iOS: use accessibilityElements para redefinir el orden de lectura, accessibilityCustomActions para acciones adicionales en el menú contextual y shouldGroupAccessibilityChildren para agrupar elementos en grupos lógicos. Para SwiftUI, use los modificadores .accessibilityLabel(), .accessibilityAddTraits() y .accessibilityRespondsToUserInteraction(). Evite establecer isAccessibilityElement = false en contenedores que contengan elementos secundarios interactivos; esto los ocultará de VoiceOver.

Para Android: use accessibilityTraversalBefore y accessibilityTraversalAfter para el orden de navegación, AccessibilityDelegate para elementos personalizados y LiveRegion (polite/assertive) para actualizaciones dinámicas. En Compose, use el modificador .semantics {} con contentDescription, stateDescription y customActions. Evite establecer focusable = true en elementos no interactivos; esto crea falsos puntos de foco para TalkBack y confunde al usuario.

Herramientas de prueba

Las pruebas con un lector de pantalla deben realizarse en un dispositivo físico. Un emulador/simulador proporciona una comprensión básica, pero los gestos y la velocidad de respuesta difieren. Use Accessibility Inspector (Xcode) para iOS y Accessibility Scanner (Android) para la detección automática de problemas.

Escenarios clave de prueba: registro (rellenar un formulario, validación, envío), búsqueda y navegación por catálogo, proceso de pago, recuperación de contraseña. Cada escenario debe poder completarse sin control visual, solo mediante las indicaciones de voz del lector de pantalla. Si un usuario de lector de pantalla no puede completar un escenario en el mismo tiempo que un usuario habitual (±50%), la aplicación necesita mejoras de accesibilidad.