Lanzamiento de WCAG 2.2: qué cambia y cómo adaptarte

Publicado el 14/06/2025

Web Content Accessibility Guidelines 2.2

La accesibilidad web no es una opción, es una responsabilidad. Con el reciente lanzamiento de las WCAG 2.2 (Web Content Accessibility Guidelines), nos encontramos ante una nueva etapa en la evolución de los estándares internacionales de accesibilidad digital. Esta actualización, publicada por el World Wide Web Consortium (W3C), trae consigo una serie de nuevas pautas que buscan ampliar la inclusión digital, en especial para usuarios con discapacidades cognitivas, de movilidad o baja visión.

En este artículo analizaremos de forma detallada qué cambia con WCAG 2.2, cuáles son sus nuevos criterios, cómo se relaciona con versiones anteriores y, sobre todo, cómo podemos adaptarnos de manera efectiva a estos cambios. Si tu sitio web ya cumple con WCAG 2.1 o WCAG 2.0, estás en buen camino, pero aún queda trabajo por hacer.


¿Qué es WCAG y por qué es importante su versión 2.2?

Las WCAG son un conjunto de normas y recomendaciones desarrolladas por el W3C que definen cómo hacer que el contenido web sea más accesible para personas con discapacidad. Estas pautas son utilizadas por diseñadores, desarrolladores, organizaciones e incluso entidades gubernamentales de todo el mundo para garantizar el acceso equitativo a la información y la interacción digital.

De WCAG 2.0 a 2.1: el camino hacia una web más inclusiva

Desde la publicación de WCAG 2.0 en 2008, el panorama tecnológico y las necesidades de los usuarios han evolucionado significativamente. En 2018, se lanzó WCAG 2.1, añadiendo criterios enfocados en usuarios móviles, personas con baja visión y discapacidades cognitivas.

Con WCAG 2.2, el W3C da un paso más hacia la inclusión, con el objetivo de cubrir aún más escenarios y hacer que la accesibilidad sea un componente fundamental del diseño digital moderno.

¿Qué hace diferente a WCAG 2.2?

Lo que distingue a esta nueva versión es su énfasis en la usabilidad práctica y su enfoque en grupos de usuarios previamente subrepresentados. Si bien sigue manteniendo los cuatro principios fundamentales –Perceptible, Operable, Comprensible y Robusto (POUR)–, incorpora nueve nuevos criterios de éxito, algunos de los cuales son obligatorios para alcanzar el nivel AA, el más comúnmente exigido en normativas legales.


Cambios clave introducidos por WCAG 2.2

Ahora que sabemos por qué WCAG 2.2 es relevante, veamos en detalle qué ha cambiado respecto a su versión anterior. Esta actualización incluye nuevos criterios de éxito, la eliminación de uno anterior, y mejoras en la claridad del lenguaje técnico.

Criterio eliminado

  • 4.1.1 Parsing (Nivel A): Este criterio, presente en WCAG 2.0 y 2.1, fue eliminado en la versión 2.2 debido a su falta de aplicabilidad actual y a la evolución de las tecnologías web modernas, que hacen que este requisito sea redundante.

Nuevos criterios en WCAG 2.2

2.4.11 Enfoque no oculto (Nivel AA)

El contenido al recibir foco (como al navegar con el teclado) no debe quedar oculto por otros elementos como cabeceras fijas o ventanas emergentes. Asegura que los usuarios puedan ver claramente dónde están.

2.4.12 Enfoque no oculto mejorado (Nivel AAA)

Este es un criterio más estricto que el anterior. Además de que el foco no quede oculto, se debe garantizar que el elemento enfocado esté completamente visible en la ventana gráfica.

2.4.13 Apariencia del foco (Nivel AA)

Establece que el indicador de foco debe ser claramente visible y tener suficiente contraste con el fondo. Esto ayuda especialmente a usuarios que navegan solo con teclado.

2.5.7 Alvo táctil mínimo (Nivel AAA)

Para interfaces táctiles, los objetivos interactivos deben tener un tamaño mínimo de 24x24 píxeles CSS, con márgenes apropiados, a fin de evitar errores al tocar.

2.5.8 Activación por arrastre (Nivel AA)

Cuando una acción requiere arrastrar un objeto (drag and drop), debe existir una alternativa accesible mediante simple pulsación o interacción con teclado.

