Requisitos técnicos SCORM: guía práctica para asegurar compatibilidad, seguimiento y experiencia del alumno

Requisitos técnicos SCORM para contenidos de formación FP/SEPE y normativos

Qué es SCORM y por qué importa en 2025

Si algo he aprendido es que formatos y estándares suenan a chino… hasta que te rechazan un archivo y toca repetir. En e-learning pasa lo mismo: si un PDF mal exportado vuelve de imprenta, mal empaquetado vuelve del LMS en forma de errores de tracking. Los requisitos técnicos SCORM (Sharable Content Object Reference Model) es el “idioma” que usa tu curso para empaquetarse (.zip), comunicarse con el LMS y reportar progreso.

En 2025 siguen conviviendo SCORM 1.2 (por defecto en muchísimos LMS) y SCORM 2004 (más potente para secuenciación), mientras que xAPI y cmi5 ganan peso cuando quieres medir fuera del LMS o escenarios más libres (apps, simuladores, mobile). No es un combate; es elegir la herramienta adecuada para tu proyecto, la infraestructura del cliente y el nivel de analítica que necesitas. Y todo estos contenidos deben respetar un orden y requisitos que veremos a continuación.

Objetivo de esta guía: dejar claro qué exigimos y probamos en cada entrega para que el curso funcione, mida y no te sorprenda en la implantación.

Cuáles son los requisitos técnicos de un paquete SCORM

Un paquete SCORM es un .zip que el LMS interpreta: debe incluir un imsmanifest.xml válido (estructura y punto de lanzamiento), las unidades SCO que se comunican con el LMS y todos los recursos del curso autocontenidos (HTML/CSS/JS y multimedia) con rutas coherentes

¿Qué contiene ese .zip?

En términos generales, el fichero comprimido debe incluir:

  • imsmanifest.xml (el índice):
    El LMS, como Moodle, abre este archivo para saber qué hay dentro, en qué orden y qué archivo debe abrir primero. También incluye metadatos (título, idioma, autor, versión), por eso es fundamental.

  • SCOs (las “unidades” del curso):
    Son las pantallas o módulos que se comunican con el LMS (en este caso, serán mensajes tipo: “completado”, “nota”, “tiempo”, etc.).

  • Recursos (los materiales):
    Páginas HTML, estilos CSS, scripts JS, imágenes, vídeos, audios y fuentes. Todo lo que el curso necesita para funcionar y lo que el alumno ve.

  • Navegación (cómo te mueves dentro del curso):
    Todo lo que compone la arquitectura del curso: botones Siguiente/Anterior, menús y, si hace falta, reglas (ej.: “no puedes hacer el Módulo 2 hasta aprobar el 1”).

Buenas prácticas básicas

De una forma sencilla y sin tecnisismos, a la hora de pensar en un curso bien realizado, se debe pensar en:

  • Nombres limpios y coherentes:
    Usa minúsculas y guiones: modulo-1/index.html (evita mezclar Index.html, INDEX.HTML, etc. porque algunos sistemas lo interpretan distinto).

  • Incluir todo “dentro”:
    Evita depender de archivos externos en internet. Si la conexión falla, el curso debe seguir funcionando (de otro modo se correría el riesgo de perder información valiosa).

  • Versiones a la vista:
    Incluye la versión en el nombre del paquete y/o en los metadatos: curso-onboarding_v1-3.zip. Así todos saben qué subieron.

  • Metadatos claros:
    Como mínimo: título, descripción, idioma y autor bien puestos. Ayuda a buscar el curso dentro del LMS y a saber qué es sin abrirlo.

Ejemplo rápido

Subes onboarding_v1-2.zip al LMS.
Dentro está imsmanifest.xml que dice: “El curso empieza en index.html, tiene 3 módulos (SCOs) y se completa al aprobar el test”.
El alumno entra, completa el test y el SCO le envía al LMS: completado + nota + tiempo.

Run-Time API en SCORM 1.2: lo mínimo que debe funcionar

1. Qué partes se comunican entre sí durante la ejecución del curso

    • LMS: la plataforma (Moodle, Canvas…) donde se sube y registra el curso.
    • SCO (Shareable Content Object ): tu curso/lección (una página web en HTML/JS) dentro del paquete SCORM.
    • Run-Time API: el “teléfono” JavaScript que el LMS ofrece para que el SCO guarde datos.

