Ya sabemos quiénes son (02-01) y con qué herramientas navegan (02-02). Falta la pieza que convierte todo eso en decisiones de diseño: cómo se navega realmente con esas tecnologías de asistencia, y por qué eso condiciona cómo debemos construir cada página. Esta es la lección que "cierra el círculo" del módulo: aquí verás que las TA no consumen la web como tú, sino siguiendo patrones muy concretos —por teclado, por estructura, por voz, con zoom— y que si el sitio ignora esos patrones, la experiencia se rompe en puntos identificables.

Recorreremos cuatro patrones de uso, y luego narraremos tres escenarios completos en Cursalia (Marta con NVDA, Lucía solo con teclado, y una alumna con zoom al 300%) mostrando dónde y por qué falla cuando el sitio no está bien hecho. Usaremos algún fragmento HTML mínimo para ilustrar una buena frente a una mala estructura, pero sin entrar en la implementación completa (la semántica y ARIA se ven en el módulo 4). El objetivo aquí es motivar el porqué; el cómo llega en los módulos siguientes.

1. Patrón 1: navegación por teclado
2. Patrón 2: uso de lector de pantalla por estructura
3. Patrón 3: navegación por voz
4. Patrón 4: zoom, ampliación y reflow
5. Escenario A — Marta busca un curso con NVDA
6. Escenario B — Lucía se matricula solo con teclado
7. Escenario C — Sofía estudia con zoom al 300%
8. Qué tienen en común todos los fallos

Muchísimas personas no usan el ratón: usuarios motrices, de lector de pantalla, de conmutador, de voz… y también usuarios avanzados. Todos ellos comparten un mismo lenguaje, el del teclado. Sus teclas básicas:

De este patrón nacen tres exigencias que repetiremos todo el curso:

• Todo lo operable con ratón debe serlo con teclado. Si un menú solo se abre "al pasar por encima" o un botón solo responde al clic, quien usa teclado queda fuera.
• El foco debe verse. La persona necesita saber dónde está el "cursor de teclado". Ese recuadro o resalte es el foco visible. Si el diseño lo elimina (un CSS que quita el outline), el usuario navega a ciegas.
• El orden de foco debe ser lógico. Tab debería recorrer la página en un orden que tenga sentido (normalmente, el de lectura). Si salta del encabezado al pie y luego al menú, recorrer la página se vuelve un laberinto.

Aquí está la revelación que más cambia la mentalidad de un desarrollador: una persona ciega no lee la página de arriba abajo palabra por palabra. Sería lentísimo. En su lugar, navega por la estructura, usando el marcado como un índice. Sus atajos habituales:

• Saltar por encabezados (en NVDA/JAWS, la tecla H): recorre los <h1>, <h2>, <h3>… como quien ojea los titulares de un periódico para orientarse.
• Lista de enlaces: pide "dame todos los enlaces" y elige. Por eso cuarenta enlaces llamados "Ver más" son inútiles: fuera de contexto, no dicen adónde van.
• Regiones / landmarks: salta directamente a zonas como "navegación principal", "contenido principal", "pie", si el sitio las declara.
• Modo navegación vs. modo foco. Este matiz es clave. Al leer, el lector está en modo navegación (o "de exploración"): las teclas como H o las flechas sirven para moverse por el contenido. Pero al llegar a un campo de formulario, el lector entra en modo foco (o "de formularios"): ahora las teclas escriben en el campo en lugar de navegar. Muchos lectores cambian entre ambos modos automáticamente al entrar y salir de los campos.

La consecuencia de diseño es enorme: la estructura semántica es la interfaz para el usuario de lector de pantalla. Compara estos dos catálogos de Cursalia:

En el primer caso, el usuario pulsa H para saltar por encabezados y no ocurre nada: no hay encabezados; el sitio es un muro plano. Pide la lista de enlaces y oye "Ver más", sin destino. En el segundo, salta de <h2> en <h2> oyendo los nombres de los cursos y cada enlace se anuncia con su destino. Mismo aspecto visual; experiencia opuesta. (El detalle de por qué <h2> y <article> son los correctos, y cómo etiquetarlos, es el módulo 4; aquí solo observamos el efecto.)

Quien usa control por voz maneja la página hablando. Sus comandos más típicos:

• Activar por nombre: "haz clic en Matricularme", "pulsa Buscar". El sistema busca un elemento cuyo nombre accesible coincida con lo dicho.
• Mostrar números / cuadrícula: cuando un elemento no tiene nombre pronunciable (un icono "🔍" sin etiqueta), la persona dice "mostrar números" y el sistema superpone un número a cada elemento clicable; entonces dice "clic en el 7". Es el plan B, más lento y torpe.
• Dictado y desplazamiento: "desplázate hacia abajo", "vuelve arriba", dictar texto en un campo.

La lección de diseño: el nombre visible debería coincidir con el nombre accesible. Si el botón dice "Matricularme" en pantalla pero internamente se llama otra cosa (o nada), el comando "haz clic en Matricularme" falla, y la persona ni siquiera sabe por qué. Los iconos sin etiqueta obligan a recurrir a los números, encareciendo cada acción. (Cómo garantizar ese nombre accesible: módulos 4 y 5.)

