Qué significa WCAG 2.2 para tu sitio web

Tras dos años recopilando comentarios, el World Wide Web Consortium (W3C) publicó las Pautas de Accesibilidad para el Contenido Web (WCAG) 2.2(opens in a new tab) como su recomendación oficial, estableciendo un nuevo conjunto de criterios que las empresas deben considerar para seguir cumpliendo con leyes como la Ley de Estadounidenses con Discapacidades (ADA).

Cabe destacar que las empresas que cumplían con los estándares WCAG 2.1 Nivel AA pueden no cumplir con WCAG 2.2, y es probable que estos requisitos cambien de nuevo en los próximos años. Esto significa que se necesitan pruebas adicionales y el asesoramiento de expertos certificados en accesibilidad para garantizar que las empresas sigan cumpliendo.

A continuación, ofrecemos una visión general de los nuevos criterios y consejos sobre cómo las empresas pueden identificar dónde su contenido digital ya no cumple. También hablaremos de cómo AudioEye simplifica este proceso, facilitando a las organizaciones el cumplimiento de los estándares de accesibilidad en evolución.

La evolución de las Pautas de Accesibilidad para el Contenido Web

Establecidas originalmente en 1999, las WCAG 1.0 fueron el primer paso para establecer pautas de accesibilidad en la web. Las pautas originales se centraban principalmente en HTML e incluían 14 directrices.

La siguiente versión, WCAG 2.0, se creó en 2008 y amplió su alcance para incluir los cuatro principios de la accesibilidad web. WCAG 2.0 se introdujo tras importantes cambios tecnológicos y se aplicó a todo el contenido digital, incluidos documentos y aplicaciones móviles.

WCAG 2.1 se publicó en junio de 2018 y amplía los principios de WCAG 2.0. Fue una actualización bienvenida, ya que WCAG 2.0 ya no podía tener en cuenta los avances más recientes en tecnología y uso web. Las nuevas pautas incluyen varios criterios de éxito nuevos para mejorar la accesibilidad web en dispositivos móviles.

Esto nos lleva a octubre de 2023, cuando se publicó la última versión de WCAG. Las pautas incluyen nueve nuevos criterios de éxito que se centran específicamente en proporcionar más apoyo a usuarios con baja visión, discapacidades cognitivas o de aprendizaje y habilidades motoras limitadas.

Como WCAG se considera el estándar de oro para la accesibilidad web, la Sección 508 de la Ley de Rehabilitación exige que las agencias federales cumplan con WCAG 2.0 A/AA. Para las empresas privadas, el Departamento de Justicia (DOJ) ha declarado que, para cumplir con la Ley de Estadounidenses con Discapacidades (ADA)(opens in a new tab), las organizaciones deben ajustarse a las recomendaciones de WCAG.

Un gráfico que muestra los tres niveles de conformidad de WCAG: Nivel A, Nivel AA y Nivel AAA.

WCAG 2.2: Qué hay de nuevo y por qué es importante

Como se mencionó anteriormente, WCAG 2.2 incluye nueve nuevos criterios de éxito, que se suman a los 78 criterios de éxito de WCAG 2.1. Cada uno de estos criterios ayuda a mejorar la accesibilidad digital para tres grandes grupos: usuarios con discapacidades cognitivas o de aprendizaje, usuarios con baja visión y usuarios con discapacidades en dispositivos móviles.

La última versión de las pautas de accesibilidad también eliminó un criterio anterior que ahora está obsoleto: WCAG 4.1.1: Análisis sintáctico. Es la primera vez que se elimina un criterio de éxito de las pautas, lo que demuestra la capacidad de adaptación de las mismas a las tendencias digitales actuales.

Como en versiones anteriores, los nuevos criterios se dividen en tres niveles de conformidad: A, AA y AAA. Según el aviso recientemente publicado por el DOJ sobre la propuesta de reglamentación de accesibilidad web bajo el Título II de la ADA, las empresas deben cumplir con los estándares WCAG 2.X Nivel AA.

