Accesibilidad en LMS y cursos: criterio de producto con WCAG 2.2

Un sistema de gestión del aprendizaje (LMS, por sus siglas en inglés) accesible no garantiza un curso accesible. Puede tener navegación por teclado, contraste correcto y un informe de conformidad convincente, y aun así entregar una actividad imposible de terminar. Basta un icono diminuto para borrar una respuesta, una pregunta que obliga a arrastrar, un vídeo sin subtítulos, un documento sin estructura o una herramienta externa que pierde el foco.

Por eso la accesibilidad de una plataforma de aprendizaje no debe evaluarse mirando solo su interfaz. La unidad que importa es el recorrido completo. La persona debe poder entrar, localizar el curso, comprender el contenido, realizar la actividad, corregir un error, entregar y recibir confirmación. Para las páginas y procesos web incluidos en el alcance, las Pautas de accesibilidad para el contenido web (WCAG) 2.2, en su nivel AA, proporcionan un suelo verificable. El criterio profesional empieza al decidir cómo se traduce ese suelo a componentes, autoría, contratación y pruebas continuas.

La diferencia no es retórica. Afecta a quién firma la aceptación, qué se pregunta a un proveedor y cuándo se detiene una publicación. Una declaración general no basta si desconoce el tema instalado, los complementos, el contenido del curso o las integraciones. Tampoco basta una herramienta automática. Puede encontrar un botón sin nombre, pero no demostrar que un alumno comprende el error de una evaluación ni que conserva su respuesta al pedir más tiempo.

Si una sola etapa impide terminar la tarea, que las demás superen sus comprobaciones no permite aceptar el recorrido completo.

La unidad de accesibilidad es el recorrido completo

En una plataforma de aprendizaje hay al menos seis capas que pueden introducir una barrera, aunque las demás estén bien resueltas:

1. El componente: botones, menús, campos, pestañas, mensajes y cuadros de diálogo.
2. La plantilla: navegación del curso, jerarquía de páginas, cabeceras, regiones y adaptación a móvil o ampliación.
3. La herramienta de autor: lo que permite crear y lo que impide publicar sin nombre, estructura, alternativa o instrucciones suficientes.
4. El contenido: texto, imágenes, documentos, audio, vídeo y recursos descargables.
5. La actividad: cuestionarios, simulaciones, foros, tareas, intentos, límites de tiempo y retroalimentación.
6. La integración: reproductores, clases virtuales, laboratorios, paquetes SCORM —un modelo para empaquetar contenido y comunicar su ejecución con el LMS— y conexiones LTI —un estándar para integrar herramientas con la plataforma—.

Basta que un solo paso bloquee la tarea para que el recorrido completo no sea accesible. Si el LMS permite llegar al cuestionario con teclado pero exige arrastrar cada respuesta, una parte del alumnado no puede completarlo. «Parcialmente accesible» no describe ese resultado. Si el editor pide texto alternativo para una imagen pero acepta un PDF escaneado como material obligatorio, la prevención se ha quedado a medio camino.

Esta forma de mirar cambia el reparto de responsabilidades. Los equipos de diseño y desarrollo especifican y corrigen los componentes. El equipo de producto define los recorridos y acepta sus estados, mientras que el de formación crea las plantillas y revisa el contenido. El área de compras comprueba el alcance de la evidencia y el equipo de pruebas recorre el conjunto. El proveedor corrige el producto que entrega, pero no puede declarar accesible el documento que sube el cliente ni una extensión que no ha evaluado.

La primera decisión de gobierno es sencilla: definir recorridos esenciales e indicar, para cada paso e integración, quién acepta el resultado y quién corrige los defectos. «Completar un curso obligatorio», «entregar una evaluación» o «consultar la retroalimentación» son objetos comprobables. «Mejorar la accesibilidad» no lo es.

Abrir la imagen a tamaño completo

WCAG 2.2 es el suelo, no la especificación del producto

WCAG 2.2 organiza la accesibilidad alrededor de cuatro principios: el contenido y la interfaz deben ser perceptibles, operables, comprensibles y robustos. Sus criterios de conformidad se distribuyen en los niveles A, AA y AAA. Para alcanzar el nivel AA, cada página completa del alcance debe satisfacer todos los criterios A y AA, o disponer de una versión alternativa conforme. Si una página forma parte de un proceso, todas las páginas de ese proceso deben alcanzar el nivel declarado.

