Novedades en WCAG 2.2: Cambios y actualizaciones respecto a WCAG 2.1

Las Pautas de Accesibilidad para el Contenido Web(opens in a new tab) (WCAG) proporcionan un marco para crear contenido digital accesible para todos los usuarios y conforme a las principales leyes de accesibilidad. Seguir las WCAG ayuda a garantizar que todo el mundo pueda utilizar tu contenido digital, amplía tu alcance y reduce el riesgo legal. 

A medida que la industria de la accesibilidad y la tecnología siguen evolucionando, también lo hacen las directrices WCAG. La última versión, publicada en octubre de 2023, impulsa los estándares de accesibilidad digital. A continuación, desglosamos las novedades de WCAG 2.2 y cómo aplicar estas actualizaciones a tu contenido digital.

Una serie de cuatro símbolos de accesibilidad que se desvanecen en la distancia, sobre un fondo degradado de arco iris.

¿Qué es WCAG 2.2?

Publicadas por el World Wide Web Consortium(opens in a new tab) (W3C), las WCAG son estándares internacionales que explican cómo hacer que los sitios web y el contenido digital sean accesibles para personas con discapacidad. El W3C publicó originalmente las WCAG el 5 de mayo de 1999. A medida que las experiencias digitales evolucionan y se vuelven más sofisticadas, el W3C actualiza las directrices tras rigurosas revisiones, numerosas rondas de cambios y aportaciones del público(opens in a new tab). Desde su publicación, el W3C ha anunciado tres versiones de las directrices, cada una basada en la anterior.

Cada versión de las WCAG contiene criterios de éxito organizados en tres niveles de conformidad:

• Nivel A: El nivel mínimo de conformidad, el Nivel A contiene criterios de éxito básicos para eliminar barreras graves de accesibilidad que afectan a un amplio abanico de usuarios. 

• Nivel AA: El criterio de éxito de Nivel AA elimina barreras adicionales y establece un nivel de accesibilidad que funciona para la mayoría de las personas con discapacidad y tecnologías de apoyo, incluidos los lectores de pantalla. 

• Nivel AAA: El nivel más estricto de conformidad, el Nivel AAA, incluye criterios de éxito adicionales para establecer el mayor nivel posible de accesibilidad. Declarar conformidad con el Nivel AAA significa que tu sitio cumple todos los criterios de éxito de las WCAG.

Icono de accesibilidad con la etiqueta 2.1 junto a un icono de accesibilidad con la etiqueta 2.2

¿Cuál es la diferencia entre WCAG 2.1 y 2.2?

La principal diferencia entre WCAG 2.1 y WCAG 2.2 es el enfoque. Desde octubre de 2025, WCAG 2.2 es el estándar actual de accesibilidad del W3C(opens in a new tab), y pone mayor énfasis en la usabilidad —especialmente en la navegación por teclado, las interacciones táctiles y la accesibilidad cognitiva— manteniendo los requisitos existentes de WCAG 2.1.

Los nuevos criterios de éxito de WCAG 2.2 abordan barreras comunes que los usuarios siguen encontrando en experiencias digitales reales, como indicadores de foco ocultos, interacciones solo de arrastrar, objetivos táctiles pequeños, ubicación inconsistente de la ayuda y flujos de autenticación inaccesibles.

Estas actualizaciones mejoran la accesibilidad en sitios web, aplicaciones móviles, documentos en línea y otros contenidos digitales, manteniendo la alineación con los cuatro principios de las WCAG: el contenido debe ser perceptible, operable, comprensible y robusto. 

También es importante destacar que WCAG 2.2 no sustituye a las versiones anteriores de las directrices. Todos los criterios de éxito de WCAG 2.1 (y WCAG 2.0) permanecen sin cambios y siguen siendo plenamente aplicables, ya que WCAG 2.2 simplemente amplía esa base.

Nuevos criterios de éxito de WCAG 2.2 explicados

Con una mejor comprensión de cómo WCAG 2.2 difiere de las versiones anteriores, veamos los nuevos criterios en WCAG 2.2(opens in a new tab).

2.4.11 Foco no oculto (Mínimo)

Este criterio(opens in a new tab) garantiza que el indicador visual de foco de teclado (como un borde o resaltado) sea parcialmente visible para los usuarios. Añadir un indicador de foco asegura que los usuarios puedan localizar e interactuar con el componente enfocado, como botones o enlaces. 

Al diseñar con cabeceras fijas, elementos adhesivos o modales, asegúrate de que el foco del teclado no quede detrás de la interfaz que lo obstruye. Los desarrolladores pueden usar JavaScript para desplazar los elementos al área visible usando ‘.scrollIntoView({block:”nearest”})’ u otros métodos similares. El CSS también debe evitar diseños fijos que cubran elementos interactivos sin reposicionarlos dinámicamente. 