3.2.6 Consistencia de ayuda (Nivel A)

Este criterio establece que si se ofrece ayuda (como chat en vivo, número de teléfono, o sección de ayuda), debe mantenerse disponible de forma consistente en todas las páginas del sitio.

3.3.7 Validación redundante de entrada (Nivel A)

Cuando un usuario introduce datos incorrectos, el sitio no debe depender exclusivamente de una sola forma de validación, como un mensaje de color. Es necesario proporcionar mensajes de error claros, visibles y comprensibles.

3.3.8 Asistencia en la corrección (Nivel AA)

Se refiere a proporcionar sugerencias claras para corregir errores en formularios, como completar campos requeridos o utilizar el formato correcto para una fecha.

3.3.9 Autenticación accesible (Nivel AA)

Los métodos de autenticación no deben requerir memorizar información compleja. Se deben ofrecer alternativas accesibles como autenticación con dispositivo o mediante patrones repetibles.


Cómo adaptar tu sitio a WCAG 2.2 paso a paso

1. Evalúa tu estado actual

Antes de implementar cambios, es fundamental auditar tu sitio web actual. Si ya cumple con WCAG 2.1 AA, muchas de las bases están cubiertas. Puedes utilizar herramientas como:

  • WAVE (WebAIM)
  • Axe DevTools
  • Lighthouse (de Google)
  • TAW (del Centro Tecnológico de la UNED)

Analiza en especial elementos como el foco del teclado, mensajes de error, tamaño de botones táctiles y la disponibilidad de ayuda.

2. Ajusta tus hojas de estilo (CSS)

Muchos criterios nuevos implican cambios visuales. Por ejemplo:

  • Asegúrate de que el foco de teclado tenga un grosor y color perceptible.
  • Verifica el tamaño de los botones en pantallas táctiles.
  • Añade clases accesibles para mostrar mensajes de error con aria-live.

3. Mejora la interacción con formularios

Revisa cada formulario para que:

  • Los errores se comuniquen claramente con texto, no solo con colores.
  • Haya sugerencias visibles sobre cómo corregir errores.
  • Se ofrezca una autenticación alternativa si se requiere login.

4. Diseña pensando en la consistencia

Si tienes un botón de ayuda en tu página principal, asegúrate de que también esté presente en secciones como contacto, tienda o preguntas frecuentes. La ayuda debe ser fácil de encontrar en todo momento.

5. Involucra a usuarios reales

No hay mejor forma de probar la accesibilidad que involucrando a personas con discapacidad en tus pruebas de usabilidad. Esto te permitirá detectar problemas reales que las herramientas automáticas no identifican.


¿Qué impacto tendrá WCAG 2.2 a nivel legal?

Regulaciones actuales

En muchos países, el cumplimiento con las WCAG es un requisito legal. Por ejemplo:

  • En la Unión Europea, la European Accessibility Act exige el cumplimiento de WCAG 2.1 AA (pronto 2.2).
  • En Estados Unidos, la sección 508 del Acta de Rehabilitación toma como referencia las WCAG.
  • En Latinoamérica, países como México, Argentina y Colombia han comenzado a incluir normativas similares.

¿WCAG 2.2 será obligatoria?

Aunque por ahora muchas legislaciones aún mencionan WCAG 2.1, es solo cuestión de tiempo para que WCAG 2.2 se convierta en el nuevo estándar legal. Por lo tanto, cuanto antes te adaptes, más preparado estarás para evitar sanciones, demandas o exclusiones de usuarios.


Conclusión

La llegada de WCAG 2.2 no debe verse como una carga adicional, sino como una oportunidad de evolucionar hacia una web más justa e inclusiva. Adaptarse a estos nuevos criterios no solo mejorará la accesibilidad de tu sitio, sino que también enriquecerá la experiencia general de todos los usuarios, sin importar sus capacidades.

Como creadores de contenido digital, tenemos la responsabilidad ética y profesional de garantizar que nadie quede excluido. Y con WCAG 2.2, contamos con una guía clara para lograrlo.

Implementar estos cambios puede parecer un reto, pero también es una señal de que estamos avanzando. Avanzando hacia una web en la que todos puedan participar con equidad, libertad y dignidad.

Comentarios (0)

Inicia sesión para comentar.

No hay comentarios aún. Sé el primero en comentar!