Esto último importa en formación. Una matrícula, una evaluación o una entrega son procesos: no se pueden seleccionar solo las pantallas fáciles y excluir el paso que falla. También importa el límite de la norma. Incluso la conformidad AAA no cubre todas las necesidades de todas las personas. WCAG permite afirmar algo concreto y auditable; no sustituye conocer las necesidades y condiciones de uso del alumnado ni decidir el diseño pedagógico.

Conviene separar dos columnas en los requisitos:

Ese segundo nivel no debe disfrazarse de requisito normativo. Es una recomendación profesional; si el equipo la adopta, pasa a ser una regla de producto. Así se evita afirmar que WCAG exige lo que en realidad ha decidido el equipo y, a la vez, se impide usar el mínimo como techo.

El criterio 2.5.8 cambia cómo se construye un componente

El criterio 2.5.8, tamaño mínimo del objetivo (Target Size (Minimum)), pertenece al nivel AA de WCAG 2.2. Para acciones con puntero, exige que dentro de la zona de activación quepa por completo un cuadrado de 24 por 24 píxeles CSS, alineado con los ejes de la página, salvo que se cumpla alguna de sus excepciones. Mide el área que recibe la interacción, no el tamaño visible del icono ni una caja exterior cualquiera.

Un icono de 16 por 16 puede estar dentro de un botón de 44 por 44 y ofrecer una zona de activación cómoda. Un icono de 24 dibujado dentro de un enlace que solo recibe clic sobre el trazo puede fallar. Tampoco basta con pedir a la persona que amplíe la página: el zoom no cambia el tamaño de la zona medido en píxeles CSS.

Las excepciones evitan imponer una caja rígida a cualquier elemento:

• Separación: una zona menor puede cumplir si el círculo de 24 píxeles CSS centrado sobre su caja delimitadora no se cruza con otra zona ni con el círculo equivalente de otra zona pequeña.
• Equivalente: existe en la misma página otro control para la misma función que sí alcanza el mínimo.
• En línea: la zona forma parte de una frase o su tamaño queda condicionado por el texto.
• Control del agente de usuario: el navegador determina el tamaño y el autor no lo modifica.
• Esencial: esa presentación concreta resulta imprescindible o está legalmente exigida para la información transmitida.

Cumplir el criterio mediante la excepción de separación es válido, pero tiene un coste. Obliga a calcular distancias según la geometría de las zonas y se vuelve frágil cuando cambian la traducción, el zoom del texto, la densidad o la disposición. En un sistema de componentes conviene incorporar la zona segura al propio control.

La recomendación profesional que propongo es una zona de activación predeterminada de 44 por 44 píxeles CSS para controles críticos, repetidos o agrupados, aunque el requisito de tamaño AA de 2.5.8 sea que quepa el cuadrado de 24 por 24 o se cumpla una excepción. Si el equipo la adopta, se convierte en una regla de producto. Los 44 por 44 aparecen en 2.5.5, tamaño mejorado del objetivo (Target Size (Enhanced)), que es AAA. No son el requisito general de nivel AA. Como decisión interna, ese umbral ofrece más margen geométrico y unifica la especificación de esos controles; en barras densas, tablas y visualizaciones debe contrastarse con la tarea, la separación disponible y las alternativas equivalentes.

La biblioteca de interfaz puede incorporar ese umbral en sus variantes críticas, pero la regla no demuestra por sí sola la accesibilidad. Las pruebas todavía deben medir la zona de activación real y comprobar superposiciones, reflujo —la redistribución del contenido al estrechar la vista o ampliar el texto—, estados y variantes. Integrar la regla en el componente evita que los equipos tengan que aplicarla de nuevo en cada pantalla; el mismo patrón sirve para el foco, el nombre accesible, los errores y los estados.

La interfaz tiene que funcionar en un entorno de referencia acordado

Un componente accesible no es una captura correcta. Antes de probarlo, el equipo acuerda un entorno de referencia: navegadores, sistemas, dispositivos, idiomas, versiones y tecnologías de apoyo que espera soportar. Es un conjunto mínimo de combinaciones, no una forma de impedir otras. En ese entorno, el componente debe funcionar con teclado, voz, puntero impreciso, ampliación, lector de pantalla, alto contraste y las orientaciones previstas, y conservar su significado cuando el contenido cambia de idioma o crece.

La especificación de una biblioteca de interfaz incluye, como mínimo:

Los estados merecen tanta atención como el estado inicial. Cuando una operación comunica que sigue en curso, ese mensaje debe quedar disponible para las tecnologías de apoyo sin exigir un cambio de foco; una entrega correcta necesita confirmación perceptible. Al cerrar un cuadro de diálogo, el foco vuelve al control que lo abrió o avanza a otro lugar coherente con la tarea. Una sesión que va a caducar permite ampliar el tiempo cuando el criterio correspondiente lo exige. La semántica correcta no compensa que la respuesta desaparezca después de un error.

Las tecnologías de apoyo son programas o dispositivos —como lectores de pantalla, magnificadores o pulsadores adaptados que sustituyen teclas o gestos— que permiten percibir u operar de otra forma. Probar con ellas no consiste en «abrir un lector de pantalla»: hay que indicar navegador, tecnología, versión, recorrido y resultado esperado. Para una tarea esencial, el guion debe llegar hasta el final: localizar el curso, iniciar la actividad, responder, revisar, entregar y confirmar. Si se prueba solo que el botón tiene nombre, se ha comprobado el componente, no que la tarea pueda completarse.

La accesibilidad de un curso empieza también en la herramienta de autor

La accesibilidad del contenido se decide mucho antes de que el equipo de pruebas abra el curso. Una herramienta de autor interviene en dos frentes. Su propia interfaz debe ser accesible para docentes y editores; además, debe ayudarles a producir contenido accesible para el alumnado. Las Pautas de accesibilidad para herramientas de autor (ATAG 2.0) describen esa doble responsabilidad. Para la interfaz y el contenido web, se evalúan junto con la versión de WCAG fijada en el alcance. Así se evita una contradicción habitual: pedir cursos accesibles mediante un editor que no se puede manejar con teclado o que genera marcado deficiente.

Una buena herramienta no se limita a permitir texto alternativo. Presenta estructura real de encabezados, conserva listas y tablas, ofrece plantillas válidas e identifica el idioma. También admite subtítulos y transcripciones, y advierte cuando un enlace no tiene un propósito comprensible. Cuando un dato es obligatorio para evitar una barrera, lo pide en el momento de creación y explica para qué sirve.

Las comprobaciones preventivas deben distinguir entre la ausencia de un dato y su calidad. Se puede detectar que una imagen no tiene alternativa; no se puede decidir automáticamente si «imagen» describe su función. Se puede avisar de una tabla sin encabezados; hace falta juicio para saber si la tabla era el formato adecuado. La herramienta debe bloquear los defectos inequívocos, orientar sobre los dudosos y reservar estos últimos para una revisión humana antes de publicar.

Los criterios de aceptación de un curso cubren, al menos:

• una jerarquía de encabezados que represente la estructura y no el aspecto;
• instrucciones que no dependan solo de posición, forma, sonido o color;
• imágenes con alternativa funcional y decorativas correctamente vacías;
• documentos descargables con orden de lectura, etiquetas y estructura comprobados;
• subtítulos sincronizados para el vídeo, transcripción cuando corresponda y control accesible del reproductor;
• texto comprensible, siglas explicadas y nomenclatura estable;
• enlaces cuyo propósito se entienda dentro de la frase o el bloque donde aparecen;
• ausencia de contenido que parpadee o provoque un riesgo evitable;
• alternativas para recursos de terceros que no alcanzan el nivel exigido.

Una plantilla accesible reduce el trabajo repetido, pero no convierte en accesible cualquier contenido que reciba. Lo mismo ocurre con SCORM: el empaquetado y el intercambio de estado no certifican la interfaz incluida. Si se compra contenido a otra empresa, el objeto que se acepta es cada curso y su reproductor en la instalación real, no la extensión del fichero.

Las actividades y evaluaciones pueden impedir acreditar lo aprendido

Las barreras de una página informativa suelen dificultar la lectura. En una evaluación pueden impedir acreditar el conocimiento. Por eso las actividades necesitan una revisión funcional y pedagógica, no solo un análisis automático del marcado.

Pensemos en casos hipotéticos, pero frecuentes en cualquier catálogo de formación:

La equivalencia no significa ofrecer una actividad más fácil ni medir otra destreza. Si el resultado de aprendizaje es ordenar un procedimiento, los botones de subir y bajar pueden conservarlo. Si la prueba pretende valorar la coordinación motora porque esa destreza es esencial, el análisis cambia. La pregunta previa es qué resultado de aprendizaje se evalúa; la mecánica de la interfaz no debe añadir una capacidad que el curso nunca pretendió medir.