Teniendo esto en cuenta, veamos los nuevos criterios y cómo cada uno ayuda a abordar problemas de accesibilidad.

WCAG 2.4.11: El enfoque no está oscurecido (mínimo) (Nivel AA)

Para los usuarios videntes que dependen del teclado para navegar por sitios web, conocer el punto de enfoque actual es fundamental para moverse por las páginas. Sin embargo, los elementos enfocados pueden quedar ocasionalmente ocultos por cabeceras fijas, ventanas emergentes y otros contenidos que aparecen en pantalla.

Cuando un componente de la interfaz de usuario recibe el enfoque del teclado, WCAG 2.4.11(opens in a new tab) establece que una parte de él debe permanecer visible y no ser ocultada por otros contenidos en pantalla. Esto puede ayudar a mejorar el enfoque y la navegación para usuarios con discapacidades cognitivas o visuales; sin embargo, cuanto más visible sea el indicador de enfoque, más fácil será para los usuarios seguirlo mientras navegan por las páginas web.

WCAG 2.4.12: El enfoque no está oscurecido (mejorado) (Nivel AAA)

WCAG 2.4.12(opens in a new tab) sigue las mismas pautas que el criterio anterior; sin embargo, la diferencia clave aquí es que ninguna parte del indicador de enfoque puede quedar oculta por otros contenidos de la página. Esto garantiza que el elemento enfocado sea completamente visible para el usuario, lo que mejora la navegación para quienes tienen visión limitada o baja. Los usuarios con limitaciones de atención (como limitaciones de memoria a corto plazo) también pueden concentrarse más fácilmente con todo el enfoque visible.

WCAG 2.4.13: Apariencia del enfoque (Nivel AAA)

Los indicadores de enfoque resaltan el elemento de una página web que está actualmente enfocado. WCAG 2.4.13(opens in a new tab) exige que los indicadores de enfoque tengan suficiente contraste de color (al menos 3:1 entre los mismos píxeles en los estados enfocado y no enfocado) y sean lo suficientemente grandes como para ser claramente visibles. Por ejemplo, cuando un enlace recibe el enfoque, se muestra un contorno alrededor del enlace. El color de este contorno debe tener suficiente contraste con el color de fondo de la página.

Garantizar que los indicadores de enfoque tengan suficiente contraste de color asegura que los usuarios puedan ver fácilmente pequeños cambios en la apariencia visual. Esto es especialmente beneficioso para personas mayores o usuarios de teclado, ya que pueden seguir fácilmente dónde están en una página mientras se desplazan.

WCAG 2.5.7: Movimientos de arrastre (Nivel AA)

Arrastrar y soltar puede ser complicado y propenso a errores para muchas personas, ya sea que usen un teclado, tengan una discapacidad motora o dependan de dispositivos de entrada adaptados como punteros de cabeza o emuladores de ratón controlados por voz.

WCAG 2.5.7(opens in a new tab) exige que los movimientos de arrastre no sean la única forma de realizar acciones esenciales en una página, ya sea manipulando un control deslizante o reordenando componentes en una interfaz de arrastrar y soltar.

Por ejemplo, un sitio web podría permitir el uso del teclado con las flechas arriba/abajo/izquierda/derecha o proporcionar botones en pantalla que el usuario pueda pulsar para mover un control deslizante o ordenar una lista. Esto garantiza que los usuarios que tienen dificultades o que no pueden realizar movimientos de arrastre puedan seguir utilizando la interfaz de arrastrar y soltar.

WCAG 2.5.8: Tamaño del objetivo (mínimo) (Nivel AA)

Cuando los botones y otros elementos clicables son pequeños, es difícil para las personas con temblores en las manos y otras discapacidades motoras finas activarlos sin activar accidentalmente otro elemento.

WCAG 2.5.8(opens in a new tab) exige que el tamaño mínimo de todos los elementos clicables (como los botones de llamada a la acción) sea de al menos 24 x 24 píxeles CSS. También exige que los sitios web proporcionen al menos 24 píxeles CSS de espacio entre objetivos adyacentes.

