En la lección anterior conocimos a las personas y sus barreras. Ahora conocemos sus herramientas. Marta (ciega), Lucía (solo teclado), Diego (sordo) y el resto no acceden a la web a mano descubierta: se apoyan en programas y dispositivos que traducen el contenido a un canal que sí pueden usar —voz, braille, ampliación, comandos hablados, un solo botón—. Esas herramientas son las tecnologías de asistencia (TA, o AT en inglés).

En esta lección haremos una panorámica de las principales: lectores de pantalla, magnificadores y zoom, líneas braille, control por voz, acceso por conmutador, seguimiento ocular, teclados alternativos y los modos de lectura/alto contraste del navegador y del sistema. Además introduciremos, a nivel conceptual, cómo una TA se apoya en el marcado para funcionar: aquí aparece la idea del árbol de accesibilidad y las API de accesibilidad.

Alcance: describimos qué es cada TA y para quién, no cómo se programa para ellas (eso es semántica, ARIA, alt… módulos 4 y 5), ni los patrones de navegación detallados (cómo se salta por encabezados, cómo se usa el modo foco… eso es la lección 02-03). Aquí montamos el catálogo de herramientas; su manejo fino viene después.

1. Qué son las tecnologías de asistencia
2. Lectores de pantalla
3. Magnificadores, zoom y ampliación
4. Líneas braille
5. Control por voz
6. Acceso por conmutador (switch)
7. Seguimiento ocular (eye tracking)
8. Teclados alternativos y otros dispositivos de entrada
9. Modos de lectura y alto contraste del navegador/SO
10. Cómo "ven" las TA tu web: el árbol de accesibilidad
11. Mapa: discapacidad → TA típica

Una tecnología de asistencia es cualquier producto —software o hardware— que permite a una persona con discapacidad realizar una tarea que de otro modo le resultaría difícil o imposible. En la web, su misión es mediar entre la página y la persona: reciben el contenido, lo transforman (a voz, a texto grande, a braille) y, en sentido inverso, traducen las acciones de la persona (un comando de voz, la pulsación de un conmutador) en interacciones con la página.

Dos ideas que conviene fijar desde ya:

• La TA no adivina. Funciona bien solo si el sitio le ofrece información correcta y estructurada. Un lector de pantalla no "entiende" una imagen: lee la descripción que el desarrollador le haya dado. Esta dependencia es la razón de ser de todo el curso.
• Una misma persona puede combinar varias TA (por ejemplo, lector de pantalla + línea braille) y, además, ajustes del sistema operativo (tamaño de fuente, reducir movimiento). No hay "un usuario de TA" estándar.

Son la TA más conocida. Un lector de pantalla (screen reader) convierte el contenido de la pantalla en voz sintetizada y/o braille. Lo usan sobre todo personas ciegas y algunas con baja visión severa o dificultades de lectura. La persona no ve la página: la escucha, elemento a elemento, y la recorre con el teclado o con gestos táctiles.

Los principales, con su plataforma habitual:

Una consecuencia práctica de esta tabla: hay muchos lectores y ninguno es idéntico a otro. Lo que suena perfecto en NVDA puede leerse distinto en VoiceOver. Por eso, más adelante (módulo 6), probar con más de un lector será parte del proceso de pruebas. De momento, quédate con que existen, en qué plataforma viven y que son gratuitos de probar en casi todos los sistemas.

No todas las personas con discapacidad visual son ciegas. Muchas tienen baja visión y usan su resto visual ampliado. Aquí hay una escala de soluciones:

• Zoom del navegador. El más simple y universal: con Ctrl + + (o Cmd + +) se agranda todo. Muchísima gente lo usa a diario, con o sin discapacidad. Ampliaciones del 200% son habituales; WCAG exige que la página siga funcionando a ese nivel.
• Magnificadores del sistema operativo (Lupa de Windows, Zoom de macOS): amplían una porción de la pantalla, a veces con lente que sigue al cursor, hasta el 400% o más.
• Software especializado como ZoomText o MAGic, que además de ampliar mejoran contraste, suavizan bordes y pueden combinar ampliación con lectura por voz.

