WCAG 2.2 para colegios: qué debe revisar tu web educativa

Una familia intenta matricular a su hija desde el móvil. El botón de “Solicitar información” queda tapado al navegar con teclado, el formulario no explica los errores y el documento de admisiones no se entiende con lector de pantalla. La web del colegio funciona para parte de las familias, pero deja fuera a otras.

Revisar WCAG 2.2 colegios no consiste en convertir la web en un proyecto técnico interminable. Consiste en detectar las barreras que afectan a la información, la captación y la relación diaria con alumnos y familias.

Las WCAG son las pautas internacionales que ayudan a que una web pueda ser utilizada por personas con discapacidad visual, auditiva, motora, cognitiva o del aprendizaje. Para un colegio, una academia o una escuela de negocios, estas pautas aterrizan en situaciones muy concretas: pedir una visita, consultar el menú escolar, descargar una autorización o acceder al campus.

Además, la accesibilidad ya no es una cuestión secundaria. La Directiva Europea de Accesibilidad, conocida como EAA, es aplicable desde el 28 de junio de 2025 para los servicios privados incluidos en su ámbito. En España, la Ley 11/2023 incorpora esta directiva. Por su parte, los centros públicos deben atender al Real Decreto 1112/2018 y a la norma EN 301 549.

Esta guía explica qué revisar primero, qué cambia con WCAG 2.2 y cuándo conviene pasar de una revisión inicial a una auditoría profesional. El objetivo no es prometer una conformidad mágica, sino ayudarte a priorizar con criterio.

Qué significa aplicar WCAG 2.2 en la web de un colegio

Aplicar WCAG 2.2 significa diseñar, publicar y mantener una web que pueda percibirse, manejarse, comprenderse y utilizarse con tecnologías de apoyo. Estos cuatro principios se conocen como POUR: perceptible, operable, comprensible y robusto.

La versión 2.2 de las Web Content Accessibility Guidelines incorpora criterios nuevos sobre foco visible, tamaños de objetivos táctiles, autenticación y formularios. Es la versión más reciente publicada por el W3C y una referencia recomendable para mejorar una web educativa. (Fuente: W3C, WCAG 2.2)

Conviene hacer una distinción importante. El marco técnico de la EAA se apoya en la EN 301 549, que actualmente referencia WCAG 2.1 nivel AA. Por tanto, WCAG 2.2 no sustituye de forma automática el estándar legal citado por la norma europea. Sin embargo, seguir WCAG 2.2 permite trabajar con una pauta más actual y prevenir barreras que ya son habituales en móviles y formularios complejos.

Piensa en estas pautas como las señales, rampas y pasillos de un edificio escolar. Una rampa no sustituye el mantenimiento del edificio, pero hace posible que más personas lleguen a clase. De la misma forma, los requisitos de accesibilidad web colegio eliminan obstáculos en el camino digital que lleva a una familia desde Google hasta la matrícula.

Para empezar por la base, puede ser útil revisar qué es la accesibilidad web en un colegio. Así podrás distinguir entre una mejora estética y una barrera que impide completar una acción esencial.

Los requisitos WCAG web colegio que tienen mayor impacto

Una revisión útil no empieza por cada detalle del código. Empieza por las tareas que alumnos, familias y futuros estudiantes realizan en tu web. Después, se comprueba si esas tareas pueden completarse con distintos dispositivos, configuraciones y formas de navegación.

En una web educativa, estos son los requisitos WCAG web colegio que suelen afectar antes a la experiencia diaria:

• Contraste entre texto y fondo: los avisos de matrícula, horarios y botones deben leerse con claridad, incluso con baja visión o bajo la luz exterior.
• Texto alternativo en imágenes: las imágenes informativas necesitan una descripción que un lector de pantalla pueda transmitir. Una foto decorativa, en cambio, no requiere una descripción extensa.
• Navegación con teclado: menús, desplegables, formularios y botones deben poder usarse sin ratón.
• Jerarquía de encabezados: títulos y subtítulos ordenados ayudan a localizar rápidamente “Admisiones”, “Becas” o “Contacto”.
• Formularios comprensibles: cada campo debe tener una etiqueta clara, instrucciones visibles y mensajes de error que expliquen qué corregir.
• Vídeos y contenidos multimedia: los vídeos institucionales, clases abiertas o jornadas de puertas abiertas deben incluir subtítulos cuando haya información sonora relevante.

La prioridad no es corregir todos los problemas a la vez. Primero hay que proteger los recorridos críticos: contacto, solicitud de visita, matrícula, pago, acceso al campus y descarga de información académica. Un carrusel visual poco accesible importa, pero un formulario de admisión inutilizable importa más.