Este criterio proporciona una alternativa de Nivel AA a WCAG 2.5.5: Tamaño del objetivo(opens in a new tab), un requisito de Nivel AAA que se introdujo como parte de WCAG 2.1 y exige que el tamaño del objetivo de todos los elementos clicables sea de al menos 44 x 44 píxeles CSS.

Esta nueva capacidad permite a las personas con limitaciones motoras finas hacer clic fácilmente en los botones. También mejora la experiencia móvil, ya que los usuarios tienen suficiente espacio para seleccionar botones pequeños.

WCAG 3.2.6: Ayuda consistente (Nivel A)

Si las funciones de ayuda o los mecanismos de ayuda — como los datos de contacto de un sitio web o un chatbot de autoservicio — están disponibles en varias páginas de un sitio web, WCAG 3.2.6(opens in a new tab) exige que aparezcan en el mismo lugar relativo y en el mismo orden en cada página donde estén presentes.

Por ejemplo, si un sitio web tiene una opción de 'Chat', debería aparecer en la esquina inferior derecha de cada página. O los datos de contacto, incluido el número de teléfono, horario de atención o dirección de correo electrónico, deben figurar en el pie de página de cada página.

Al mostrar de forma consistente la información útil en el mismo lugar, las personas que puedan tener dificultades para encontrar ayuda o recordar dónde está la información podrán localizarla más fácilmente.

WCAG 3.3.7: Entrada redundante (Nivel A)

Algunos formularios requieren que los usuarios introduzcan la misma información más de una vez, lo que puede ser una carga para las personas con discapacidades motoras. También puede ser difícil para los usuarios con discapacidades cognitivas, ya que pueden tener dificultades para recordar qué información ya han introducido.

WCAG 3.3.7(opens in a new tab) exige que los sitios web autocompleten los campos o permitan a los usuarios reutilizar datos previamente introducidos. Esto evita que los usuarios tengan que introducir la información repetidamente, reduce la probabilidad de errores y disminuye la necesidad de escribir texto.

WCAG 3.3.8: Autenticación accesible (mínimo) (Nivel AA)

El objetivo de WCAG 3.3.8(opens in a new tab) es proporcionar a los usuarios con discapacidades cognitivas una forma fácil y accesible de iniciar sesión en sitios web y aplicaciones móviles. Si se utiliza una prueba de función cognitiva(opens in a new tab) — como memorizar una contraseña o identificar imágenes o caracteres —, los sitios web deben ofrecer al menos otro método de autenticación.

Esto simplifica el proceso de autenticación para personas con discapacidades cognitivas y les permite autenticarse según sus necesidades individuales. Un mecanismo que puede ayudar con esto es el uso de gestores de contraseñas. Estos pueden ayudar a reducir la necesidad de memoria y la carga de volver a escribir información.

WCAG 3.3.9: Autenticación accesible (mejorada) (Nivel AAA)

Similar al criterio anterior, WCAG 3.3.9(opens in a new tab) está diseñado para simplificar el proceso de inicio de sesión para usuarios con discapacidades cognitivas. Sin embargo, este criterio va un paso más allá y no permite la autenticación mediante reconocimiento de objetos o contenido proporcionado por el usuario, como una imagen subida por el usuario. Esto garantiza que los usuarios con dificultades cognitivas relacionadas con la memoria, la lectura (por ejemplo, dislexia), los números o las limitaciones de procesamiento-percepción puedan iniciar sesión o autenticarse fácilmente.

¿Es WCAG un requisito legal?

Cabe destacar que varios de los nuevos criterios de éxito de WCAG 2.2 requieren pruebas manuales para identificarlos de forma fiable, lo que subraya la necesidad de que las empresas complementen las pruebas automatizadas con auditorías manuales realizadas por expertos certificados en accesibilidad y usuarios de tecnología de asistencia.