La persona con baja visión amplía. No hablamos de un caso raro: ampliaciones del 200% son cotidianas, y con magnificadores se llega al 300-400%. Al ampliar tanto, en una pantalla caben muy pocas palabras, así que el comportamiento correcto es el reflow: el contenido se reorganiza en una sola columna que se lee bajando en vertical, sin scroll horizontal.

Dónde se rompe:

• Scroll horizontal: si al ampliar aparece una barra horizontal, la persona tiene que arrastrar a izquierda y derecha en cada línea para leer. Es agotador y hace que se pierdan trozos.
• Contenido que se solapa o se corta: menús que tapan el texto, botones que se salen de la pantalla, texto recortado.
• Barras fijas que se comen la pantalla: una cabecera fija que al 300% ocupa media pantalla y deja el contenido en una rendija.

El principio: el diseño debe ser flexible/responsive para que el mismo contenido quepa reorganizado. Es la misma cualidad que hace que un sitio funcione bien en móvil; no es casualidad. (Los criterios exactos de redimensionamiento y reflow son del módulo 4.)

Marta es ciega y usa NVDA en Windows. Quiere encontrar el curso "Python desde cero" en el catálogo de Cursalia y abrir su ficha.

Cómo lo intenta (su patrón natural): al cargar el catálogo, Marta pulsa H para saltar por encabezados y hacerse un mapa rápido de la página. Luego pediría la lista de enlaces para ir directa al curso.

Sitio mal hecho:

1. Pulsa H… y NVDA dice "sin encabezados". Toda la página es un mar de <div>. Marta ha perdido su mapa: ahora tiene que oír la página entera, linealmente.
2. Pide la lista de enlaces y oye "Ver más, Ver más, Ver más…" cuarenta veces, todos idénticos. No hay forma de saber cuál es Python.
3. Las tarjetas llevan una imagen del curso sin texto alternativo: NVDA lee "imagen" o el nombre del archivo, curso_0423.jpg. Inútil.
4. Marta abandona y se va a otra plataforma. La barrera no fue su ceguera; fue la falta de estructura y de texto alternativo.

Sitio bien hecho:

1. Pulsa H y oye "Catálogo de cursos, encabezado 1", "Python desde cero, encabezado 2", "Diseño UX, encabezado 2"… En segundos tiene el índice mental.
2. Se planta en "Python desde cero" y su enlace se anuncia como "Ver el curso Python desde cero, enlace". Pulsa Enter y entra.
3. Total: unos segundos, con autonomía y sin frustración.

Lucía tiene una lesión medular y navega solo con teclado (sin ratón). Retomamos la escena que dejamos abierta en 02-01: quiere completar el formulario de matrícula.

Cómo lo intenta: Tab para avanzar campo a campo, escribir, flechas para elegir opciones, Enter para enviar.

Sitio mal hecho — se rompe en tres puntos:

1. Foco invisible. Alguien "limpió" el diseño quitando el outline del CSS. Lucía pulsa Tab varias veces y no ve dónde está: teclea a ciegas, sin saber en qué campo escribe.
2. Trampa de teclado + desplegable de solo-ratón. El selector de "forma de pago" es un <div> personalizado que solo se abre con clic. Con teclado no despliega, y peor: al tabular, el foco queda atrapado dentro de él y no sale (una keyboard trap). Lucía no puede ni elegir pago ni continuar.
3. Botón final inalcanzable. Aun sorteando lo anterior, el botón "Confirmar matrícula" es un <div onclick> que no recibe foco con Tab. Lucía llega al último paso y no puede pulsarlo. Matrícula perdida.

Sitio bien hecho: cada campo recibe foco en orden lógico, el foco se ve con claridad, el selector de pago se abre y se recorre con teclado (flechas + Enter), y "Confirmar" es un <button> real que Lucía activa con Enter. Se matricula sola, sin ayuda. (El cómo construir ese selector accesible es el módulo 5; el botón semántico, el módulo 4.)

Sofía tiene baja visión y navega con el zoom del navegador al 300%. Está en la ficha de curso leyendo el temario antes de matricularse.

Sitio mal hecho:

1. Al 300%, la ficha mantiene su rejilla de tres columnas comprimida: aparece scroll horizontal. Sofía debe arrastrar a derecha e izquierda en cada línea del temario. Tras dos minutos, agotada, lo deja.
2. La cabecera fija ocupa ahora casi media pantalla; el contenido real asoma por una rendija.
3. Un aviso de "plazas limitadas" queda cortado por el borde: Sofía no llega a leerlo entero.

Sitio bien hecho: al ampliar, el contenido hace reflow a una sola columna; Sofía lee bajando en vertical, sin desplazamiento horizontal, la cabecera se compacta y nada se solapa. Misma información, esfuerzo mínimo.

Si observas los tres escenarios, los fallos no son azarosos: se repiten y se agrupan. Y esa agrupación es, precisamente, la antesala del Módulo 3.