Flujo mínimo en 5 pasos (para que el LMS “te escuche”)

  1. Encontrar la API
    El SCO busca el objeto JavaScript del LMS (normalmente en la ventana padre).
    Si no lo encuentra, no habrá tracking.

  2. Abrir sesión → LMSInitialize("")
    Inicia la comunicación.
    Sin esto, el LMS ignora todo lo que envíes.

  3. Leer/escribir datos → LMSGetValue(...) / LMSSetValue(...)

    • Leer: estado previo, nombre del alumno, etc.
      Ej.: LMSGetValue("cmi.core.lesson_status")

    • Escribir: progreso/nota/tiempo.
      Ej.: LMSSetValue("cmi.core.score.raw","85")

  1. Guardar → LMSCommit("")
    “Guarda ahora lo que acabo de escribir.”
    Piensa en pulsar “Guardar” en un documento.

  2. Cerrar sesión → LMSFinish("")
    Cierra limpio.
    Si cierras la pestaña sin LMSFinish, podrías perder datos.

3. ¿Qué datos mínimos conviene manejar en 1.2?

  • Estado: cmi.core.lesson_status → completed / incomplete / passed / failed.

  • Puntuación: cmi.core.score.raw (0–100 típico).

  • Tiempo: cmi.core.session_time (lo que dura la sesión actual) y el LMS acumula en cmi.core.total_time.

  • Salida: cmi.core.exit (p. ej., suspend si el alumno se va a mitad para reanudar luego).

  • Progreso extra: cmi.suspend_data (un pequeño “bloc de notas” para guardar estado interno del curso: qué pantallas vio, respuestas, etc.).

Idea clave: estado + nota + tiempo ya explican gran parte de lo que pasa. Si eso falta, nadie entiende por qué el alumno abandona.

4. Un ejemplo mental (con un poquito de código)

Supongamos un curso de 10 pantallas. Consideramos “completado” si llega a la 10 y aprueba un quiz al 70%.

// 1) Encontrar la API (simplificado)
function findAPI(win) {
try {
while (win && !win.API && win.parent && win.parent !== win) win = win.parent;
return win.API || null;
} catch (e) { return null; }
}
var API = findAPI(window);

// 2) Check-in
if (API) {
API.LMSInitialize(«»);

// 3) Leer estado previo (por si reanuda)
var prevStatus = API.LMSGetValue(«cmi.core.lesson_status»); // e.g., «incomplete»
// … restaurar interfaz según suspend_data si existe …

// Durante el curso vamos guardando progreso:
API.LMSSetValue(«cmi.suspend_data», JSON.stringify({ pantalla: 7 }));
API.LMSCommit(«»); // 4) Guardar

// Al finalizar:
var score = 85;
API.LMSSetValue(«cmi.core.score.raw», score.toString());
API.LMSSetValue(«cmi.core.lesson_status», score >= 70 ? «passed» : «failed»);
API.LMSCommit(«»);

// 5) Check-out
API.LMSFinish(«»);
}

No necesitas ser programador: quédate con la idea de inicializar → escribir datos → guardar → finalizar.

5. Secuencia visual (qué pasa tras bambalinas)

SCO (curso) API/JS del LMS LMS (servidor)
| busca API -------------------------------> [expuesta en ventana]
|-- LMSInitialize("") -----------------------> abre sesión
|-- LMSSetValue("cmi.core.score.raw","85") -> marca 85
|-- LMSSetValue("cmi.core.lesson_status","passed")
|-- LMSCommit("") ---------------------------> guarda en base de datos
|-- LMSFinish("") --------------------------> cierra sesión

6. Errores típicos (y cómo evitarlos)

  • “No encuentro la API”
    Suele ser por abrir el curso en otra pestaña/ventana bloqueada por el navegador o porque el SCO no mira en la ventana correcta (padre/opener).
    Solución: abrir el SCO como recomienda tu LMS y usar una búsqueda de API robusta.

  • Datos que no se guardan
    Faltó LMSCommit, el curso crasheó antes de Finish, o hay contenido mixto (HTTPS + recursos HTTP).
    Solución: llamar a Commit en puntos clave (fin de módulo/quiz) y asegurar todo en HTTPS.

  • Reanudación no funciona
    No se usa cmi.core.exit = "suspend" ni suspend_data para recordar el punto.
    Solución: al salir a medias, poner exit = "suspend" y guardar un pequeño JSON en suspend_data.

  • Pop-ups bloqueados / SameSite
    El SCO no puede “ver” la API si el navegador aísla la cookie o bloquea la ventana.
    Solución: lanzar el curso como indica el LMS, evitar redirecciones raras y revisar políticas de cookies.

7. ¿Qué debo probar sí o sí?

  • ✅ Se llama a LMSInitialize al abrir y a LMSFinish al cerrar.

  • ✅ score.raw, lesson_status y session_time cambian como espero y se ven en los informes del LMS.

  • ✅ Salgo en mitad del curso → vuelvo y reanuo donde estaba (gracias a exit = "suspend" + suspend_data).

  • ✅ Hago Commit después de eventos importantes (fin de tema, quiz).

  • ✅ El curso carga sin bloqueos (pop-ups, contenido mixto, CORS/SameSite).