También conviene vigilar los documentos enlazados desde la web. Un PDF de normas de convivencia o una autorización puede ser esencial para una familia. La web y los documentos no son el mismo problema técnico, aunque ambos forman parte de la experiencia digital. Cuando la accesibilidad documental exige una gestión continua y evidencias específicas, una solución independiente como Stally puede cubrir esa capa especializada.

Cómo revisar una web educativa sin perderse en criterios técnicos

La forma más práctica de revisar WCAG 2.2 en colegios es combinar una comprobación automática con pruebas de uso y una priorización clara. Un escáner localiza incidencias repetidas; una revisión humana detecta si el recorrido tiene sentido para una persona real.

Inclusif recomienda una ruta de tres capas para evitar dos errores frecuentes: confiar solo en una herramienta automática o intentar revisar toda la norma sin saber por dónde empezar.

1. Detecta errores repetidos con un escáner

Un escáner puede identificar elementos sin texto alternativo, contrastes insuficientes, encabezados mal estructurados o enlaces poco descriptivos. Esta primera capa sirve para obtener visibilidad y ordenar problemas. También permite comparar el estado de varias páginas sin abrirlas una a una.

2. Prueba los recorridos que importan a las familias

Después, recorre la web sin usar el ratón. Pulsa la tecla Tab, abre el menú, llega al formulario y trata de enviarlo. Si no sabes dónde está el foco, si un menú no se cierra o si un botón no se puede activar, hay una barrera que un informe automático puede no explicar bien.

3. Prioriza por impacto, no por cantidad

Finalmente, separa las incidencias que bloquean una acción de las que solo mejoran la presentación. Un error en la página de contacto suele tener más impacto que una imagen decorativa sin descripción. Esta priorización ayuda al coordinador TIC a presentar un plan razonable a dirección, incluso cuando no dispone de presupuesto ni equipo técnico propio.

Si quieres partir de datos reales, puedes analizar gratis la accesibilidad de la web de tu centro. El resultado inicial no sustituye una auditoría manual, pero sí permite abrir una conversación concreta sobre prioridades, riesgos y siguientes pasos.

WCAG 2.2 colegios: los criterios nuevos que conviene conocer

WCAG 2.2 añade criterios que responden a problemas muy comunes en webs modernas: controles pequeños en móvil, focos que quedan ocultos y pasos repetitivos en formularios. No hace falta memorizar sus números para tomar buenas decisiones, pero sí entender qué experiencia protegen.

Estos criterios son especialmente útiles para una web escolar con menús extensos, formularios de admisión, áreas privadas y contenidos vistos desde móvil:

• Foco no oculto (2.4.11, nivel AA): cuando una persona navega con teclado, el elemento activo no puede quedar escondido detrás de una cabecera fija, un aviso de cookies o un chat.
• Movimientos de arrastre (2.5.7, nivel AA): si una acción exige arrastrar un elemento, debe existir una alternativa sencilla. Esto afecta a calendarios, selectores o interfaces interactivas.
• Tamaño mínimo de objetivo (2.5.8, nivel AA): botones, enlaces e iconos deben tener un área táctil suficiente. Un icono diminuto para descargar una circular no es cómodo para nadie.
• Ayuda coherente (3.2.6, nivel A): el teléfono, el correo o el acceso a soporte deben aparecer en un lugar consistente cuando se repiten entre páginas.
• Entrada redundante (3.3.7, nivel A): la web no debería pedir de nuevo un dato que ya ha recogido, salvo que sea necesario por seguridad o verificación.
• Autenticación accesible (3.3.8, nivel AA): el acceso a áreas privadas no debe depender de pruebas cognitivas difíciles, como recordar información sin una alternativa accesible.

Estos puntos son relevantes, pero no deben eclipsar los fundamentos de WCAG 2.1: estructura semántica, contraste, teclado, formularios, alternativas textuales y mensajes de error. Una web no mejora porque un botón sea más grande si el proceso de inscripción sigue siendo imposible con lector de pantalla.

Por eso, la recomendación es clara: usa WCAG 2.2 como una mejora práctica sobre una base sólida. No lo conviertas en una lista aislada ni en una excusa para rediseñar todo el sitio.

Qué puede resolver un widget y qué requiere una auditoría

Un widget de accesibilidad puede mejorar la experiencia de navegación de muchas personas. Por ejemplo, permite ajustar contraste, tamaño de texto, espaciado, tipografía o resaltado de enlaces. Para una familia que necesita adaptar la lectura, estas opciones pueden marcar una diferencia inmediata.

