Cerramos el Módulo 1 con una idea: antes de aplicar un solo criterio de WCAG necesitamos entender a las personas para las que diseñamos. Este es el primer paso. En esta lección haremos un panorama de las discapacidades relevantes para la web, agrupadas por el tipo de capacidad afectada: visuales, auditivas, motrices/físicas, cognitivas y de aprendizaje, del habla y neurológicas. Para cada grupo veremos qué implica y, sobre todo, qué barreras encuentra esa persona en un sitio web mal construido —descrito a alto nivel, sin la solución técnica todavía—. Retomaremos el modelo permanente / temporal / situacional de la lección 01-02 aplicándolo a cada grupo, y lo aterrizaremos en escenarios concretos de personas usando Cursalia.

Dos advertencias de alcance. Primera: aquí describimos a las personas y sus barreras, no las herramientas que usan (los lectores de pantalla, magnificadores, etc., son la lección 02-02) ni cómo navegan con ellas (02-03). Segunda: no daremos la solución de código; el "cómo se arregla" son los módulos 3, 4 y 5. Aquí construimos la empatía y el diagnóstico que darán sentido a todo lo demás.

1. Por qué agrupar las discapacidades (y una advertencia)
2. Discapacidades visuales
3. Discapacidades auditivas
4. Discapacidades motrices y físicas
5. Discapacidades cognitivas y de aprendizaje
6. Discapacidades del habla
7. Discapacidades neurológicas y otras
8. El modelo permanente / temporal / situacional aplicado

Agrupamos las discapacidades por capacidad afectada porque es la forma más útil para el diseño: lo que nos importa como creadores de web no es un diagnóstico médico, sino qué canal de interacción queda limitado (ver, oír, mover, procesar, hablar) y, por tanto, qué barreras debemos evitar.

Antes de empezar, tres matices imprescindibles:

• No son compartimentos estancos. Una misma persona puede pertenecer a varios grupos (por ejemplo, sordoceguera, o una persona mayor con baja visión y temblor en las manos).
• Hay un enorme espectro de grados. "Discapacidad visual" abarca desde una leve dificultad de contraste hasta la ceguera total. La mayoría de las personas están en algún punto intermedio.
• Usamos lenguaje centrado en la persona. Decimos "persona ciega" o "persona con baja visión", no etiquetas que reduzcan a alguien a su condición. El respeto también se diseña.

Afectan al canal visual, el más usado para consumir la web. Dentro del grupo hay realidades muy distintas:

• Ceguera. Ausencia total o casi total de visión. Estas personas no perciben nada de la pantalla: acceden al contenido a través del oído (audio) o el tacto (braille), mediante tecnologías de asistencia. El diseño puramente visual les es invisible.
• Baja visión. Visión muy reducida que no se corrige con gafas: agudeza baja, campo visual reducido (visión "de túnel" o pérdida central), sensibilidad al deslumbramiento. Suelen usar la vista, pero necesitan ampliar, aumentar el contraste o reorganizar el contenido.
• Daltonismo y deficiencias de percepción del color. La persona ve, pero no distingue ciertos colores (lo más común, confundir rojos y verdes). Afecta a alrededor del 8% de los hombres.

Barreras típicas en la web (a alto nivel):

• Imágenes, iconos o gráficos sin alternativa textual: para una persona ciega, sencillamente no existen.
• Contraste insuficiente entre texto y fondo: ilegible para baja visión.
• Texto que no se puede ampliar sin romper la página o que obliga a hacer scroll horizontal.
• Información transmitida solo por color: "los campos en rojo son obligatorios", "el curso en verde está disponible". Quien no distingue el color pierde el mensaje.
• Interfaces que dependen de la posición o la forma visual sin ninguna etiqueta que las nombre.

Escenario Cursalia. Marta es ciega y quiere apuntarse a un curso. En el catálogo, cada curso es una tarjeta con una imagen atractiva y un botón. Si esas imágenes no tienen descripción y el botón se llama solo "Ver más" repetido cuarenta veces, Marta oye una lista de "Ver más, Ver más, Ver más…" sin saber a qué curso pertenece cada uno. La barrera no es su ceguera: es el diseño.

Afectan al canal auditivo. Con la web cada vez más audiovisual (vídeo-lecciones, pódcast, notificaciones sonoras), su impacto ha crecido.

• Sordera. Pérdida auditiva profunda o total. Muchas personas sordas se comunican en lengua de signos, que es su lengua natural; el texto escrito en el idioma oral puede ser para ellas una segunda lengua, lo que conviene recordar al redactar.
• Hipoacusia. Pérdida auditiva parcial. La persona puede oír algo, quizá con audífonos, pero pierde matices, palabras en entornos ruidosos o audios de baja calidad.

Barreras típicas en la web:

• Vídeo sin subtítulos: todo el contenido hablado se pierde.
• Audio o pódcast sin transcripción: no hay forma alternativa de acceder al mensaje.
• Información importante dada solo por sonido (una alerta que "pita" al enviar un formulario) sin equivalente visual.
• Vídeos con subtítulos automáticos de mala calidad, llenos de errores, que confunden más que ayudan.

