Braillito con lector de pantalla: VoiceOver y TalkBack
Braillito está construido para usarse con VoiceOver en iOS y TalkBack en Android, y ese trabajo está en el código: cada celda braille se anuncia punto por punto, cada mecánica de juego tiene una explicación hablada previa y hay tests automáticos que lo comprueban. Lo que no tenemos es una auditoría externa que lo certifique.
Este artículo separa esas dos cosas a propósito. Primero, qué es un lector de pantalla y cómo se maneja, con los gestos verificados en la documentación de Apple y de Google. Después, qué hay exactamente en nuestro código, con nombres de archivo. Y al final, una sección entera dedicada a lo que no podemos afirmar.
Puntos clave
- Un lector de pantalla no es un modo de la app: es un programa del sistema. VoiceOver y TalkBack vienen instalados en iOS y Android, y son ellos los que hablan. La app solo pone las etiquetas que el lector lee.
- Braillito no tiene una «versión accesible» aparte. Es la misma aplicación, el mismo curso y los mismos ejercicios, con la interfaz adaptada cuando hay un lector de pantalla en marcha.
- La web y las apps nativas resuelven eso de dos maneras distintas. La web lo pregunta, porque un navegador no puede detectarlo; las apps de iOS y Android lo detectan a través del sistema operativo.
- En el código de la web hay cinco módulos de accesibilidad y cinco archivos de tests que comprueban qué se anuncia. Puedes ver los nombres más abajo; no son una promesa, son archivos.
- No hay auditoría externa, no hay nivel WCAG declarado y no hay soporte de línea braille. Nuestra declaración de accesibilidad lo dice con las mismas palabras, y esa página es la fuente, no esta.
Aviso sobre el alcance de este artículo
Este artículo lo escribe el equipo de Braillito y describe su propio producto. Eso no lo invalida, pero cambia cómo hay que leerlo, así que conviene decir de dónde sale cada afirmación.
Las afirmaciones sobre el código son verificables: dan el nombre del archivo y la función, y cualquiera con el repositorio delante puede comprobarlas. Las afirmaciones sobre gestos de VoiceOver y TalkBack salen de la documentación oficial de Apple y de Google, enlazada en cada caso.
Lo que este artículo no contiene es un informe de pruebas con dispositivo real. No decimos «funciona perfectamente con lector de pantalla», porque esa frase, escrita por quien hizo la app y sin una prueba independiente detrás, no vale nada. Si has probado muchas apps que prometían accesibilidad y no la tenían, ya sabes por qué.
Qué es un lector de pantalla
Un lector de pantalla es un programa del sistema operativo que convierte en voz —o en braille, si hay una línea braille conectada— lo que aparece en la pantalla, y que sustituye el manejo táctil normal por un conjunto de gestos propios. No es una función de la aplicación: es una capa que está por encima de todas las aplicaciones.
Los dos que importan en móvil vienen preinstalados y son gratuitos:
| Lector | Sistema | Fabricante | Coste |
|---|---|---|---|
| VoiceOver | iOS, iPadOS, macOS | Apple | Incluido en el sistema |
| TalkBack | Android | Incluido en el sistema |
En ordenador de escritorio los más usados son NVDA y JAWS en Windows, Orca en Linux y VoiceOver en macOS. La versión web de Braillito se abre en el navegador, así que en escritorio es el lector del sistema el que la lee.
La consecuencia práctica para quien desarrolla es la que casi nunca se explica: el lector de pantalla no adivina lo que significa un dibujo. Si una celda braille se dibuja con seis círculos y nada más, el lector no dice nada útil, porque no hay nada que decir. Alguien tiene que escribir «puntos 1 y 3 marcados» en el código. Eso es, literalmente, casi todo el trabajo de accesibilidad de una app como esta.
Cómo se activa cada uno
| VoiceOver (iOS) | TalkBack (Android) | |
|---|---|---|
| Por ajustes | Ajustes › Accesibilidad › VoiceOver | Ajustes › Accesibilidad › TalkBack › «Usar TalkBack» |
| Atajo rápido | Triple clic en el botón lateral o de inicio, si está configurada la Función rápida de accesibilidad | Mantener pulsados los dos botones de volumen unos segundos |
| Por voz | Pedirle a Siri «activar VoiceOver» | — |
Fuentes: Activar VoiceOver y practicar gestos en el iPhone (Apple) y Empezar a usar TalkBack (Google).
Apple documenta además una zona llamada Práctica de VoiceOver, dentro de Ajustes › Accesibilidad › VoiceOver, donde se pueden ensayar los gestos «sin que afecte al iPhone o sus ajustes». Si vas a enseñar braille a alguien que acaba de empezar con VoiceOver, ese es el sitio por donde se empieza, antes de abrir ninguna app.
Gestos básicos de VoiceOver
Estos son los gestos que Apple documenta en la guía del usuario del iPhone. Con ellos se maneja cualquier app, Braillito incluida.
| Acción | Gesto |
|---|---|
| Seleccionar el elemento siguiente | Deslizar hacia la derecha |
| Seleccionar el elemento anterior | Deslizar hacia la izquierda |
| Activar el elemento seleccionado | Pulsar dos veces |
| Leer todo desde el principio | Deslizar hacia arriba con dos dedos |
| Leer desde el elemento actual | Deslizar hacia abajo con dos dedos |
| Desplazarse una página | Deslizar con tres dedos, arriba o abajo |
| Volver atrás | Barrido con dos dedos: moverlos de un lado a otro tres veces, dibujando una «z» |
| Cambiar el ajuste del rotor | Girar con dos dedos, como si giraras un dial |
Fuente: Aprender gestos de VoiceOver en el iPhone (Apple).
El rotor es el que más rinde y el que menos se conoce. Girando dos dedos sobre la pantalla se elige una unidad de navegación —encabezados, enlaces, controles de formulario, regiones— y a partir de ahí, deslizando arriba y abajo, se salta de un encabezado al siguiente en lugar de recorrer la pantalla elemento por elemento. En una app con muchas pantallas es la diferencia entre llegar en tres gestos o en cuarenta.
Gestos básicos de TalkBack
Los que Google documenta para TalkBack 9.1 y versiones posteriores:
| Acción | Gesto |
|---|---|
| Ir al elemento siguiente | Deslizar hacia la derecha |
| Ir al elemento anterior | Deslizar hacia la izquierda |
| Seleccionar un elemento | Tocar |
| Activar el elemento seleccionado | Tocar dos veces |
| Desplazarse | Deslizar dos dedos hacia arriba o hacia abajo |
| Abrir el menú de TalkBack | Deslizar hacia abajo y luego hacia la derecha, o tocar con tres dedos |
| Siguiente control de lectura | Deslizar hacia arriba y luego hacia abajo |
| Control de lectura anterior | Deslizar hacia abajo y luego hacia arriba |
Fuente: Usar los gestos de TalkBack (Google).
Los controles de lectura de TalkBack son el equivalente al rotor de VoiceOver: cambian qué unidad se recorre al deslizar —caracteres, palabras, encabezados, controles— y son lo que convierte una pantalla larga en algo navegable.
Qué hay en el código de la versión web
Todo lo de esta sección está en el repositorio de la versión web y se puede comprobar abriendo los archivos. Damos las rutas para que no haya que creernos.
Las celdas braille se anuncian punto por punto
El módulo src/lib/a11yBraille.js construye la etiqueta de cada celda. Una celda que no dice nada se convierte en una frase concreta:
Celda Braille 1 de 3: puntos 1 y 3 marcados
Y cuando el foco cae sobre un punto individual que se puede activar, la etiqueta incluye su posición física dentro de la celda:
Punto 1, arriba izquierda, marcado
Esa segunda parte importa más de lo que parece. «Punto 1» es un número; «arriba izquierda» es dónde está el dedo. Para alguien que está aprendiendo el sistema, la posición es la mitad de la información.
El módulo hace además una cosa menos visible: oculta los puntos individuales del árbol de accesibilidad cuando la celda es estática (aria-hidden="true" sobre cada punto, role="img" sobre la celda). Si no se hiciera, cada letra sería seis paradas del lector en lugar de una, y leer una palabra de cinco letras costaría treinta gestos.
Las etiquetas se rehacen solas cuando la pantalla cambia
En app.js hay un MutationObserver sobre el contenedor de la aplicación que vuelve a etiquetar el árbol braille cada vez que el DOM cambia, con un retardo de 300 ms para no dispararse en cada fotograma, y limitado a la pantalla activa. Es lo que hace que una celda que cambia a mitad de un ejercicio no se quede con la etiqueta antigua, que es el fallo más habitual y más difícil de detectar mirando la pantalla.
Los 16 minijuegos anuncian lo que pasa
Braillito tiene 16 mecánicas de juego, una por archivo en src/games/. Los 16 archivos llaman al anunciador de src/lib/announcer.js, que mantiene dos regiones aria-live ocultas: una asertiva, que interrumpe al lector para dar el resultado de una respuesta, y una educada, que espera a que termine de hablar para dar información de progreso.
Sin eso, acertar o fallar sería un cambio de color: información que no llega si no ves la pantalla.
Cada mecánica se explica antes de empezar
src/lib/blindMechanicPrimer.js contiene un texto explicativo para cada una de las 16 mecánicas, que se lee antes de empezar la lección cuando el perfil está marcado como persona ciega. Por ejemplo, para el juego de construir:
A continuación te vas a encontrar con una letra objetivo en la parte superior. Debajo tendrás una celda Braille de 6 puntos. Debes activar los puntos correctos para formar la letra y luego pulsar COMPROBAR.
La razón de que exista es sencilla: quien ve la pantalla entiende la mecánica de un vistazo, y quien no la ve necesita que alguien se la cuente. Sin ese texto, el ejercicio no es más difícil: es un acertijo distinto.
Hay una excepción deliberada, y está en el código: el aviso no se lee en el repaso diario ni en la práctica libre, porque son mecánicas ya conocidas y repetirlo cada día sería ruido.
Los iconos y las barras de progreso dicen qué significan
src/lib/a11yIcons.js convierte los emojis de la interfaz en texto: el rayo pasa a ser «Energía: 3 recargas disponibles», los corazones a «Vidas: 2 de 3», y el emoji en sí se oculta del árbol de accesibilidad para que no se lea dos veces. src/lib/a11yProgress.js hace lo mismo con las barras de progreso: «Barra de progreso: 1 de 10» en lugar de un rectángulo sin nombre.
Cada pantalla es una región con nombre
La aplicación web es de una sola página, y cada pantalla es una sección con role="main" y su propio aria-label —«Bienvenida a Braillito», «Configuración de Accesibilidad», «Traductor»—. Las pantallas inactivas se ocultan con display: none, así que solo la activa está en el árbol de accesibilidad en cada momento. En la práctica eso significa que la navegación por regiones devuelve el nombre de la pantalla en la que estás, y no una lista de cuarenta y seis.
Un informe de lo que se anuncia en cada lección
Esta es la parte menos habitual. scripts/export-voiceover-lessons-report.mjs monta la aplicación entera en un DOM simulado, recorre las 55 lecciones del curso y extrae, control por control, qué texto anunciaría un lector de pantalla en cada pantalla y en cada ronda. El resultado son 2.387 controles y 764 textos distintos, guardados en docs/voiceover_lessons_buttons.md.
Sirve para detectar botones sin etiqueta antes de que lleguen a nadie. Y conviene decir en la misma frase lo que no es: es una simulación sobre el DOM, no una ejecución real de VoiceOver. Comprueba que la etiqueta existe y qué dice. No comprueba que VoiceOver la lea en ese orden, ni que el foco vaya donde debe, ni que un gesto llegue al elemento correcto. Un botón puede tener una etiqueta perfecta y ser inalcanzable.
Los tests de accesibilidad
Cinco archivos de test, ejecutables con npm test:
| Archivo | Qué comprueba exactamente |
|---|---|
tests/a11yBraille.test.js |
Que la etiqueta de una celda diga «puntos 1 y 3 marcados», que incluya la letra solo cuando toca, y que dos grupos de celdas en la misma pantalla no mezclen sus conteos («1 de 3» y «1 de 5» a la vez) |
tests/a11yIcons.test.js |
Que los indicadores de energía y vidas expongan role="img", sean alcanzables con el foco y digan «recargas infinitas» o «3 vidas disponibles» |
tests/a11yProgress.test.js |
Que la barra de progreso se etiquete «Barra de progreso: 1 de 10», y que caiga a una etiqueta base cuando no hay datos |
tests/blindMechanicPrimer.test.js |
Que el aviso hablado se active con el perfil de persona ciega, que no se active en el repaso diario ni en la práctica, y que cada mecánica reciba su texto |
tests/voiceoverLessonsReport.test.js |
Que el informe cubra todas las lecciones del curso, en orden, que ninguna se quede sin controles y que el resultado sea reproducible |
Son 20 tests sobre 70 del total del proyecto. Lo que comprueban es real y lo que no comprueban también: son tests sobre el DOM, no sobre un lector de pantalla. Ninguno de ellos ejecuta VoiceOver ni TalkBack. Verifican que el texto que un lector leería es el correcto; no verifican la experiencia de usarlo.
En la web se pregunta; en iOS y Android se detecta
Aquí hay una diferencia real entre las dos versiones, y la contamos porque no aparece en ningún otro sitio de nuestra web.
En la versión web, Braillito lo pregunta. Durante la configuración inicial aparece una pregunta con dos opciones: «Sí, tengo discapacidad visual — Uso lector de pantalla» y «No, puedo ver bien». La respuesta se guarda en el perfil y se puede cambiar después en Ajustes.
Preguntarlo tiene un motivo técnico que merece explicarse, porque de fuera parece una pereza: una página web no puede detectar si hay un lector de pantalla funcionando. Los navegadores no lo exponen, y lo hacen a propósito, porque sería un dato de salud utilizable para identificar y rastrear a alguien. Así que la alternativa a preguntar no es detectarlo: es adivinarlo.
Lo que cambia esa respuesta, en el código de la web:
- Se activa el aviso hablado de cada mecánica antes de empezar la lección.
- Se silencia la narración propia de la app. Braillito tiene su propia voz para quien quiere guía en audio sin usar lector de pantalla; con el perfil de persona ciega marcado, esa voz se apaga. Si no lo hiciera, la app y VoiceOver hablarían encima el uno del otro, que es una de las formas más rápidas de hacer una app inutilizable.
- Se ocultan las mecánicas incompatibles con el perfil marcado.
En las apps de iOS y Android no se pregunta: se detecta. Ahí sí existe la API que falta en el navegador, y las apps nativas la usan para saber si hay un lector de pantalla activo en ese momento y para enterarse si se enciende o se apaga a mitad de sesión. Esas apps tuvieron durante un tiempo la misma pregunta que la web, y se retiró en marzo de 2026.
La consecuencia práctica: en iOS y Android no hay nada que configurar. Si enciendes VoiceOver o TalkBack, la app se entera sola. Conviene decir también que nuestra web habla de esto como si fuera una sola cosa —«el onboarding pregunta si usas lector de pantalla»— y son dos mecanismos distintos. Esta página es la versión detallada.
Qué hay en el código de las apps de iOS y Android
Las apps nativas son otro proyecto, con otra base de código, así que sus datos van aparte.
| Qué | Cuánto |
|---|---|
Etiquetas de accesibilidad (accessibilityLabel) |
395 apariciones |
Roles de accesibilidad (accessibilityRole) |
249 apariciones |
| Componentes con etiqueta o rol | 136 de 216 archivos de interfaz (63 %) |
| Anuncios explícitos al lector de pantalla | 54 llamadas |
| Archivos de test de accesibilidad | 7 |
Tres cosas concretas, más allá de los recuentos:
- La detección cambia el comportamiento, no solo un ajuste. Cuando hay un lector de pantalla activo, la pantalla de juegos muestra otro conjunto: se ocultan las mecánicas que dependen de ver para poder jugarse. Es mejor decir «este juego no es para ti» que ofrecerlo y que sea una trampa.
- La app no habla encima de tu lector. La narración propia se suprime cuando detecta VoiceOver o TalkBack, igual que en la web.
- Dos reglas de accesibilidad bloquean el envío de código. Una prohíbe que las etiquetas de los minijuegos revelen la respuesta —de nada sirve anunciar «opción 2: la letra M» en un ejercicio que consiste en adivinar la letra—; la otra obliga a que cualquier pantalla que declare una región dinámica anuncie de verdad sus cambios. Son comprobaciones automáticas que se ejecutan antes de subir cambios.
Esa segunda regla tiene tres excepciones registradas en el propio código, con nombre y apellidos: tres pantallas donde el comportamiento no está resuelto y cuyos cambios de estado, según nuestra propia nota interna, hoy son silenciosos para VoiceOver en iOS. Están anotadas ahí para que no se olviden. Las mencionamos porque una lista de excepciones que no se cuenta fuera es una lista que no presiona a nadie.
Lo que no podemos afirmar
Esta es la sección que hace que el resto del artículo sirva de algo. Casi todo lo que sigue está también en nuestra declaración de accesibilidad, que es el documento oficial y manda sobre esta página.
Una etiqueta presente no es una etiqueta que se oye. Todos los recuentos de este artículo miden presencia, no funcionamiento. Nuestra propia revisión interna encontró en su día un botón importante cuya etiqueta estaba escrita en el código, había pasado revisión, y aun así se anunciaba como «botón», sin nombre. Los tests y los recuentos detectan la ausencia de etiqueta; no detectan que el foco no llegue, que el orden sea absurdo o que un gesto no alcance el elemento. Léelos con esa medida.
No hay auditoría externa. Nadie ajeno al equipo ha evaluado formalmente Braillito contra las WCAG. La evaluación que hay es una autoevaluación interna.
No declaramos un nivel de conformidad. Aspiramos a WCAG 2.1 nivel AA y no afirmamos cumplirlo. Declarar un nivel sin una evaluación que lo respalde es exactamente el tipo de promesa que hace daño a quien la lee para decidir si puede usar la herramienta.
No hemos probado todas las combinaciones. No existe una batería sistemática de pruebas con cada lector de pantalla, cada navegador y cada versión de sistema operativo.
Y la más incómoda: nuestras pruebas automáticas leen el árbol de accesibilidad, no escuchan a un lector de pantalla. Los tests, el informe por lección y las reglas que bloquean el envío de código funcionan todos sobre la estructura de la interfaz. Es una forma buena y barata de cazar el fallo más común, el control sin nombre. Pero no sustituye a recorrer la app entera con VoiceOver encendido en un teléfono de verdad, y esa prueba completa, con su informe, todavía no la hemos hecho. Cuando esté, se publicará y esta sección cambiará.
No hemos probado con cada modelo de línea braille. El texto de la aplicación es texto real, así que una línea braille conectada al lector de pantalla lo mostrará como muestra cualquier otro texto, pero no hemos hecho pruebas específicas con modelos concretos. Y conviene no confundir dos cosas: Braillito no es compatible con líneas braille en el sentido de usarlas como dispositivo de entrada del ejercicio, como sí hace iBraille Challenge. La línea muestra el texto de la pantalla; no es el instrumento con el que se responde.
Los 16 minijuegos no se han revisado con el mismo detalle. Son mecánicas muy distintas entre sí. Si alguna no te funciona con tu lector, queremos saber cuál.
La declaración de accesibilidad cubre la web, no las apps nativas. Su alcance está acotado a braillito.com y a la aplicación web que se abre desde él. Las aplicaciones nativas de iOS y Android no están evaluadas todavía, y por eso no aparecen en esa declaración.
Y una limitación del curso que no es de accesibilidad pero condiciona para quién sirve: Braillito enseña braille grado 1, letra por letra. No enseña braille contraído. Lo explicamos en braille grado 1 y grado 2, y en la comparativa de apps para aprender braille decimos cuáles lo hacen mejor que nosotros.
Cómo empezar, si usas lector de pantalla
Un orden que reduce las probabilidades de tropezar en los primeros cinco minutos:
- Ten el lector ya activado antes de abrir la app. VoiceOver o TalkBack no se activan desde dentro de Braillito; son del sistema.
- Si entras por el navegador, responde «Sí, uso lector de pantalla» en la pregunta de la configuración inicial. Es lo que enciende los avisos hablados y apaga la voz propia de la app. En las apps de iOS y Android no hace falta: lo detectan solas.
- Empieza por el primer mundo aunque ya sepas braille. Las primeras lecciones son también donde se aprende cómo suenan las celdas anunciadas, y eso es una convención nueva aunque el braille no lo sea.
- Escucha el aviso de la mecánica antes de pulsar EMPEZAR LECCIÓN. Explica qué vas a encontrarte y dónde. Es el único sitio donde se cuenta la disposición de la pantalla.
- Usa el rotor o los controles de lectura para saltar por encabezados en lugar de recorrer la pantalla elemento por elemento.
- Si algo no funciona, no lo des por tu culpa. Escríbenos y dinos qué pantalla era: es lo que arregla la lista de arriba.
Cómo reportarnos una barrera
Si una pantalla no se deja leer con tu lector, si un ejercicio no se puede completar sin ver, si el contraste no te alcanza o si algo se pierde al ampliar el texto, dínoslo. Los avisos concretos son lo único que mueve la lista de limitaciones.
Lo que nos sirve saber: qué pantalla o qué lección era, con qué dispositivo y con qué lector de pantalla, y qué esperabas que pasara.
Respondemos en un plazo máximo de 5 días hábiles. Si prefieres no usar la web —o si es precisamente la web lo que no te funciona— puedes llamarnos al +1 305 462 4160. Los detalles y el formulario están en la declaración de accesibilidad.
Tratamos estos avisos como errores, no como sugerencias.
Preguntas frecuentes
¿Braillito funciona con VoiceOver y TalkBack?
Está construido para eso y hay trabajo específico en el código —etiquetas de celda punto por punto, anuncios en vivo en los 16 minijuegos, avisos hablados por mecánica— con tests automáticos que lo comprueban. No hay una auditoría externa que lo certifique, y por eso decimos «construido para» y no «certificado». La forma honesta de resolver la duda es probarlo, y decir de antemano que la app es de pago. Si algo no te funciona con tu lector de pantalla, escríbenos y lo arreglamos.
¿Hay que activar algo dentro de la app?
El lector de pantalla se activa desde el sistema, no desde Braillito. En la versión web conviene además responder que usas lector de pantalla en la configuración inicial —o activarlo después en Ajustes—, porque eso enciende los avisos hablados de cada mecánica y apaga la narración propia de la app para que no se solape con tu lector. En las apps de iOS y Android no hay nada que tocar: detectan VoiceOver y TalkBack por su cuenta.
¿Puedo usar Braillito con una línea braille?
Puedes leer con ella lo que muestre tu lector de pantalla, porque el texto de la aplicación es texto real. Lo que no puedes es usarla como dispositivo de entrada para responder los ejercicios: Braillito no la soporta como mando. Si buscas eso, la app diseñada alrededor de una línea braille es iBraille Challenge, que reseñamos en la comparativa de apps.
¿Sirve Braillito si soy ciego total?
El curso está diseñado para que se pueda completar sin ver la pantalla: cada mecánica se explica hablada antes de empezar, las celdas se anuncian con sus puntos y sus posiciones, y los resultados se anuncian por voz. Dicho eso, aprender braille en pantalla tiene un límite que ninguna app resuelve: la pantalla no tiene relieve. En una app se aprende el sistema —qué puntos forman cada letra—; el tacto se entrena con papel, regleta o línea braille. Lo desarrollamos en cómo aprender braille desde cero.
¿Por qué la web pregunta si soy ciego en lugar de detectarlo?
Porque en un navegador no se puede detectar. Los navegadores no exponen si hay un lector de pantalla en marcha, y lo hacen deliberadamente: sería un dato de salud utilizable para identificar y rastrear a una persona. Preguntarlo es la única alternativa a adivinarlo, y adivinarlo se acierta mal. En iOS y Android el sistema sí lo expone, así que ahí las apps lo detectan y no preguntan nada.
¿Qué pasa si encuentro algo que no funciona?
Escríbenos con la pantalla, el dispositivo y el lector de pantalla que usabas. Respondemos en un máximo de 5 días hábiles, y también atendemos por teléfono en el +1 305 462 4160 por si la barrera está justo en la web. Está todo en la declaración de accesibilidad.