Lo que WCAG 2.2 AA exige realmente a una plataforma de aprendizaje

Si tu plataforma de aprendizaje presta servicio al público, a una administración, a una universidad o a empleados de la Unión Europea, la accesibilidad ha dejado de ser algo deseable. Ahora es una obligación legal con fechas concretas, y algunos plazos están lo bastante cerca como para importar este año.

Este artículo explica qué significa realmente que una plataforma sea accesible, quién debe cumplir y cuándo, dónde suelen fallar estos productos y la diferencia real de coste entre integrar la accesibilidad desde el principio y añadirla después de recibir una reclamación. Está pensado para quien toma la decisión de construir o comprar, no para un responsable de cumplimiento, así que reduciremos al mínimo el lenguaje normativo. Es una guía práctica, no asesoramiento jurídico: confirma tus obligaciones concretas con un profesional.

La versión corta

El estándar al que apuntan casi todas las leyes es WCAG, las Web Content Accessibility Guidelines, en el nivel de conformidad AA. WCAG tiene tres niveles: A es el mínimo, AA es el que exigen los reguladores y AAA es un objetivo ambicioso que rara vez se impone por completo.

La versión actual es WCAG 2.2, publicada a finales de 2023. Muchas leyes siguen nombrando la 2.1 porque se redactaron antes de que apareciera la 2.2. La buena noticia es que la 2.2 incluye casi todo lo anterior y añade varios criterios especialmente relevantes para los productos educativos. Construir para WCAG 2.2 AA es el objetivo sensato: satisface las reglas actuales y se adelanta a las siguientes.

La accesibilidad no es una función que se añade. Es una propiedad de cómo se construye cada pantalla, formulario e interacción. Ese hecho explica casi todo lo demás, incluido por qué cuesta poco al principio y mucho al final.

Quién debe cumplir y cuándo

No hay una única regla global. Hay varias, y más de una puede aplicarse a la misma plataforma.

Hay varios matices importantes.

El plazo del sector público estadounidense es el que tiene cuenta atrás. El Departamento de Justicia fijó fechas firmes bajo el Título II de la ADA. Las entidades públicas grandes tenían hasta abril de 2026 y las pequeñas hasta abril de 2027. Si vendes a distritos escolares, community colleges o universidades estatales, tus compradores están pendientes de ese reloj y sus equipos de compras preguntan hoy.

Las empresas privadas no quedan libres. La ADA no contiene una frase que diga que un sitio web debe cumplir WCAG. Sin embargo, los tribunales han considerado repetidamente cubiertos los sitios y aplicaciones de empresas privadas, y el referente práctico es WCAG AA. Aquí la presión no llega como fecha, sino como requerimiento de un bufete. La edtech es un objetivo frecuente porque su público incluye a estudiantes con discapacidad.

La UE amplió el alcance en junio de 2025. Las universidades públicas ya estaban cubiertas. El Acta Europea de Accesibilidad extiende las obligaciones a muchos servicios digitales privados para consumidores. Si vendes acceso a cursos online a personas de la UE, no des por hecho que estás fuera.

El patrón es el mismo estándar, WCAG AA, que llega por distintas puertas. Construye una vez para él y responderás a todas.

WCAG en lenguaje claro: cuatro preguntas

WCAG se organiza en cuatro principios, resumidos por POUR en inglés: perceptible, operable, comprensible y robusto. Sin jerga, plantea cuatro preguntas.

• Perceptible. ¿Puede una persona recibir el contenido por más de un sentido? Un vídeo necesita subtítulos para quien no lo oye y una transcripción para quien usa lector de pantalla. Una imagen con significado necesita descripción.
• Operable. ¿Se puede utilizar sin ratón? Botones, menús, cuestionarios y controles de vídeo deben funcionar solo con el teclado.
• Comprensible. ¿Es claro y predecible? Las etiquetas dicen lo que hacen, los errores explican cómo corregirlos y la interfaz no cambia de forma inesperada.
• Robusto. ¿Funciona con tecnología de asistencia? La página debe permitir que un lector anuncie correctamente qué es cada control, cómo se llama y en qué estado se encuentra.

Cada criterio específico concreta una de estas preguntas. Casi cualquier fallo de auditoría se remonta a una de ellas.

Dónde fallan realmente las plataformas de aprendizaje

Una plataforma hace cosas que una web comercial no hace: reproduce vídeo, lanza exámenes cronometrados, integra contenidos externos y mantiene sesiones interactivas largas. Estos son los puntos que fallan una y otra vez.

Vídeo y audio sin subtítulos ni transcripción. Es el fallo más común del e-learning y un incumplimiento claro del nivel A. Los subtítulos automáticos son un comienzo, pero no bastan para terminología técnica, nombres propios o habla con acento.

Temporizadores que no se pueden ajustar. Una cuenta atrás fija que el alumno no puede ampliar o apagar incumple el criterio sobre límites de tiempo. También discrimina a quien usa un lector de pantalla o necesita más tiempo. La accesibilidad y la equidad se encuentran en la evaluación; por eso conviene leer cómo diseñar evaluaciones resistentes a las trampas.

Preguntas de arrastrar y soltar que exigen ratón. Las actividades de emparejar y ordenar suelen cerrarse por completo a algunos alumnos si no ofrecen alternativa de teclado. WCAG 2.2 añadió un criterio específico que exige una alternativa al gesto de arrastre.