Checklist de requisitos técnicos antes de publicar

Esta es la “lista roja” que usamos en cada entrega. Si algo no aplica, lo validamos contigo.

Navegador y ventana

  • Ventana emergente o incrustada sin bloqueos (políticas de pop-ups y SameSite).

  • Todas las URLs en HTTPS (evitar contenido mixto).

  • Sin dependencias obsoletas (Flash, APIs no soportadas).

Comunicación con el LMS

  • LMSInitialize/Commit/Finish llamados en los momentos correctos.

  • Retries prudentes si la API tarda en estar disponible (p.ej., prueba en window.parent/opener).

  • Guardado de estado en suspend_data compacto (evitar romper límites del LMS).

Contenido

  • HTML5/CSS/JS ligero; nada de librerías pesadas innecesarias.

  • Imágenes optimizadas (WebP/JPG progresivo), fuentes con subset.

  • Botones de navegación consistentes (siguiente/anterior/finalizar).

Reporting

  • Estados y puntuación configurados (pasar/completar) según criterios de aceptación.

  • Reanudación probada: salir → volver → conservar progreso.

  • Informes del LMS: el curso aparece con título correcto y agrupa intentos.

Si un SCORM mal empaquetado te “rompe” el seguimiento, es casi lo mismo que un PDF sin sangrado: todo vuelve para atrás.

Medición para reducir el abandono

Tu hipótesis es clave: sin medición, hay abandono. Traducimos esto en reglas prácticas:

KPIs mínimos

  • % de finalización por intento (status).

  • Tiempo medio por usuario (total_time).

  • % que alcanza el umbral de aprobado (score ≥ X).

  • “Puntos de fuga”: pantalla/tema tras el que más gente se va (se infiere por tiempo + eventos internos).

Automatiza decisiones

  • Si lesson_status = incomplete y total_time < 5 min → recordatorio por email al día siguiente.

  • Si score.raw < umbral en 2 intentos → sugerir refuerzo (FAQ o microlección).

  • Si session_time medio cae en móvil → revisar peso de vídeos o navegación en responsive.

Cuadro de mando (básico)

  • Finalización, Tiempo, Nota, Dispositivo (si el LMS lo reporta), Intentos, Última visita.

  • Segmentos: grupo, cohorte y dispositivo para detectar fricción.

SCORM 1.2 vs SCORM 2004 (y mirada a xAPI/cmi5)

Qué cambia entre 1.2 y 2004, cuándo elegir cada uno y cuándo dar el salto a xAPI/cmi5.

SCORM 1.2

  • Simple, ubicuo, rápido de implantar.

  • Modelo de datos más reducido; sin secuenciación avanzada.

  • Ideal para cursos lineales, evaluaciones simples y despliegues “sin sorpresas”.

SCORM 2004 (ed. 3/4)

  • Secuenciación y navegación basadas en reglas (requisito/condición, objetivos).

  • Modelo de datos más amplio (objetivos, interacciones con más detalle).

  • Útil cuando necesitas rutas no lineales y control fino del flujo didáctico.

xAPI (Tin Can)

  • Traza eventos arbitrarios (“actor, verbo, objeto”) dentro y fuera del LMS.

  • Requiere LRS (Learning Record Store) y diseño de statements.

  • Recomendado si tu proyecto es multi-canal, móvil o con simulaciones.

cmi5

  • Define cómo arrancar y controlar cursos xAPI desde un LMS.

  • Ideal cuando quieres lo mejor de ambos mundos: lanzamiento LMS + tracking xAPI.

Decisión práctica

  • Por defecto: SCORM 1.2.

  • Necesitas reglas de avance complejas: SCORM 2004.

  • Quieres medir fuera del LMS o experiencias ricas: xAPI (+cmi5 si arrancas desde LMS).

Validación rápida en Moodle u otros LMS

He usado Moodle como usuario y lo esencial es tener un sandbox. Nuestro flujo:

  1. Subir .zip (PIF) en un curso de pruebas.

  2. Abrir el SCO y comprobar el debug SCORM (si el LMS lo ofrece) para ver Initialize/Commit/Finish.

  3. Forzar intentos: completar, fallar, salir a medias… y revisar status/nota/tiempo en informes.

  4. Validar reanudación: cerrar pestaña a mitad, volver y continuar.

  5. Confirmar visibilidad de informes al rol que corresponda (tutor/admin).

Compatibilidad e-learning (resumen operativo unificado)