Escenario Cursalia. Diego es sordo y ve una vídeo-lección del reproductor de Cursalia. El profesor explica un concepto clave hablando a cámara. Sin subtítulos ni transcripción, Diego ve una persona moviendo los labios durante doce minutos: el contenido educativo, que es lo que ha pagado, le resulta inaccesible.

Afectan a la capacidad de moverse y manipular los dispositivos de entrada (ratón, teclado, pantalla táctil). Son muy variadas:

• Movilidad reducida en manos o brazos (por lesión medular, parálisis, artritis, esclerosis…).
• Temblor o falta de precisión (párkinson, temblor esencial): dificulta apuntar y hacer clic en objetivos pequeños.
• Amputación o ausencia de miembros.
• Imposibilidad de usar el ratón, ya sea por lo anterior o por fatiga; muchas de estas personas navegan solo con teclado o con dispositivos alternativos.

El punto común de este grupo: la interacción con precisión y velocidad es difícil o imposible, y a menudo el ratón queda descartado.

Barreras típicas en la web:

• Funciones que solo se activan con el ratón (menús que se abren "al pasar por encima", arrastrar y soltar sin alternativa): quien navega con teclado queda excluido.
• Objetivos táctiles o de clic diminutos o muy juntos: imposibles de acertar con temblor.
• Límites de tiempo para completar tareas (un formulario que "caduca") que no dan margen a quien se mueve más despacio.
• Orden de navegación caótico: si al pulsar Tabulador el foco salta de forma ilógica, recorrer la página se vuelve agotador.

Escenario Cursalia. Lucía tiene una lesión medular y navega solo con teclado. Quiere matricularse. Llega al formulario tabulando, rellena los campos… pero el desplegable para elegir la forma de pago solo se abre al hacer clic con el ratón, y el botón final "Confirmar matrícula" no recibe el foco del teclado. Lucía llega hasta el último paso y no puede terminar. (Veremos esta escena a fondo en 02-03.)

Es el grupo más amplio y diverso, y a menudo el más olvidado porque es "invisible". Afecta a cómo se procesa, comprende, recuerda o atiende la información. Algunos ejemplos:

• Dislexia. Dificultad con la lectura y el procesamiento del texto (no con la inteligencia). Bloques largos, tipografías apretadas o justificadas la agravan.
• TDAH. Dificultad para mantener la atención; los elementos que distraen (animaciones, carruseles, anuncios que se mueven) son especialmente perjudiciales.
• Autismo (TEA). Puede implicar sensibilidad a estímulos (sonidos, movimiento, saturación visual) y preferencia por lenguaje literal y predecible; las metáforas o interfaces incoherentes generan confusión.
• Problemas de memoria (incluido el deterioro asociado a la edad): dificultan recordar pasos, códigos o información entre pantallas.
• Discalculia. Dificultad con los números: fechas, precios, códigos, cálculos.

El hilo común: el esfuerzo cognitivo importa. Una interfaz recargada, con lenguaje complejo o pasos impredecibles, excluye a estas personas aunque técnicamente "funcione".

Barreras típicas en la web:

• Texto denso y jerga: instrucciones enrevesadas, párrafos interminables.
• Distracciones: contenido que se mueve, parpadea o se reproduce solo.
• Procesos largos y sin guía: formularios de muchos pasos sin indicar dónde estás.
• Mensajes de error crípticos ("Error 0x24B") que no explican qué hacer.
• Falta de consistencia: que el mismo botón cambie de sitio o de nombre entre páginas.

Escenario Cursalia. Hugo tiene dislexia y TDAH. Hace un cuestionario interactivo del curso. Las preguntas están redactadas con dobles negaciones y frases larguísimas, y a un lado parpadea un banner promocional. Hugo relee cada pregunta tres veces y pierde el foco constantemente: falla no por no saber, sino por cómo está presentado.

Afectan a la capacidad de producir voz de forma clara (mudez, disfemia/tartamudez, secuelas de un ictus, uso de laringe artificial). En la web solían tener poco impacto… hasta la llegada de las interfaces por voz: asistentes, dictado, autenticación por voz, atención al cliente que "solo funciona por teléfono".

Barreras típicas en la web:

• Servicios que exigen hablar como único método (por ejemplo, verificación por voz) sin alternativa escrita.
• Soporte solo telefónico sin chat, correo o formulario.
• Suponer que todo el mundo puede usar comandos de voz.

Escenario Cursalia. Aisha no puede hablar con claridad tras una operación. Tiene una duda sobre su matrícula y la única vía de contacto que ofrece Cursalia es un teléfono. Si existiera un chat o un foro/formulario de soporte, Aisha resolvería su problema de forma autónoma.

Aquí incluimos condiciones que no encajan limpiamente arriba pero son muy relevantes para la web:

• Epilepsia fotosensible. Ciertos destellos, parpadeos o patrones en pantalla pueden desencadenar una crisis epiléptica. Es de las pocas barreras que no solo excluyen, sino que pueden provocar un daño físico real.
• Trastorno vestibular / sensibilidad al movimiento. Animaciones amplias, efectos de parallax o transiciones bruscas pueden causar mareo o náuseas.
• Fatiga y dolor crónicos, que reducen el tiempo y la energía disponibles para tareas complejas.