En AudioEye, trabajamos con más de 80 miembros de la comunidad con discapacidad (conocidos como AudioEye A11iance) para auditar profesionalmente los sitios web de los clientes en busca de problemas WCAG. En preparación para la publicación de WCAG 2.2, nuestros evaluadores se formaron en los últimos criterios y estrategias de remediación de WCAG.

¿Quieres saber dónde puede que tu empresa no cumpla con los últimos estándares WCAG? Programa una consulta gratuita para hablar sobre la accesibilidad de tu sitio web y cómo AudioEye puede ayudarte a identificar y solucionar problemas de accesibilidad desde la raíz.

Pasos para garantizar que tu sitio web cumple con WCAG 2.2

Incluso si tu organización está obligada a cumplir con los estándares WCAG 2.0 o 2.1, se recomienda ajustarse a los nuevos estándares WCAG. Hacerlo mejora la accesibilidad de tu sitio y demuestra tu compromiso con una experiencia accesible e inclusiva.

A continuación, te mostramos tres formas de implementar los estándares WCAG 2.2 en tu sitio.

Realiza una auditoría de accesibilidad

El primer paso para integrar los criterios de WCAG 2.2 es auditar tu sistema actual. Esto identificará dónde están los problemas de accesibilidad existentes y te dará un punto de partida para implementar WCAG 2.2. Un Comprobador de Accesibilidad como AudioEye puede ayudarte con esto.

Implementa cambios según los resultados de la auditoría

Una vez que tengas los resultados de la auditoría, comienza a implementar los cambios. Recomendamos empezar por los problemas más pequeños —como arreglar enlaces rotos o añadir texto alternativo a las imágenes— antes de abordar los problemas mayores.

Involucra a expertos certificados en accesibilidad para pruebas manuales

Las plataformas automatizadas de accesibilidad solo pueden detectar problemas comunes de accesibilidad. Los problemas más complejos, como textos alternativos mal redactados o baja compatibilidad con la navegación solo por teclado o tecnología de asistencia, pueden pasar desapercibidos. Las pruebas manuales no solo pueden descubrir estos problemas, sino que también pueden ofrecer recomendaciones sobre cómo solucionarlos.

Por ejemplo, la plataforma de Accesibilidad Digital de AudioEye utiliza pruebas automatizadas para detectar problemas comunes de accesibilidad y proporciona soluciones automáticas para estos casos. Todo lo que no pueda solucionarse con nuestra solución automatizada es gestionado por nuestro equipo de evaluadores humanos, que resuelven los problemas mediante soluciones personalizadas.

Un enfoque híbrido de las pruebas de accesibilidad mejora la accesibilidad general de tu sitio y crea una experiencia mejor y más inclusiva.

Una página web estilizada con varios errores de accesibilidad marcados con signos de exclamación, junto a un símbolo de accesibilidad verde.

Cómo AudioEye simplifica el cumplimiento de WCAG 2.2

A medida que los estándares WCAG siguen evolucionando, las organizaciones deben monitorizar y probar continuamente sus sitios para detectar errores de accesibilidad o incumplimientos de WCAG. Hacerlo mejora la accesibilidad del sitio web y ayuda a cumplir con los requisitos legales de accesibilidad.

En AudioEye, nos aseguramos de que tu sitio siga los últimos estándares WCAG mediante pruebas automatizadas y expertas realizadas por un grupo de especialistas en accesibilidad. También colaboramos con más de 80 miembros de la comunidad con discapacidad (AudioEye A11iance) para realizar pruebas personalizadas expertas en sitios web. Cada uno de nuestros evaluadores ha sido formado en la última versión de los estándares WCAG para garantizar que los sitios cumplan con los criterios de éxito más recientes.

¿Lo mejor de trabajar con AudioEye? ¡No necesitas seguir los cambios tú mismo, lo hacemos por ti! Nuestros Expert Audits prueban regularmente tu sitio para encontrar y solucionar problemas de accesibilidad antes de que afecten a tus clientes.

¿Listo para ver cuán conforme es tu sitio web con los estándares WCAG 2.2? Programa una demo gratuita con AudioEye y descubre cómo podemos agilizar tu camino hacia la accesibilidad.