En una institución privada, una plataforma de capacitación poco accesible es una mala práctica que afecta a algunos colaboradores. En una institución pública, es un problema distinto: el mandato de servir a toda la ciudadanía y a toda la fuerza laboral estatal, sin excepción, convierte la accesibilidad digital en una obligación que ya no depende de la buena voluntad del área de TI o de comunicaciones, sino de un estándar técnico exigible. Cada vez más marcos regulatorios en la región toman como referencia técnica las pautas WCAG (Web Content Accessibility Guidelines), y eso tiene consecuencias muy concretas para cualquier plataforma de formación que use o construya una entidad pública.
El estándar de referencia: por qué AA parcial ya no alcanza
La versión vigente de las pautas, WCAG 2.2, organiza los requisitos en cuatro principios —perceptible, operable, comprensible y robusto— y en niveles de conformidad A, AA y AAA. El nivel AA es, en la práctica, el estándar mínimo que toman como referencia la mayoría de los marcos legales y normativos alrededor del mundo, incluidos los que inspiran regulación en América Latina. El problema que vemos con frecuencia no es que las instituciones ignoren el estándar, sino que lo cumplen de forma parcial: corrigen el contraste de color porque es visible a simple vista, pero dejan sin resolver los criterios que requieren pruebas técnicas más profundas, como la navegación completa por teclado o la compatibilidad real con lectores de pantalla. Un cumplimiento parcial no es cumplimiento; es una plataforma que funciona para algunos usuarios con discapacidad y excluye a otros con la misma condición legal de acceso.
Dónde suele fallar una plataforma de capacitación pública
En las auditorías que hemos realizado sobre plataformas LMS de instituciones públicas, los mismos problemas se repiten con sorprendente regularidad:
- Documentos PDF no accesibles: manuales y guías escaneados como imagen, sin etiquetado semántico, ilegibles para un lector de pantalla aunque el texto sea visible para el ojo humano.
- Video sin subtítulos ni transcripción: contenido audiovisual que excluye tanto a personas con discapacidad auditiva como a quienes consumen el curso en entornos sin audio, un caso de uso mucho más común de lo que se asume.
- Navegación que depende exclusivamente del mouse: menús, formularios de evaluación y reproductores de video que no pueden operarse con teclado, lo que bloquea por completo a usuarios con limitaciones motrices.
- Configuración por defecto del LMS sin revisar: plantillas de curso instaladas tal como vienen del proveedor, sin verificar que el tema visual, los formularios y los componentes interactivos cumplan realmente los criterios de accesibilidad que el proveedor anuncia en su ficha técnica.
Accesibilidad también es cobertura real, no solo discapacidad
En el contexto de instituciones públicas de la región, la accesibilidad digital se cruza con una segunda dimensión que rara vez aparece en el debate: la cobertura real de la fuerza laboral estatal. Servidores públicos en oficinas descentralizadas con conectividad limitada, dispositivos de gama baja o alfabetización digital desigual enfrentan barreras de acceso muy similares en su efecto práctico a las que enfrenta una persona con discapacidad visual frente a un curso mal etiquetado: ambos quedan fuera de una capacitación que, en el papel, estaba disponible para todos. Diseñar pensando en accesibilidad —contenido liviano, alternativas de bajo ancho de banda, interfaces simples y predecibles— termina beneficiando a una base de usuarios mucho más amplia que el grupo que motivó originalmente el requisito legal.
Una hoja de ruta realista para instituciones públicas
Corregir esto de una sola vez en todo un catálogo es poco realista con los presupuestos típicos del sector público. Una secuencia que sí funciona:
- Auditar antes de rediseñar: una evaluación técnica contra WCAG 2.2 sobre la plataforma y los cursos de mayor uso, no sobre el catálogo completo desde el primer día.
- Priorizar por alcance, no por facilidad: corregir primero los cursos obligatorios de mayor audiencia (inducción, cumplimiento, seguridad) antes que contenido de nicho, aunque este último sea técnicamente más simple de corregir.
- Construir plantillas accesibles por defecto: en lugar de auditar curso por curso de forma indefinida, invertir en una plantilla base de autor de cursos que cumpla el estándar, de modo que todo contenido nuevo nazca conforme.
- Capacitar a quienes producen contenido, no solo al equipo técnico: gran parte de las fallas de accesibilidad se originan en decisiones de quien diseña el curso —una imagen sin texto alternativo, un color de bajo contraste—, no en el motor técnico del LMS.
Conclusión
La accesibilidad digital en la capacitación del sector público dejó de ser un criterio deseable para convertirse en una condición de cumplimiento normativo y, sobre todo, en una condición de cobertura real de la fuerza laboral y la ciudadanía a las que la institución sirve. El estándar técnico —WCAG 2.2 en su nivel AA— ya existe y es claro; lo que falta en la mayoría de los casos no es voluntad, sino una hoja de ruta que priorice con criterio y evite tratar la accesibilidad como un proyecto aislado en lugar de una práctica incorporada desde el diseño del curso.