• Que Marta no perciba las imágenes ni pueda leer el catálogo → es un fallo de Percepción.
• Que Lucía no pueda tabular, no vea el foco o quede atrapada → es un fallo de Operabilidad.
• Que Hugo (02-01) no entienda las preguntas o los errores → es un fallo de Comprensión.
• Que un <div onclick> no conste como botón en el árbol de accesibilidad → es un fallo de Robustez.

Perceptible, Operable, Comprensible, Robusto. Esos cuatro cajones no son una casualidad: son los cuatro principios POUR de WCAG que presentamos en la lección 01-04. Acabamos de descubrir, desde la experiencia real de las personas, por qué el estándar está organizado exactamente así.

• Creer que la gente lee la web como tú. El usuario de lector de pantalla salta por estructura; el de teclado tabula; el de baja visión amplía. Diseñar suponiendo un recorrido lineal con ratón deja fuera a todos ellos.
• Quitar el foco visible "porque afea". Es uno de los daños más frecuentes y más graves: deja a Lucía navegando a ciegas. Nunca elimines el indicador de foco sin sustituirlo por uno mejor.
• Fabricar botones y controles con <div>. Parecen funcionar con ratón, pero no reciben foco, no responden a Enter/Espacio y no constan en el árbol de accesibilidad. Es la raíz de medio módulo 2.
• Enlaces y botones sin texto significativo. "Ver más", "Aquí", iconos sin nombre: fuera de contexto no dicen nada al lector de pantalla ni al control por voz.
• Probar solo con ratón y vista. Consejo: navega una tarea completa de Cursalia usando solo Tab, Enter y flechas, sin tocar el ratón. En cinco minutos encontrarás barreras que a simple vista no se ven.

Ejercicio 1. Un desarrollador de Cursalia dice: "He probado el catálogo con el ratón y funciona genial, así que es accesible". Da tres razones, basadas en los patrones de esta lección, por las que esa prueba es insuficiente.

Ejercicio 2. En el escenario de Lucía identificamos tres puntos de rotura (foco invisible, trampa de teclado, botón no enfocable). Clasifica cada uno según el principio POUR al que corresponde y explica en una frase por qué.

Ejercicio 3. Sofía amplía al 300% y aparece scroll horizontal. (a) ¿Qué patrón de uso está fallando? (b) ¿Qué comportamiento debería tener la página en su lugar? (c) ¿A qué principio POUR pertenece este problema?

Solución 1. Ejemplos: (1) No probó con teclado: un usuario que solo tabula podría no alcanzar tarjetas o botones que con ratón sí funcionan. (2) No probó con lector de pantalla: sin encabezados ni textos de enlace significativos, Marta no puede navegar por estructura aunque "con el ratón se vea bien". (3) No probó con voz ni con zoom: iconos sin nombre rompen el control por voz, y la ampliación al 200-300% podría provocar scroll horizontal. En resumen, "funciona con ratón y vista" solo cubre uno de los muchos patrones de uso.

Solución 2.

• Foco invisible → Operable. El usuario de teclado no puede operar la interfaz con seguridad si no sabe dónde está el foco.
• Trampa de teclado → Operable. Si el foco queda atrapado, la persona no puede continuar la operación; es un bloqueo total de la operabilidad.
• Botón no enfocable (<div onclick>) → Robusto (y Operable). No consta como botón en el árbol de accesibilidad (robustez ante las TA) y, además, no se puede activar con teclado (operabilidad).

Solución 3. (a) Falla el patrón de zoom/ampliación y reflow. (b) La página debería reorganizar el contenido en una sola columna (reflow) para poder leerlo bajando en vertical, sin scroll horizontal. (c) Pertenece al principio Perceptible (que el usuario pueda percibir el contenido al ampliarlo, sin que se pierda o quede inaccesible).

Hemos visto cómo se usa realmente la web con tecnologías de asistencia: por teclado (con foco visible y orden lógico), por estructura con el lector de pantalla (saltando por encabezados, enlaces y regiones, alternando modo navegación y modo foco), por voz (activando elementos por su nombre) y con zoom (esperando reflow sin scroll horizontal). Y en Cursalia hemos comprobado, con Marta, Lucía y Sofía, dónde y por qué se rompe la experiencia cuando el sitio ignora esos patrones.

Con esto cerramos el Módulo 2. Ahora entendemos a las personas, sus herramientas y sus formas de navegar. Y hemos hecho un descubrimiento que lo conecta todo: los fallos no son aleatorios: se agrupan en cuatro familias —no lo perciben, no lo operan, no lo comprenden, no es robusto—. Esas cuatro familias son los principios POUR de WCAG. No son una abstracción académica: son la respuesta sistemática a las barreras reales que acabamos de presenciar.

Eso es exactamente lo que abre el Módulo 3: Principios del Diseño Accesible, donde desarrollaremos en profundidad Perceptible, Operable, Comprensible y Robusto. Ya no los veremos como una lista teórica, sino como la solución ordenada a los problemas de Marta, Lucía, Sofía, Diego y Hugo. Entender a las personas era el requisito previo; a partir de ahora, empezamos a diseñar la respuesta.