Este es el marco operativo que usamos para asegurar que tu curso sube, trackea y reporta igual en los LMS habituales. Partimos de SCORM 1.2 por robustez y ampliamos a 2004/xAPI/cmi5 según tu escenario.

  • SCORM: 1.2 (por defecto) y 2004 ed. 3/4 bajo pedido.
    Datos mínimos: cmi.core.lesson_status, cmi.core.score.raw, cmi.core.session_time y uso prudente de cmi.suspend_data (el límite efectivo lo impone cada LMS).

  • xAPI / Tin Can (opcional): diseñamos statements y trabajamos con el LRS del cliente.

  • cmi5: recomendado cuando se lanza desde LMS pero se quiere telemetría xAPI.

  • Pruebas de aceptación: carga del paquete, tracking, finalización e informes.

  • Entorno de validación: usuario de test y sandbox/staging del cliente.

Idea clave: entregamos en 1.2 por robustez; si necesitas reglas avanzadas o reporting ampliado, evaluamos 2004/xAPI/cmi5 según tu LMS.

Contenidos e-learning

¿Necesitas contenidos SCORM para plataformas de e-learning?

Realizamos contenidos educativos (cursos, tests y recursos) bajo normativa, validados y compatibles con LMS como Moodle.

Quiero contenidos SCORM y xAPI
Contenidos educativos de calidad

Accesibilidad digital (nivel AA por defecto)

La accesibilidad digital garantiza que cualquier persona pueda usar los contenidos en condiciones equivalentes. El nivel de referencia suele ser WCAG 2.1 AA, complementado con estándares documentales como PDF/UA cuando hay archivos PDF.

  • WCAG 2.1 AA: navegación por teclado, foco visible, etiquetas accesibles, contraste mínimo, subtítulos/transcripciones, compatibilidad con lectores de pantalla.

  • Documentos accesibles: PDF/UA con etiquetas semánticas, orden de lectura y marcadores.

  • Multimedia: SRT para vídeo, alternativas textuales en imágenes y audio-descripción si aplica.

  • QA accesibilidad: validación automatizada + revisión humana (muestras representativas, teclado real, lector de pantalla).

Formatos y entrega digital

  • HTML5/CSS/JS: sin dependencias obsoletas; sólo librerías necesarias.

  • ePub 3 (cuando procede): metadatos, tabla de navegación, fuentes incrustadas.

  • Rendimiento: imágenes optimizadas, subset de fuentes, lazy-loading donde tenga sentido.

  • Paquetizado: ZIP firmado/etiquetado con versión y changelog.

Artes finales e imprenta (para los proyectos editoriales)

Vengo “curtido” de rechazos por temas de color y exportación, así que aquí no improvisamos:

  • Color: perfiles CMYK/ICC (FOGRA39/51 según papel/maqueta).

  • Sangrados y lomo: +3 mm mínimo; cálculo de lomo por gramaje y paginación.

  • Tipografías: licencias embebidas o alternativas libres; si el cliente lo solicita, entregamos licencias.

  • Imágenes: 300 ppp a tamaño final, TIFF/PNG; vector en SVG/PDF.

  • Preflight: PDF/X-1a o PDF/X-4, fuentes incrustadas, sobreimpresión y transparencias controladas.

Seguridad y cumplimiento

  • Propiedad intelectual ajustada a contrato (cesiones y alcance).

  • Recursos con licencia verificada (guardamos evidencias).

  • Datos personales: no usamos datos reales en demos/ejemplos.

QA y criterios de aceptación (checklist)

Digital

  • Tracking correcto (estado/nota/tiempo).

  • Accesibilidad AA mínima.

  • Enlaces internos/externos verificados.

  • Responsive funcional.

Editorial

  • Ortotipografía, paginación sin viudas/huérfanas, estilos y rejilla coherentes.

  • Preflight PDF/X sin errores.

Opcional: entregamos Checklist de aceptación (PDF) de 1 página, para que tu equipo marque “ok” punto por punto.

Entregables por defecto

Documentación: README técnico, changelog, guía rápida de subida (LMS/imprenta).
Archivos

  • Digital: SCORM 1.2/2004 o xAPI, HTML5/ZIP, ePub3, PDF accesible.

  • Editorial: InDesign (.indd/.idml), paquetes vinculados, PDF/X.

Soporte y mantenimiento

  • Soporte post-entrega: X días laborables para incidencias de integración.

  • Mantenimiento: bolsas de horas para actualizaciones, mejoras de accesibilidad, cambios de LMS o de plataforma.

Conclusión

Tener claros los requisitos técnicos SCORM y un proceso de QA sólido evita devoluciones, acelera la implantación y, sobre todo, mejora la experiencia del alumno. En mi experiencia, cuando mides lo esencial (estado, nota, tiempo) y cuidas accesibilidad y rendimiento, la tasa de finalización sube y los tickets bajan.

Artículos relacionadas

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Scroll al inicio