Estado comunicado solo mediante color. Un punto verde para «completado» y uno rojo para «atrasado» no comunica nada a quien no los distingue. El color puede reforzar un estado, pero no ser su único vehículo.

Texto con poco contraste sobre colores de marca. El gris claro o el blanco sobre tonos pálidos incumplen a menudo la relación exigida. Es uno de los resultados más frecuentes de cualquier escáner automático y suele nacer de una decisión de diseño sin comprobar el contraste.

Componentes personalizados sin nombre ni función. Barras de progreso, acordeones, pestañas y modales construidos con elementos genéricos pueden no decir nada útil a un lector. El alumno oye «botón» sin saber qué hace, o ni siquiera lo encuentra. Es el principio Robusto fallando en la práctica.

Trampas de teclado y foco invisible. Si alguien puede entrar con Tab en el reproductor o en una ventana pero no salir, queda atrapado. Si el diseño oculta el indicador de foco, no sabe dónde se encuentra.

El contenido dentro del contenido. La plataforma puede ser accesible y el paquete SCORM, el cuaderno PDF o las diapositivas integradas no serlo. Un lector no puede interpretar un PDF sin etiquetas ni un módulo SCORM mal creado. El cumplimiento solo es tan fuerte como el contenido menos accesible que sirves, y buena parte de esto es contenido, no código.

Pruebas de acceso y objetivos táctiles diminutos. WCAG 2.2 añadió reglas relevantes: la autenticación no debe obligar a resolver una prueba de memoria o un puzle, y las zonas interactivas deben ser suficientemente grandes para pulsarlas de forma fiable, especialmente en móvil.

El coste real: integrarla o añadirla después

La realidad que pocos proveedores explican es esta: la accesibilidad es barata cuando forma parte de la construcción y cara cuando se convierte en una reparación.

La razón es estructural. Vive en los componentes: marcado semántico, etiquetas correctas, gestión del foco y subtítulos dentro del flujo de contenido. Si el equipo adopta esos hábitos desde el primer componente, el coste adicional es pequeño y consiste sobre todo en disciplina y pruebas. Se integra en el coste normal de construir bien.

La adaptación posterior es otro proyecto. Un botón puede estar reutilizado en cuarenta pantallas. Arreglar el componente mejora las cuarenta, pero obliga a probarlas todas, además de cada tipo de pregunta, modal y página cuyo orden de foco nunca se consideró. No estás añadiendo una función; estás reabriendo los cimientos de un sistema con usuarios reales, la peor posición desde la que negociar un plazo legal.

Es la misma lección de la seguridad de los datos de estudiantes: las propiedades arquitectónicas son baratas antes de lanzar y caras después. Ambas fallan silenciosamente porque, cuando funcionan, son invisibles y pierden prioridad frente a lo que el cliente puede ver, hasta el día en que su ausencia se vuelve pública. Si te planteas construir, la accesibilidad pertenece al alcance inicial y forma parte de lo que determina el precio de una plataforma e-learning.

Cómo comprobar tu situación ahora mismo

No necesitas una auditoría formal para obtener una primera lectura sincera. Cuatro pasadas descubrirán la mayoría de los problemas.

1. Ejecuta un análisis automático. axe, WAVE o la comprobación de Lighthouse detectan contraste, etiquetas ausentes y estructura en minutos. Tómalo como suelo, no como veredicto: las herramientas solo encuentran entre un tercio y la mitad de los problemas reales.
2. Guarda el ratón. Completa una lección y un cuestionario solo con teclado: Tab para moverte, Intro y Espacio para activar, flechas en menús. Si te atascas o te pierdes, a un usuario de teclado le ocurrirá igual.
3. Activa un lector de pantalla. VoiceOver viene con cada Mac y NVDA es gratuito en Windows. Cierra los ojos e intenta recorrer una lección. La primera vez resulta incómoda y enseña más que cualquier informe.
4. Comprueba por separado la capa de contenido. Abre un SCORM, un PDF y un vídeo representativos y revisa si cada uno tiene subtítulos o etiquetas y se puede navegar por sí solo.

Si compras en vez de construir, añade un quinto paso: pide al proveedor su VPAT, también llamado Accessibility Conformance Report. Declara, criterio a criterio, cómo cumple el producto. Un proveedor que no puede presentar uno, o que afirma conformidad perfecta sin matices, dice mucho en ambos casos.

Lo que el «cumplimiento» aporta y lo que no

Cumplir WCAG 2.2 AA reduce la exposición legal y, sobre todo, abre la plataforma aproximadamente a una de cada seis personas en el mundo que vive con una discapacidad importante. Es una parte enorme de cualquier público de aprendizaje.

No garantiza, sin embargo, una buena experiencia. Una plataforma puede superar cada punto y seguir siendo torpe con tecnología de asistencia. La lista es el suelo, no el techo. Tampoco es un certificado que se consigue una vez: cada función, contenido o integración externa puede romperlo. Los buenos equipos tratan la accesibilidad como una parte permanente de cómo diseñan y revisan, no como una limpieza puntual.

La conclusión es la misma que en seguridad y datos. Las propiedades que protegen a usuarios y negocio son decisiones arquitectónicas que se toman pronto, mientras siguen siendo baratas. O integras la accesibilidad en los cimientos ahora, o pagarás por reconstruirlos después bajo el plazo de otra persona.