Los intentos, la retroalimentación y la recuperación forman parte de la accesibilidad. Una persona que tarda más en recorrer opciones necesita aviso y posibilidad de ampliar el tiempo cuando el criterio correspondiente lo exige. Quien amplía la pantalla necesita revisar pregunta y respuestas sin desplazamiento imposible. Si una integración falla después de entregar, el sistema debe conservar el trabajo y explicar el estado. Un error técnico no debe convertir una necesidad de acceso en un suspenso.

Comprar accesibilidad exige alcance, método y vigencia

Cuando una empresa busca un LMS accesible, una auditoría de cursos o un proveedor de contenidos, suele encontrar tres tipos de promesa: conformidad genérica, comprobación automática y un informe de producto. Ninguna debe aceptarse sin conocer su alcance.

Un VPAT es la plantilla de ITI para documentar cómo responde un producto a criterios concretos; una vez cumplimentada, el resultado es un ACR, o informe de conformidad de accesibilidad. El ACR es una evidencia útil, no una certificación universal. Hay que leer qué producto y versión evalúa, con qué norma, qué método aplica, qué partes excluye y qué estado registra para cada criterio. En VPAT 2.5, esos estados son Supports (con soporte), Partially Supports (con soporte parcial), Does Not Support (sin soporte) y Not Applicable (no aplicable).

Siete preguntas antes de comprar o renovar

1. ¿Qué producto, versión, tema y aplicaciones cubre el informe?
2. ¿Evalúa WCAG 2.2 AA o una versión anterior?
3. ¿Quién hizo la evaluación y con qué combinación de pruebas?
4. ¿Qué significa cada «con soporte parcial» en tareas reales?
5. ¿Qué queda fuera: contenido del cliente, complementos, LTI, móvil o autoría?
6. ¿Qué plazo y versión de entrega tiene cada corrección, y quién debe realizarla?
7. ¿Podemos ejecutar nuestros recorridos con tecnología de apoyo antes de aceptar?

La instalación real requiere una comprobación propia. Un tema corporativo puede cambiar el contraste y el foco; un complemento puede introducir un selector inaccesible. Una integración LTI puede incorporar o lanzar la interfaz de otra herramienta, a menudo gestionada por otro proveedor. Un curso puede contener documentos y medios que el fabricante del LMS nunca ha evaluado. El informe del núcleo ayuda a acotar el riesgo, pero no se hereda por proximidad.

La compra no se limita a una declaración. W3C sitúa la evaluación de conformidad entre los trabajos previos a adquirir un producto y recomienda combinar método, experiencia técnica de quienes evalúan y participación de personas con discapacidad. Conservar evidencia identificable, repetible y vinculada a una versión ofrece una base técnica; no sustituye el análisis jurídico, contractual y de riesgo que corresponda a cada organización y país.

El contrato con el proveedor debe incluir entregables concretos: matriz de conformidad, defectos conocidos, recorridos probados, tecnologías de apoyo y plan de corrección. También debe fijar tiempos de respuesta, aviso de regresiones y derecho a repetir las pruebas en la instancia configurada. «El producto es accesible» no permite aceptar ni rechazar nada.

La evidencia del producto base no se extiende automáticamente al tema, los complementos, las integraciones ni el contenido del cliente: depende del alcance documentado.

La aceptación se sustenta con una matriz de pruebas

Una evaluación para decidir la aceptación empieza por definir alcance, explorar el sistema, seleccionar una muestra representativa, evaluar y registrar resultados. Para una plataforma de aprendizaje, la muestra no se elige solo por URL: incluye plantillas, tipos de contenido, actividades, estados, roles, dispositivos e integraciones. Además de la muestra, los procesos esenciales se prueban completos.

La muestra sustenta una declaración de resultados de evaluación y una decisión interna de aceptación; no permite por sí sola extender la conformidad al producto completo. Si se formula una declaración formal de conformidad WCAG, su alcance debe cubrir páginas y procesos completos que satisfagan todos los requisitos del nivel declarado. La declaración identifica, como mínimo, la fecha, el título, la versión y la URI de WCAG, el nivel, las páginas exactas y las tecnologías de las que se depende.

La automatización tiene un papel claro: puede detectar defectos repetibles, como un botón sin nombre accesible o ciertos contrastes de texto insuficientes. Después hacen falta una revisión manual, pruebas con teclado y ampliación, una inspección semántica y el uso de tecnologías de apoyo. La participación de personas con discapacidad descubre patrones de uso y problemas que una comprobación de criterios puede no anticipar, pero no reemplaza la evaluación técnica ni debe reducirse a una demostración final.