Sin embargo, un widget no corrige por sí solo la estructura interna de una web. No puede garantizar que un formulario tenga etiquetas correctas, que un vídeo disponga de subtítulos adecuados o que un lector de pantalla interprete bien un menú construido de forma incorrecta. Tampoco convierte automáticamente todos los contenidos del centro en conformes con WCAG.

Esta diferencia importa porque el cumplimiento no se demuestra solo con una capa visual. La organización debe poder acreditar que trabaja activamente la accesibilidad, publica una declaración cuando corresponde y ofrece un canal para comunicar barreras. En el sector público, el RD 1112/2018 establece requisitos específicos sobre declaración y mecanismo de comunicación. (Fuente: BOE, Real Decreto 1112/2018)

Un enfoque razonable para un colegio privado, una academia o una escuela de negocios combina tres piezas: una capa de personalización para el usuario, escaneos periódicos para detectar incidencias y una auditoría profesional cuando hay procesos complejos, varios sitios o barreras que requieren revisión manual.

La auditoría cobra más sentido si tu centro tiene un campus virtual, micrositios de campañas, procesos de pago, portales de empleo o formularios largos. En esos casos, el problema no es solo técnico: afecta a la relación con familias, candidatos y alumnos.

Plan de acción para mejorar la accesibilidad sin rehacer la web

La mayoría de colegios no necesita empezar de cero. Necesita un plan que reduzca barreras, distribuya responsabilidades y permita demostrar avances. Rehacer la web solo tiene sentido cuando su arquitectura o tecnología impide corregir problemas esenciales.

Empieza por inventariar las páginas y acciones de mayor impacto. Incluye la portada, admisiones, contacto, precios si los publicas, becas, noticias, formularios, documentos descargables y el acceso al campus. Después, asigna una persona responsable de revisar los resultados y coordinarse con la agencia o proveedor web.

A continuación, aplica este orden de trabajo:

• Analiza las páginas principales y registra los fallos detectados.
• Corrige primero las barreras que impiden navegar, entender o enviar formularios.
• Revisa con teclado los recorridos de información y admisión.
• Actualiza plantillas y componentes para no repetir el mismo error en cada página.
• Publica y mantén la declaración de accesibilidad cuando corresponda.
• Programa revisiones periódicas, especialmente tras rediseños, nuevas campañas o cambios de plataforma.

Este método también evita que la accesibilidad dependa de una única persona. Si cambia el coordinador TIC o la agencia, el centro conserva un proceso, informes y prioridades documentadas. Para completar la revisión, puedes apoyarte en este checklist de accesibilidad web para centros educativos y en la guía sobre cómo cumplir la accesibilidad web sin rehacer tu sitio.

Revisar WCAG 2.2 colegios con este enfoque permite avanzar sin falsas promesas. No se trata de marcar una casilla y olvidarse del tema, sino de hacer que la información académica y los procesos digitales sigan estando disponibles para todas las personas.

Si tu web incluye recorridos complejos o necesitas una revisión que vaya más allá del escáner, contacta con un especialista en auditoría de accesibilidad web. Un análisis profesional puede ayudarte a priorizar correcciones, coordinar a tu proveedor web y preparar una base sólida para tu declaración de accesibilidad.

---

Preguntas frecuentes sobre WCAG 2.2 para colegios

¿Es obligatorio cumplir WCAG 2.2 en un colegio?

WCAG 2.2 es la versión más reciente de las pautas del W3C y una referencia recomendable. En la normativa europea, la EAA se apoya técnicamente en EN 301 549 y WCAG 2.1 AA. Los centros públicos deben atender además al RD 1112/2018. La obligación concreta depende de la titularidad y los servicios prestados.

¿Qué páginas debe revisar primero una web educativa?

Prioriza las páginas que permiten realizar acciones esenciales: contacto, solicitud de visita, admisiones, matrícula, pagos, becas, acceso al campus y descargas obligatorias. Después revisa las plantillas de noticias, eventos y páginas institucionales. Corregir estas rutas suele mejorar tanto la accesibilidad como la experiencia de las familias.

¿Un escáner garantiza que mi colegio cumple WCAG?

No. Un escáner detecta muchos errores técnicos repetidos y es un buen punto de partida, pero no interpreta todos los contextos de uso. Por ejemplo, puede no detectar si un texto alternativo describe bien una imagen o si un formulario resulta comprensible. Las pruebas manuales y una auditoría completan el análisis.

¿Necesito rehacer mi web para cumplir los requisitos WCAG web colegio?

Normalmente, no. Muchas barreras se corrigen ajustando plantillas, textos, formularios, contraste o componentes existentes. Un rediseño solo es necesario si la tecnología actual impide resolver problemas fundamentales. Lo recomendable es analizar primero el estado real de la web y priorizar cambios por impacto.