Barreras típicas en la web:

• Contenido que destella más de tres veces por segundo (riesgo de crisis).
• Animaciones grandes imposibles de detener.
• Ausencia de respeto a la preferencia del sistema de reducir el movimiento.

Escenario Cursalia. Nora tiene un trastorno vestibular. La landing de Cursalia abre con un vídeo de fondo a pantalla completa con zoom continuo y transiciones deslizantes. A los pocos segundos Nora se marea y cierra la pestaña: nunca llegará a ver el catálogo.

Recuperamos el modelo de la lección 01-02: casi toda limitación permanente tiene equivalentes temporales y situacionales que le ocurren a cualquiera. Diseñar para la primera resuelve también las otras dos, y por eso la accesibilidad beneficia al 100% de los usuarios. Aplicado grupo a grupo:

La lectura clave: cuando ponemos subtítulos "para Diego" (sordo, permanente), también ayudamos a quien tiene otitis (temporal) y a quien estudia sin auriculares en el metro (situacional). La accesibilidad no es un caso extremo: es el caso general.

• Pensar solo en la ceguera. Es el ejemplo más citado, pero la ceguera total es una minoría dentro de las discapacidades. La baja visión, las cognitivas y las motrices afectan a muchísimas más personas y se olvidan con frecuencia.
• Olvidar las discapacidades invisibles. Dislexia, TDAH, autismo o problemas de memoria no se ven, pero condicionan enormemente el uso de la web.
• Ignorar lo temporal y situacional. Reduce la accesibilidad a "una minoría" y debilita el argumentario. Todos seremos usuarios con alguna limitación en algún momento.
• Usar lenguaje que estigmatiza. Prefiere el lenguaje centrado en la persona ("persona con discapacidad", "persona ciega") frente a etiquetas reduccionistas.
• Consejo: ante cada superficie de Cursalia, pregúntate "¿y si el usuario no puede ver / oír / usar el ratón / procesar texto complejo?". Esas cuatro preguntas cubren la mayoría de las barreras.

Ejercicio 1. Clasifica cada situación en el grupo de discapacidad afectado (visual, auditiva, motriz, cognitiva, del habla o neurológica) e indica la barrera concreta:

1. Un usuario no puede distinguir qué campos del formulario están marcados como obligatorios porque solo se señalan en rojo.
2. Un usuario sufre un mareo intenso al entrar en la landing por un fondo animado.
3. Un usuario no logra pulsar el pequeño botón "Confirmar" porque le tiemblan las manos.

Ejercicio 2. Para el reproductor de vídeo-lección de Cursalia, nombra una barrera que afecte a: (a) una persona sorda, (b) una persona ciega, (c) una persona con TDAH.

Ejercicio 3. Toma la barrera "el catálogo transmite la disponibilidad de un curso solo con color (verde = plazas libres, rojo = completo)". Aplica el modelo permanente/temporal/situacional: da un beneficiario de arreglarlo en cada categoría.

Solución 1.

1. Visual (daltonismo): la información se da solo por color; quien no distingue el rojo no sabe qué campos son obligatorios.
2. Neurológica (sensibilidad al movimiento / vestibular): la animación de fondo provoca mareo y no se puede detener.
3. Motriz (temblor): el objetivo de clic es demasiado pequeño para acertarlo sin precisión.

Solución 2. (a) Sorda: el vídeo no tiene subtítulos ni transcripción, así que pierde todo lo hablado. (b) Ciega: los controles del reproductor (play, volumen) no están etiquetados o no se pueden usar sin ver, y no hay descripción de lo que ocurre en pantalla. (c) TDAH: elementos que distraen alrededor del vídeo (banners en movimiento, reproducción automática del siguiente) dificultan mantener la atención.

Solución 3. Arreglar el "solo color" (añadiendo también una etiqueta de texto como "Completo") beneficia a: permanente = persona con daltonismo; temporal = alguien con fatiga visual que percibe mal los matices de color esa tarde; situacional = quien mira el catálogo en el móvil bajo el sol, donde los colores se lavan.

Hemos recorrido el mapa humano de la accesibilidad: las discapacidades visuales, auditivas, motrices, cognitivas, del habla y neurológicas, qué implica cada grupo y qué barreras encuentra en la web —siempre a alto nivel, porque el "cómo se arregla" llega en los módulos 3 a 5—. Hemos visto que casi ninguna es un caso extremo: el modelo permanente / temporal / situacional demuestra que diseñar para estas personas mejora la experiencia de todos, y lo hemos ilustrado con Marta, Diego, Lucía, Hugo, Aisha y Nora en Cursalia.

Pero estas personas no acceden a la web a mano descubierta: se apoyan en herramientas que traducen el contenido a un canal que sí pueden usar —voz, braille, ampliación, comandos de voz—. Esas herramientas son las tecnologías de asistencia, y son el tema de la siguiente lección, 02-02: Visión General de Tecnologías de Asistencia. Conocerlas es imprescindible, porque nuestro código deberá "hablar" con ellas.