2.4.12 Foco no oculto (Mejorado)

Sobre el requisito mínimo, el criterio mejorado(opens in a new tab) exige indicadores visuales aún más robustos para los estados de foco. Requiere que todo el elemento enfocado sea completamente visible, sin quedar oculto de ninguna manera. Esto anima a los diseñadores a usar elementos que destaquen significativamente, mejorando la visibilidad y claridad de los elementos enfocados. 

Para cumplir este requisito, los desarrolladores deben crear interfaces que siempre desplacen el elemento enfocado completamente al área visible. Evita la visibilidad parcial o la superposición de componentes de la interfaz. Usa JavaScript como ‘.scrollIntoView({block:”center”})’ o implementa lógica personalizada de desplazamiento que garantice un objetivo enfocado totalmente visible en todos los tamaños y orientaciones de pantalla.

2.4.13 Apariencia del foco

El criterio 2.4.13(opens in a new tab) exige que el indicador visible para cualquier componente de la interfaz cumpla requisitos mínimos de tamaño y contraste. Los indicadores deben ser al menos tan grandes como un borde de 2 píxeles de grosor alrededor del componente y deben contrastar con los colores adyacentes en una proporción de 3:1. 

Al crear indicadores de foco, utiliza estilos de foco visibles que no dependan únicamente de contornos sutiles o sombras. Por ejemplo, un contorno sólido de 2 píxeles con contraste de color suficiente o un resaltado de fondo cumple con los estándares de conformidad. Además, evita eliminar los contornos del foco con ‘outline: none’ a menos que se aplique una alternativa más accesible. 

2.5.7 Movimientos de arrastre

El criterio 2.5.7(opens in a new tab) exige que las acciones de arrastre realizadas por los usuarios sean accesibles. Por ejemplo, cuando un usuario arrastra un elemento para reordenarlo o interactúa con un control deslizante, deben existir métodos alternativos (como botones) para quienes no puedan realizar la acción. 

Los desarrolladores deben garantizar que estos movimientos admitan métodos de entrada alternativos como la interacción por teclado (por ejemplo, flechas o botones para mover elementos) o entrada por escritura. Por ejemplo, los usuarios pueden hacer clic en flechas para mover un elemento de una lista en lugar de requerir arrastrar y soltar. Esto ayuda a personas con movilidad reducida que pueden tener dificultades con movimientos precisos del puntero. 

2.5.8 Tamaño del objetivo (Mínimo)

Los elementos interactivos, como botones y enlaces, deben tener un tamaño mínimo de objetivo(opens in a new tab) para garantizar que puedan ser fácilmente pulsados o clicados. Los objetivos más grandes reducen la probabilidad de errores y mejoran la experiencia para los usuarios de tecnologías de apoyo. El criterio recomienda que los objetivos interactivos tengan al menos 24 por 24 píxeles CSS, salvo que haya suficiente espacio alrededor o se apliquen excepciones específicas. 

Para cumplir este requisito, asegúrate de que los objetivos táctiles y de clic cumplan el tamaño mínimo directamente o mediante relleno. Si los objetivos son más pequeños, asegúrate de que haya al menos 24 píxeles de separación entre ellos para reducir activaciones accidentales. Utiliza media queries y CSS para adaptar el tamaño de los objetivos en móviles e interfaces táctiles sin alterar el diseño. 

3.2.6 Ayuda consistente

La ayuda consistente(opens in a new tab) se refiere a la necesidad de que las funciones de asistencia y orientación, como mecanismos de ayuda o secciones de preguntas frecuentes, aparezcan en ubicaciones predecibles en todo el sitio web (a menos que el usuario cambie su ubicación). Esa consistencia ayuda a los usuarios a encontrar rápidamente las opciones de ayuda y navegar más fácilmente por el sitio, lo que beneficia especialmente a personas con discapacidades cognitivas. 

Para cumplir, asegúrate de que los mecanismos de ayuda como botones de chat en vivo, enlaces de contacto de soporte o accesos a preguntas frecuentes estén ubicados de forma consistente en todas las páginas aplicables, tanto visual como programáticamente. El orden y la ubicación deben permanecer estáticos dentro de las regiones de navegación, salvo que el usuario los personalice o reorganice. La consistencia en el etiquetado y la posición permite a los usuarios, especialmente a quienes tienen discapacidades cognitivas, anticipar dónde está disponible la ayuda. 

3.3.7 Entrada redundante

Si se requiere que los usuarios introduzcan información en varios campos, el criterio de éxito 3.3.7(opens in a new tab) exige varios mecanismos para minimizar la redundancia. Por ejemplo, la información introducida previamente por el usuario no debe volver a solicitarse en la misma sesión, salvo que sea esencial por motivos de seguridad, la repetición sea iniciada por el usuario o la información ya no sea válida. 