La barrera clásica que sufre este grupo: cuando la página se amplía y aparece scroll horizontal o el contenido se descoloca y se solapa. El comportamiento correcto (que el contenido se reorganice en una columna, el reflow) lo veremos como patrón de uso en 02-03 y como criterio técnico en el módulo 4.

Una línea (o pantalla) braille es un dispositivo hardware que se conecta al ordenador o móvil y representa el texto en braille táctil mediante una fila de celdas con puntos que suben y bajan. Trabaja junto a un lector de pantalla: el lector decide qué texto mostrar y la línea braille lo materializa bajo los dedos.

¿Por qué braille y no solo voz? Porque:

• Es imprescindible para personas sordociegas, que no pueden usar la salida de voz.
• Permite leer con precisión ortografía, código, cifras o nombres propios que la voz puede volver ambiguos.
• Muchas personas ciegas prefieren braille para lectura atenta (estudiar, revisar) frente al consumo rápido por voz.

Para nosotros la implicación es directa: todo lo que el lector de pantalla lee, la línea braille lo transmite. Si una imagen no tiene texto alternativo, no hay ni voz ni braille. Es decir, mejorar para el lector de pantalla mejora también para braille "gratis".

El control por voz permite manejar el dispositivo hablando: dictar texto y, sobre todo, dar órdenes ("abre el menú", "haz clic en Matricularme", "desplázate hacia abajo"). Lo usan personas con discapacidad motriz que no pueden usar teclado ni ratón, y también personas con dislexia o fatiga que prefieren dictar.

Ejemplos habituales: Dragon (Dragon NaturallySpeaking / Dragon Professional) en Windows, Voice Control en macOS/iOS y Voice Access en Android.

Un matiz importante que desarrollaremos en 02-03: el control por voz suele apoyarse en el nombre visible o accesible de los elementos. Si un botón se llama de verdad "Matricularme", la persona dice "haz clic en Matricularme" y funciona. Si el botón es un icono sin nombre, no hay palabra que pronunciar, y muchos sistemas recurren entonces a "mostrar números" (superponer un número a cada elemento clicable) como plan B.

El acceso por conmutador es para personas con movilidad muy reducida que solo pueden realizar un gesto fiable: pulsar uno o dos botones (un switch), accionado con la mano, la cabeza, el pie o incluso un soplo. Con tan poca entrada, ¿cómo se navega toda una web?

Mediante barrido (scanning): el sistema resalta los elementos uno a uno de forma automática, y la persona acciona el conmutador cuando el resaltado llega al elemento que quiere. Es como una navegación por teclado llevada al extremo: en el fondo, recorre los mismos elementos enfocables en el mismo orden.

La consecuencia para el diseño es contundente: si algo no es alcanzable con teclado o el orden de foco es un caos, para un usuario de conmutador no es "incómodo", es literalmente inalcanzable, y cada elemento de más en el recorrido es tiempo y esfuerzo. Por eso el trabajo que hagamos por el teclado (módulo 5) beneficia directamente a este grupo.

El seguimiento ocular rastrea hacia dónde mira la persona con una cámara especial y mueve el puntero a ese punto; la "pulsación" se hace fijando la mirada un instante (dwell) o con un conmutador auxiliar. Lo usan personas con movilidad muy limitada (por ejemplo, ELA o tetraplejia) que conservan el control de los ojos.

Su gran enemigo son los objetivos pequeños y juntos: apuntar con la mirada es menos preciso que con el ratón, así que botones diminutos o enlaces pegados se vuelven muy difíciles de acertar. Enlaza con la barrera de "objetivos táctiles" que ya vimos y con el criterio de tamaño de objetivo que trataremos más adelante.

No todo el mundo usa el teclado y el ratón estándar. Existe un ecosistema de hardware adaptado:

• Teclados grandes, con teclas separadas o con guía (para temblor o baja precisión).
• Teclados en pantalla (virtuales), que se accionan con ratón, mirada o conmutador.
• Trackballs, joysticks y ratones adaptados para quien no maneja un ratón normal.
• Punteros de cabeza/boca para escribir tecla a tecla.

El punto clave: casi todos estos dispositivos, por debajo, emulan un teclado. Es decir, generan pulsaciones de tecla, Tab, Enter, flechas… Por eso una idea que repetiremos en todo el curso: si tu sitio funciona perfectamente con teclado, funciona con la inmensa mayoría de estos dispositivos. El teclado es el "mínimo común denominador" de la accesibilidad motriz.

No todas las ayudas son productos especializados; muchas están ya integradas en el navegador y el sistema operativo, y las usan tanto personas con discapacidad como cualquiera:

• Modo lectura del navegador: elimina distracciones y deja solo el texto principal, con tipografía y tamaño ajustables. Ayuda a dislexia, TDAH y baja visión.
• Modos de alto contraste / temas de contraste del sistema, y el modo oscuro: recolorean la interfaz para hacerla más legible.
• Ajustes del SO de tamaño de texto, cursor grande, reducir movimiento o reducir transparencias.

Para nosotros son relevantes porque un sitio bien construido respeta estas preferencias del usuario (por ejemplo, "reducir movimiento"), mientras que uno mal hecho las ignora o incluso se rompe con ellas. El cómo respetarlas es materia de los módulos 4 y 5.

Esta es la idea conceptual más importante de la lección, y conviene entenderla aunque el detalle técnico venga después.

Cuando el navegador carga una página, no solo construye el DOM (el árbol de elementos HTML que se dibuja en pantalla). Construye también, en paralelo, una versión simplificada y "semántica" pensada para las TA: el árbol de accesibilidad (accessibility tree). En él, cada elemento relevante se representa con datos como:

• su rol (¿es un botón? ¿un enlace? ¿un encabezado? ¿un campo de texto?),
• su nombre (el texto que lo identifica: "Matricularme", "Buscar curso"),
• su estado y valor (¿está marcado? ¿desplegado? ¿deshabilitado? ¿qué contiene?).

El navegador expone ese árbol a través de las API de accesibilidad del sistema operativo (hay una en Windows, otra en macOS, otra en Android…). El lector de pantalla, el control por voz o la línea braille no leen tus píxeles ni tu CSS: consultan ese árbol a través de la API. Lo que no esté bien representado ahí, para la TA no existe o existe mal.

De aquí sale la moraleja que gobierna medio curso: programamos para el árbol de accesibilidad, no solo para lo que se ve. Un <div> estilizado como botón puede parecer un botón en pantalla, pero si en el árbol no consta como botón (sin rol, sin nombre), el lector de pantalla anunciará "nada" y el control por voz no lo encontrará. Cómo rellenar bien ese árbol —con HTML semántico y, cuando haga falta, ARIA— es justo el contenido de los módulos 4 y 5. Aquí solo necesitas la foto mental: existe un árbol intermedio y las TA dependen de él.

Cerramos uniendo las dos lecciones del módulo. Esta tabla conecta los grupos de discapacidad (02-01) con las TA más frecuentes en cada caso. No es una correspondencia rígida (cada persona combina lo que le sirve), pero orienta:

Fíjate en un patrón revelador: para varios grupos (sordera, daltonismo, cognitiva) la "tecnología de asistencia" es, en el fondo, que el sitio esté bien hecho. No hay un aparato que arregle un mal diseño: la accesibilidad se construye en el origen.