Esta matriz mínima sirve como mapa para preparar la aceptación; no sustituye la evaluación completa de todos los criterios A y AA:

Cada evidencia debe indicar la fecha, la versión, el alcance, el resultado, el defecto y quién debe corregirlo. Para ejecutar una fila, el caso de prueba debe incluir un identificador, las precondiciones, una combinación concreta del entorno de referencia, los pasos, el resultado esperado y el criterio para resolver discrepancias. Una captura puede ayudar a explicar un contraste; no demuestra un recorrido. Un vídeo facilita la reproducción de la prueba; no sustituye los pasos ni el resultado esperado. El informe final debe permitir repetir la comprobación después de actualizar un tema, un reproductor o una actividad.

La severidad no depende solo del nivel WCAG. La aceptación debe bloquear cualquier defecto que impida matricularse, entrar, comprender una instrucción necesaria, responder, entregar o conocer el resultado, aunque aparezca en una única combinación del entorno de referencia. Después conviene priorizar la frecuencia, el número de personas afectadas, la disponibilidad de una alternativa, la posibilidad de perder datos y el coste de recuperación.

Ocho criterios que pueden bloquear la publicación

La accesibilidad se vuelve operativa cuando puede detener una salida. Estas condiciones son bloqueos adicionales de producto para recorridos esenciales; no sustituyen la evaluación completa de WCAG 2.2 AA. Para publicar un curso o aceptar una versión del LMS deben exigirse estas ocho condiciones:

1. Los recorridos esenciales están definidos de principio a fin y se completan con teclado, salvo la operación cuya modalidad de entrada sea esencial para el resultado de aprendizaje y esté justificada.
2. Ningún foco queda perdido, invisible o completamente oculto, y el orden conserva el sentido.
3. En cada control cabe el cuadrado de 24 por 24 píxeles CSS de 2.5.8 o se justifica una excepción; los controles críticos y repetidos aplican la regla interna de 44 por 44 píxeles CSS, y cualquier excepción a esa regla se justifica por la tarea, la separación o una alternativa equivalente.
4. La página conserva contenido y función al refluir; los mensajes, estados y errores se anuncian y se pueden corregir sin perder trabajo.
5. Imágenes, documentos, audio y vídeo han pasado la revisión correspondiente, no solo el editor automático.
6. Arrastres, límites de tiempo y autenticación satisfacen el criterio correspondiente mediante el mecanismo o la excepción previstos; las tareas visuales ofrecen una alternativa que conserva el propósito cuando procede.
7. Las integraciones y el contenido de terceros se han probado en la instalación real; cada limitación indica quién la acepta, quién la corrige, qué alternativa existe y en qué plazo.
8. La matriz conserva alcance, versiones, tecnologías, evidencias, defectos y decisión de aceptación.

No debe presentarse como conforme una «plataforma» en abstracto. Para la aceptación, el informe debe registrar la versión, la instalación, los recorridos y el contenido evaluados contra WCAG 2.2 AA, además de las reglas de producto aplicadas. Ese informe de resultados no es por sí solo una declaración formal de conformidad. Si se emite una, queda limitada al alcance exacto que satisface todos los requisitos de WCAG. La distinción permite al área de compras comparar resultados, al equipo de pruebas repetirlos y al de formación saber qué revisar antes de publicar.

Descomponer un requisito por capas, responsables y pruebas también sirve para otros requisitos transversales. Si la accesibilidad se escribe como una frase suelta, cada equipo rellena los huecos de forma distinta. La guía sobre qué debe contener una especificación explica cómo convertirla en reglas y criterios verificables. Si la plataforma todavía se está definiendo, conviene empezar por la arquitectura para aprender con IA. Allí se sitúan las responsabilidades, interfaces y límites que deben existir antes de elegir componentes o proveedores.

Si estás diseñando, comprando o renovando una plataforma de aprendizaje, conviene empezar por un solo recorrido esencial y su matriz de aceptación. Si nadie puede aportar la evidencia de una fila, no hay que suavizar la frase: hay que indicar quién debe obtenerla o reconocer que esa parte aún no está lista.

Última revisión: 28 de julio de 2026.

Alberto Lara Hernández trabaja en dirección técnica, arquitectura de software, inteligencia artificial aplicada y plataformas de aprendizaje. Publica análisis para equipos que necesitan convertir requisitos amplios en decisiones, acuerdos y pruebas que sigan siendo defendibles cuando el sistema crece.