Para cumplir, deben implementarse técnicas como el almacenamiento de sesión o la memoria del lado del cliente para preservar la información introducida por el usuario durante un proceso de varios pasos. Por ejemplo, si un usuario introduce su dirección en una pantalla de un formulario de compra, esos datos deben rellenarse automáticamente en las siguientes pantallas si es necesario. Esto reduce repeticiones innecesarias, que pueden ser especialmente gravosas para personas con problemas de memoria o movilidad.

3.3.8 Autenticación accesible (Mínimo)

Los estándares de autenticación accesible(opens in a new tab) exigen que cualquier forma de autenticación de usuario (como los campos de inicio de sesión) esté diseñada para personas con discapacidad. Esto puede incluir ofrecer opciones para diferentes métodos de entrada, mensajes de error claros, procesos de autenticación y ayuda para la recuperación de contraseñas, garantizando que los usuarios puedan acceder a sus cuentas sin barreras. 

Cumplir este requisito implica crear métodos de autenticación que reduzcan la carga cognitiva, como permitir copiar y pegar en los campos de contraseña, integrar gestores de contraseñas y ofrecer opciones de inicio de sesión sin contraseña (por ejemplo, códigos de un solo uso enviados por correo electrónico). Si se utiliza CAPTCHA, asegúrate de que exista un método alternativo de verificación que no requiera resolver un reto basado en la memoria, el reconocimiento de patrones o la interpretación. 

3.3.9 Autenticación accesible (Mejorada)

El estándar mejorado de autenticación accesible(opens in a new tab) amplía los requisitos básicos exigiendo que no se requiera ninguna prueba de función cognitiva en ningún paso de la autenticación, salvo que exista un mecanismo alternativo que no requiera habilidades cognitivas. 

Para cumplir plenamente este requisito, elimina la dependencia de contraseñas tradicionales y preguntas de seguridad siempre que sea posible. En su lugar, ofrece alternativas como inicio de sesión biométrico, enlaces de autenticación seguros enviados por correo electrónico o SMS, o reconocimiento de dispositivo de confianza. Así, las personas con discapacidades cognitivas pueden autenticarse de forma independiente sin la barrera de recordar o descifrar información.

Balanza de la justicia sosteniendo los iconos de WCAG 2.2 y WCAG 2.1

¿Qué versión de WCAG debes seguir?

En el momento de escribir esto, las organizaciones deben cumplir los estándares establecidos en WCAG 2.2 Nivel AA para cumplir con leyes como la Ley de Estadounidenses con Discapacidades(opens in a new tab) (ADA), la Sección 508 o la Ley de Accesibilidad para los Ontarianos con Discapacidad(opens in a new tab) (AODA). Estas directrices abordan muchas de las barreras de accesibilidad más frustrantes, entre ellas:

• Falta de texto alternativo (o texto alt) en imágenes u otros contenidos no textuales, lo que afecta a personas con discapacidad visual como ceguera o baja visión. 

• Falta de subtítulos en vídeos, descripciones de audio o transcripciones, lo que puede afectar a personas con discapacidades auditivas, dificultades de aprendizaje y condiciones neurocognitivas. 

• Falta de encabezados, subencabezados y etiquetas de título, lo que puede dificultar la navegación a personas que usan lectores de pantalla. 

• “Trampas de teclado”, que pueden hacer que el contenido sea inutilizable para quienes no usan ratón para navegar por la web.

Cumplir con los estándares de WCAG 2.2 te permite mantenerte conforme a las principales leyes de accesibilidad y prepararte para futuras versiones de WCAG, incluida la WCAG 3.0. 

El primer paso hacia la conformidad WCAG: prueba tu contenido

A medida que evolucionan los estándares de accesibilidad, actuar con antelación ayuda a reducir riesgos y crear mejores experiencias para todos. Seguir las recomendaciones anteriores te sitúa en una excelente posición para cumplir con los estándares de WCAG 2.2. 

AudioEye te ayuda a simplificar lo que viene después. Nuestra Plataforma de Accesibilidad combina de forma experta pruebas automatizadas con Auditorías de Expertos para detectar y corregir problemas de accesibilidad, ayudándote a crear una experiencia online más accesible y conforme. El proceso comienza con nuestro Comprobador de Accesibilidad Web gratuito, que revisa 32 violaciones de WCAG (más que cualquier otra herramienta del mercado). Estos problemas se corrigen automáticamente mediante nuestras Soluciones Automatizadas, agilizando tu camino hacia una experiencia más accesible.

¿Listo para dar el siguiente paso? Escanea tu contenido ahora o solicita una demo para ver cómo AudioEye facilita la conformidad con WCAG de forma más rápida y eficiente.