• Creer que "accesible" = "compatible con lector de pantalla". El lector de pantalla es solo una TA. Hay usuarios de voz, de conmutador, de zoom, de subtítulos… y muchos que solo necesitan buen diseño. Diseñar solo para el lector deja fuera al resto.
• Suponer un único lector de pantalla. NVDA, JAWS, VoiceOver y TalkBack no se comportan igual. Lo veremos al hablar de pruebas (módulo 6).
• Olvidar que casi toda TA motriz emula teclado. Si algo no va con teclado, no va con conmutador, ni con voz "por números", ni con muchos teclados alternativos. El teclado es el mínimo común denominador.
• Pensar que la TA "adivina". No lo hace: lee el árbol de accesibilidad. Si el marcado es pobre, la TA no puede compensarlo.
• Consejo: instala NVDA (Windows) o activa VoiceOver (Mac) y dedica diez minutos a "escuchar" una web. No busques todavía arreglar nada; solo entender la experiencia. Es la mejor inversión de empatía del curso.

Ejercicio 1. Empareja cada usuario de Cursalia con la(s) TA que probablemente usa y por qué:

1. Marta, ciega, quiere leer con precisión el código de descuento de su matrícula.
2. Un alumno con ELA que solo controla la mirada.
3. Lucía, con lesión medular, que además tiene fatiga y prefiere no teclear mucho.

Ejercicio 2. Explica con tus palabras, en 3-4 frases, qué es el árbol de accesibilidad y por qué un <div> con aspecto de botón puede ser un problema para un lector de pantalla y para el control por voz.

Ejercicio 3. Indica Verdadero o Falso y justifica:

1. "Si mi sitio funciona con teclado, funcionará también para la mayoría de usuarios de conmutador y de teclados alternativos."
2. "Una persona sorda necesita instalar una tecnología de asistencia especial para ver los vídeos de Cursalia."
3. "NVDA es de pago y solo funciona en macOS."

Solución 1.

1. Marta: lector de pantalla + línea braille. La voz puede volver ambiguo un código alfanumérico; el braille le permite leerlo carácter a carácter con precisión.
2. Seguimiento ocular (eye tracking), posiblemente con dwell o un conmutador para "clicar". Conserva el control de los ojos aunque no el de las manos.
3. Control por voz (dar órdenes y dictar), quizá combinado con navegación por teclado cuando le convenga. Reduce el esfuerzo físico de teclear.

Solución 2. El árbol de accesibilidad es la representación semántica (rol, nombre, estado y valor de cada elemento) que el navegador construye en paralelo al DOM y expone a las TA a través de las API de accesibilidad del sistema. Las TA leen ese árbol, no los píxeles. Un <div> con aspecto de botón parece un botón en pantalla, pero en el árbol no consta como botón: no tiene rol de botón ni un nombre accesible. Por eso el lector de pantalla no lo anuncia como algo activable y el control por voz no encuentra ninguna palabra ("haz clic en…") con la que activarlo.

Solución 3.

1. Verdadero. La mayoría de dispositivos de acceso motriz (conmutadores por barrido, teclados alternativos) recorren los mismos elementos enfocables en el mismo orden que el teclado: si el teclado funciona, ellos también.
2. Falso. No necesita ninguna TA especial: necesita que el sitio ofrezca subtítulos y transcripción. La ayuda, en este caso, está en el contenido, no en un aparato.
3. Falso. NVDA es gratuito y de código abierto, y funciona en Windows (VoiceOver es el de macOS).

Ya tenemos el catálogo de herramientas: lectores de pantalla (NVDA, JAWS, VoiceOver, TalkBack), magnificadores y zoom, líneas braille, control por voz, conmutadores, seguimiento ocular, teclados alternativos y los modos de lectura/contraste del sistema. Y, sobre todo, tenemos el concepto que las une: las TA no leen tu diseño visual, sino el árbol de accesibilidad que el navegador expone por las API de accesibilidad. Programamos para ese árbol —cuya construcción práctica llega en los módulos 4 y 5—.

Nos falta la pieza que convierte todo esto en decisiones de diseño: cómo se navega realmente con estas herramientas. ¿Cómo recorre Marta el catálogo con NVDA? ¿Cómo tabula Lucía por el formulario de matrícula? ¿Qué pasa exactamente cuando algo está mal hecho? Eso es la siguiente lección, 02-03: Cómo las Personas con Discapacidades Usan la Web, donde veremos los patrones de uso reales y los puntos exactos donde se rompe la experiencia.