¿Qué es WCAG 2.2? Guía completa para 2026

¿Qué es WCAG?

WCAG son las siglas de Web Content Accessibility Guidelines (Pautas de Accesibilidad para el Contenido Web), un conjunto de estándares técnicos desarrollados por el World Wide Web Consortium (W3C) para hacer que el contenido web sea accesible para las personas con discapacidad. Estas pautas proporcionan un marco compartido que gobiernos, organizaciones y desarrolladores de todo el mundo utilizan para garantizar que los sitios web, las aplicaciones y los documentos digitales puedan ser usados por cualquier persona, independientemente de sus capacidades o de las tecnologías de asistencia que necesiten.

En esencia, WCAG trata de eliminar barreras. Una persona ciega debería poder usar un lector de pantalla para navegar por tu sitio web. Una persona con una discapacidad motora debería poder interactuar con todos los controles usando únicamente el teclado. Una persona con una discapacidad cognitiva debería poder entender tu contenido sin complejidad innecesaria. WCAG define criterios de conformidad verificables que, al seguirse, hacen posibles estas experiencias.

Las pautas se organizan en torno a cuatro principios fundamentales conocidos por el acrónimo POUR: Perceptible (Perceivable), Operable, Comprensible (Understandable) y Robusto (Robust). Cada principio contiene directrices, y cada directriz contiene criterios de conformidad en tres niveles (A, AA y AAA). La versión actual, WCAG 2.2, se publicó en octubre de 2023 y contiene 87 criterios de conformidad en total.

¿Quién publica WCAG?

WCAG es publicada por la Web Accessibility Initiative (WAI), un programa dentro del World Wide Web Consortium (W3C). El W3C es la organización internacional de estándares responsable de muchas de las tecnologías fundamentales de la web, incluyendo HTML, CSS y ARIA. La WAI reúne a profesionales de la industria, organizaciones de personas con discapacidad, gobiernos e instituciones de investigación de todo el mundo para desarrollar estándares y recursos de accesibilidad.

El desarrollo de WCAG sigue el proceso basado en consenso del W3C, que incluye múltiples rondas de revisión y comentarios públicos. Esto significa que las pautas reflejan un amplio acuerdo internacional sobre lo que constituyen las mejores prácticas en accesibilidad web. WCAG no es el producto de una única empresa o gobierno, sino un estándar global desarrollado de forma colaborativa.

Por qué WCAG importa en 2026

WCAG importa más en 2026 que nunca por tres razones interconectadas: el panorama legal, la magnitud de la discapacidad a nivel global y el argumento empresarial a favor de la accesibilidad.

En el frente legal, la European Accessibility Act (EAA) entró en vigor en junio de 2025, exigiendo que una amplia gama de productos y servicios vendidos en la UE cumplan requisitos de accesibilidad que se corresponden directamente con WCAG. En Estados Unidos, el Department of Justice ha emitido directrices que referencian explícitamente WCAG 2.1 Nivel AA como el estándar que los sitios web deben cumplir bajo la Americans with Disabilities Act (ADA). Las demandas de accesibilidad web relacionadas con la ADA han seguido aumentando, con más de 4.000 presentadas en tribunales federales durante 2024 -- un incremento del 14 por ciento respecto al año anterior. La Section 508 de la Rehabilitation Act exige que las agencias federales de Estados Unidos y sus contratistas cumplan estándares de accesibilidad que incorporan WCAG. Leyes similares existen en Canadá, Reino Unido, Australia y decenas de otros países.

La Organización Mundial de la Salud estima que 1.300 millones de personas -- aproximadamente el 16 por ciento de la población mundial -- experimentan alguna discapacidad significativa. Esto incluye personas con discapacidades visuales, auditivas, motoras, cognitivas y neurológicas. A medida que las poblaciones envejecen, estas cifras seguirán creciendo. No hacer accesible el contenido web significa excluir a una parte sustancial de los usuarios, clientes y ciudadanos potenciales.

El argumento empresarial es igualmente convincente. Los sitios web accesibles tienden a tener mejor posicionamiento en buscadores porque muchas buenas prácticas de accesibilidad -- como una estructura de encabezados adecuada, texto de enlace descriptivo y texto alternativo para imágenes -- coinciden con las buenas prácticas de SEO. Los sitios accesibles también suelen tener menores tasas de rebote, mayores tasas de conversión y un alcance de mercado más amplio. Las organizaciones que invierten en accesibilidad demuestran un compromiso con la inclusión que conecta con los consumidores y fortalece la reputación de marca.

Breve historia de WCAG

Comprender de dónde proviene WCAG ayuda a explicar por qué la versión actual tiene la forma que tiene y hacia dónde se dirige el estándar. Las pautas han evolucionado significativamente a lo largo de más de dos décadas, y cada versión ha respondido a los cambios en la tecnología web y a una comprensión más profunda de cómo las personas con discapacidad utilizan la web.

De WCAG 1.0 a 2.2

WCAG 1.0 se publicó en mayo de 1999, convirtiéndose en uno de los primeros estándares formales de accesibilidad web. Contenía 14 directrices y 65 puntos de verificación, pero sus recomendaciones estaban fuertemente vinculadas a la web basada en HTML de finales de los años 90. A medida que la tecnología web evolucionó con el auge de CSS, JavaScript y las aplicaciones ricas de internet, WCAG 1.0 resultaba cada vez más difícil de aplicar al contenido web moderno.

WCAG 2.0, publicada en diciembre de 2008, supuso un rediseño fundamental. En lugar de estar vinculada a tecnologías específicas, WCAG 2.0 se redactó de forma agnóstica respecto a la tecnología. Sus criterios de conformidad describen resultados en lugar de técnicas, lo que significa que se pueden aplicar a HTML, PDF, aplicaciones móviles y tecnologías emergentes por igual. WCAG 2.0 introdujo los cuatro principios POUR y los tres niveles de conformidad (A, AA, AAA) que siguen siendo la base del estándar hoy en día. WCAG 2.0 también fue adoptada como estándar internacional ISO/IEC 40500:2012.

WCAG 2.1, publicada en junio de 2018, amplió WCAG 2.0 añadiendo 17 nuevos criterios de conformidad. Estas incorporaciones abordaban lagunas que se habían hecho evidentes a medida que la web se desplazaba hacia los dispositivos móviles y la comunidad de accesibilidad adquiría una comprensión más profunda de las necesidades de las personas con discapacidades cognitivas y de aprendizaje, así como de las personas con baja visión. WCAG 2.1 se diseñó para ser retrocompatible con WCAG 2.0, lo que significa que cualquier sitio conforme a WCAG 2.1 también cumple con WCAG 2.0.

WCAG 2.2, publicada el 5 de octubre de 2023, sigue el mismo enfoque de retrocompatibilidad. Añade nueve nuevos criterios de conformidad y elimina uno (4.1.1 Parsing, que quedó obsoleto gracias a las mejoras en la forma en que los navegadores y las tecnologías de asistencia procesan el HTML). Los nuevos criterios continúan poniendo énfasis en la accesibilidad cognitiva, la usabilidad móvil y el mejor soporte para personas con baja visión.

Niveles de conformidad de WCAG 2.2

Cada criterio de conformidad de WCAG tiene asignado uno de tres niveles: A, AA o AAA. Estos niveles indican el impacto y la dificultad de cada criterio. Comprender los niveles es esencial para establecer objetivos de cumplimiento y priorizar las tareas de corrección.

Nivel A -- Accesibilidad mínima

Los criterios de Nivel A abordan las barreras más fundamentales de accesibilidad. Si no se cumplen estos criterios, uno o más grupos de usuarios encontrarán imposible o extremadamente difícil acceder al contenido. Algunos ejemplos incluyen proporcionar alternativas de texto para el contenido no textual (imágenes, iconos, gráficos), hacer que toda la funcionalidad esté disponible desde el teclado, y no utilizar contenido que parpadee más de tres veces por segundo.

Cumplir con el Nivel A es el mínimo absoluto para cualquier sitio web, pero el Nivel A por sí solo no hace que un sitio sea realmente accesible. Muchas barreras significativas solo se abordan en el Nivel AA. Piensa en el Nivel A como la eliminación de los obstáculos más graves que impedirían por completo el acceso a grupos enteros de usuarios.

Nivel AA -- El objetivo estándar

El Nivel AA es el nivel de conformidad más referenciado en leyes, regulaciones y políticas organizacionales de todo el mundo. La ADA, la European Accessibility Act, la Section 508 y la EN 301 549 apuntan al Nivel AA de WCAG como objetivo. Los criterios de Nivel AA abordan problemas que crean barreras significativas pero que pueden no bloquear el acceso por completo. Ejemplos clave incluyen un contraste de color suficiente entre el texto y el fondo (una proporción mínima de 4,5:1 para texto normal), la posibilidad de ampliar el texto hasta un 200 por ciento sin pérdida de contenido o funcionalidad, indicadores de foco visibles para la navegación por teclado, y subtítulos para el contenido de audio pregrabado.

Para la mayoría de las organizaciones, el Nivel AA debería ser el objetivo. Proporciona un nivel sólido de accesibilidad para la gran mayoría de usuarios con discapacidad y satisface los requisitos de la mayor parte de la legislación sobre accesibilidad. La conformidad con el Nivel AA incluye todos los criterios del Nivel A más los criterios adicionales de AA, sumando un total de 58 criterios de conformidad en WCAG 2.2.

Nivel AAA -- Accesibilidad avanzada

El Nivel AAA representa los requisitos de accesibilidad más exigentes. Estos criterios ofrecen mejoras adicionales que benefician a los usuarios con discapacidad, pero pueden no ser alcanzables para todos los tipos de contenido. Algunos ejemplos incluyen una proporción de contraste de color mejorada de 7:1 para texto normal, interpretación en lengua de signos para todo el contenido de audio pregrabado, y limitar todo el contenido a un nivel de lectura de educación secundaria básica.

El W3C no recomienda el Nivel AAA como objetivo general de conformidad para sitios web completos porque no es posible satisfacer todos los criterios AAA para todos los tipos de contenido. Sin embargo, las organizaciones deberían aspirar a cumplir criterios AAA individuales siempre que sea viable, ya que hacerlo mejora aún más la experiencia de los usuarios con discapacidad. Cumplir criterios AAA específicos en las áreas más relevantes para tu audiencia puede marcar una diferencia significativa.

Los cuatro principios de WCAG (POUR)

Todo el marco de WCAG se sustenta en cuatro principios fundamentales conocidos habitualmente por el acrónimo POUR. Cada criterio de conformidad de WCAG se enmarca en uno de estos cuatro principios. Comprender POUR proporciona un modelo mental para pensar en accesibilidad que va más allá de cualquier lista de verificación o herramienta de pruebas específica.

Perceptible

La información y los componentes de la interfaz de usuario deben presentarse de formas que los usuarios puedan percibir. Esto significa que el contenido no puede depender de un único sentido. Si la información se transmite visualmente, debe existir una alternativa no visual. Si el contenido se presenta como audio, debe haber una alternativa basada en texto. Los requisitos clave bajo el principio de Perceptibilidad incluyen proporcionar alternativas de texto (texto alternativo) para todo el contenido no textual como imágenes, iconos y gráficos; proporcionar subtítulos y transcripciones para el contenido de audio y vídeo; asegurar que el contenido pueda presentarse de diferentes maneras sin perder información ni estructura (por ejemplo, usando una jerarquía de encabezados adecuada y HTML semántico); y mantener un contraste de color suficiente entre el texto y su fondo para que los usuarios con baja visión o daltonismo puedan leer el contenido.

Operable

Los componentes de la interfaz de usuario y la navegación deben ser operables por todos los usuarios. Este principio garantiza que las personas que no pueden usar un ratón, que necesitan más tiempo o que padecen trastornos convulsivos puedan interactuar con el contenido. Los requisitos clave incluyen hacer que toda la funcionalidad sea accesible mediante teclado; dar a los usuarios tiempo suficiente para leer e interactuar con el contenido; no diseñar contenido que pueda provocar convulsiones o reacciones físicas (como contenido parpadeante); proporcionar mecanismos para ayudar a los usuarios a navegar y encontrar contenido (encabezados, landmarks, enlaces de salto); y asegurar que los usuarios puedan operar la interfaz a través de diversas modalidades de entrada más allá del teclado y ratón tradicionales, incluyendo táctil, voz y otras tecnologías de asistencia.

Comprensible

La información y el funcionamiento de la interfaz de usuario deben ser comprensibles. Los usuarios deben ser capaces de entender tanto el contenido como el funcionamiento de la interfaz. Los requisitos clave incluyen hacer que el texto sea legible y comprensible especificando el idioma de la página y cualquier cambio de idioma dentro del contenido; hacer que las páginas web se comporten de manera predecible, de modo que la navegación sea consistente, los componentes se comporten como se espera y los cambios de contexto no ocurran sin que el usuario los inicie; y proporcionar asistencia en la entrada de datos como etiquetas claras, mensajes de error útiles y mecanismos de prevención de errores en formularios. Este principio es especialmente importante para los usuarios con discapacidades cognitivas y de aprendizaje, que pueden verse afectados de forma desproporcionada por diseños confusos, instrucciones poco claras o comportamientos impredecibles de la interfaz.

Robusto

El contenido debe ser lo suficientemente robusto como para ser interpretado de forma fiable por una amplia variedad de agentes de usuario, incluidas las tecnologías de asistencia. Este principio se centra en la compatibilidad técnica y la preparación para el futuro. Los requisitos clave incluyen utilizar marcado válido y bien formado para que los navegadores y las tecnologías de asistencia puedan analizar y presentar el contenido con precisión; asegurar que los componentes personalizados de la interfaz de usuario tengan nombres, roles y valores correctos que puedan ser determinados programáticamente por las tecnologías de asistencia (usando atributos ARIA cuando la semántica nativa de HTML no es suficiente); y proporcionar mensajes de estado que puedan ser determinados programáticamente para que los lectores de pantalla puedan anunciarlos sin necesidad de recibir el foco. El principio de Robustez garantiza que, a medida que los navegadores y las tecnologías de asistencia evolucionen, el contenido siga siendo accesible.

Novedades de WCAG 2.2

WCAG 2.2 introduce nueve nuevos criterios de conformidad que no estaban presentes en WCAG 2.1. Estos criterios abordan áreas en las que los usuarios con discapacidad seguían enfrentando barreras significativas a pesar de la conformidad con las versiones anteriores. Los nuevos criterios ponen especial énfasis en la visibilidad del foco, la autenticación y la reducción de la carga cognitiva. A continuación se detalla cada uno de ellos.

2.4.11 Focus Not Obscured (Minimum) -- Nivel AA

Cuando un componente de la interfaz de usuario recibe el foco del teclado, dicho componente no debe quedar completamente oculto detrás de otro contenido como cabeceras fijas, pies de página o superposiciones modales. Este criterio reconoce que los usuarios videntes que navegan con teclado dependen del indicador de foco para saber dónde se encuentran en la página. Si el elemento enfocado queda completamente tapado por una barra de navegación fija o un banner de consentimiento de cookies, el usuario pierde la noción de su posición y no puede interactuar de forma eficaz. Se permite una ocultación parcial en este nivel, pero el elemento enfocado no debe quedar totalmente oculto.

2.4.12 Focus Not Obscured (Enhanced) -- Nivel AAA

Esta versión mejorada del criterio anterior exige que ninguna parte del componente enfocado quede oculta por contenido creado por el autor. Mientras que el nivel AA permite la ocultación parcial, este criterio AAA demanda que el elemento enfocado sea completamente visible en todo momento. Esto proporciona una experiencia aún mejor para los usuarios videntes que navegan con teclado, al garantizar que siempre puedan ver el indicador de foco completo y la totalidad del elemento enfocado.

2.4.13 Focus Appearance -- Nivel AAA

Este criterio define los requisitos mínimos para los indicadores de foco a fin de garantizar que sean suficientemente visibles. El indicador de foco debe tener un área mínima equivalente al menos a un perímetro de 2 píxeles CSS de grosor alrededor del componente sin foco, y debe tener una relación de contraste de al menos 3:1 entre sus estados con y sin foco. Este criterio aborda el problema habitual de indicadores de foco que están técnicamente presentes pero son demasiado sutiles para ser percibidos por usuarios con baja visión.

2.5.7 Dragging Movements -- Nivel AA

Cualquier funcionalidad que utilice un movimiento de arrastre debe poder realizarse también mediante un puntero único sin arrastre, a menos que el arrastre sea esencial para la actividad subyacente. Este criterio ayuda a los usuarios con discapacidades motoras que pueden no ser capaces de realizar acciones de arrastrar y soltar. Por ejemplo, una lista ordenable que permite reorganizar elementos arrastrándolos a una nueva posición también debe ofrecer botones de subir y bajar u otro mecanismo de puntero único para lograr el mismo resultado.

2.5.8 Target Size (Minimum) -- Nivel AA

El tamaño de los objetivos interactivos (botones, enlaces, controles de formulario) debe ser de al menos 24 por 24 píxeles CSS, o debe existir un espaciado suficiente entre los objetivos de menor tamaño para que no estén demasiado cerca unos de otros. Este criterio reconoce que los usuarios con discapacidades motoras, usuarios con temblores y usuarios en dispositivos táctiles pueden tener dificultades para tocar o hacer clic con precisión en objetivos pequeños. Existen excepciones para los enlaces en línea dentro del texto, los objetivos cuyo tamaño es determinado por el agente de usuario y los casos en que el tamaño del objetivo es esencial para la información que se transmite.

3.2.6 Consistent Help -- Nivel A

Si un sitio web proporciona mecanismos de ayuda como información de contacto, un chat, un enlace a una página de ayuda o preguntas frecuentes de autoservicio, dichos mecanismos deben aparecer en el mismo orden relativo en todas las páginas. Los usuarios con discapacidades cognitivas dependen de la ubicación consistente de las funciones de ayuda. Si el enlace de ayuda está en el pie de página en una página y en la cabecera en otra, se genera confusión y aumenta la carga cognitiva. Este criterio no exige que existan mecanismos de ayuda, pero si los hay, deben ser consistentes.

3.3.7 Redundant Entry -- Nivel A

La información que el usuario ya ha introducido durante un proceso debe autocompletarse o estar disponible para que el usuario la seleccione, en lugar de requerir que la introduzca de nuevo. Por ejemplo, si un usuario introduce su dirección de envío durante el proceso de compra, el formulario de dirección de facturación debería ofrecer la opción de reutilizar la dirección de envío en lugar de obligar al usuario a escribirla una segunda vez. Este criterio reduce la carga cognitiva y el esfuerzo físico, beneficiando a los usuarios con discapacidades cognitivas, discapacidades motoras y a todos los demás.

3.3.8 Accessible Authentication (Minimum) -- Nivel AA

Los procesos de autenticación no deben depender de pruebas de función cognitiva como recordar una contraseña, resolver un puzzle o realizar un cálculo, a menos que se proporcione un método alternativo o exista un mecanismo para asistir al usuario (como permitir que los gestores de contraseñas rellenen las credenciales o admitir copiar y pegar en los campos de contraseña). Este criterio reconoce que las pruebas de función cognitiva crean barreras desproporcionadas para los usuarios con discapacidades cognitivas. Los métodos de autenticación que admiten gestores de contraseñas, inicio de sesión biométrico o passkeys satisfacen este criterio.

3.3.9 Accessible Authentication (Enhanced) -- Nivel AAA

Esta versión mejorada del criterio de autenticación va más allá al prohibir también el reconocimiento de objetos y el reconocimiento de contenido personal como métodos de autenticación. En el nivel AA, reconocer objetos en imágenes (como seleccionar todas las fotos que contienen semáforos) se permite como alternativa. En el nivel AAA, incluso este tipo de prueba no está permitido. Esto garantiza que la autenticación sea accesible para los usuarios con la gama más amplia de discapacidades cognitivas.

WCAG 2.2 vs. WCAG 2.1: diferencias clave

WCAG 2.2 se construye sobre WCAG 2.1 de manera retrocompatible. Esto significa que todos los criterios de conformidad de WCAG 2.1 se mantienen en WCAG 2.2, con una excepción: el Criterio de Conformidad 4.1.1 Parsing ha sido eliminado. Este criterio exigía que el HTML estuviera bien formado y libre de errores de análisis. Se eliminó porque los navegadores modernos y las tecnologías de asistencia se han vuelto lo suficientemente robustos como para manejar la mayoría de los problemas de análisis, haciendo que el criterio fuera en gran medida redundante.

En su lugar, WCAG 2.2 añade nueve nuevos criterios de conformidad. Seis de ellos son de nivel A o AA, lo que los hace relevantes para las organizaciones que apuntan al nivel de conformidad más comúnmente exigido. Los nuevos criterios reflejan tres áreas de enfoque clave: mejorar la experiencia de los usuarios con discapacidades cognitivas y de aprendizaje reduciendo las barreras de autenticación y evitando la entrada redundante de datos; mejorar el soporte para los usuarios con baja visión y discapacidades motoras mediante una mejor visibilidad del foco y tamaños mínimos de objetivo; y mejorar la usabilidad móvil asegurando alternativas a los gestos de arrastre.

Un sitio que ya cumple con WCAG 2.1 Nivel AA necesita abordar cinco criterios adicionales de nivel AA (Focus Not Obscured Minimum, Dragging Movements, Target Size Minimum, Accessible Authentication Minimum) y dos nuevos criterios de nivel A (Consistent Help, Redundant Entry) para cumplir con WCAG 2.2 Nivel AA. La eliminación de 4.1.1 Parsing supone un criterio menos del que preocuparse, aunque la mayoría de los sitios ya lo estaban cumpliendo.

Requisitos legales que referencian WCAG

WCAG no es una ley en sí misma, pero sirve como el estándar técnico que numerosas leyes y regulaciones de todo el mundo referencian al definir los requisitos de accesibilidad. Comprender el panorama legal es esencial para las organizaciones que desean gestionar el riesgo y cumplir con sus obligaciones.

Americans with Disabilities Act (ADA)

La ADA prohíbe la discriminación por motivos de discapacidad en los lugares de alojamiento público, y los tribunales federales han sostenido de forma creciente que los sitios web se consideran lugares de alojamiento público. El Department of Justice (DOJ) ha emitido directrices que establecen que la ADA se aplica a los sitios web y que referencian WCAG 2.1 Nivel AA como el estándar apropiado. En abril de 2024, el DOJ publicó una norma final bajo el Título II de la ADA que exige a los sitios web de gobiernos estatales y locales cumplir con WCAG 2.1 Nivel AA para 2026 o 2028, dependiendo del tamaño de la jurisdicción. Aunque todavía no existe una norma formal similar para los sitios web del sector privado bajo el Título III, los tribunales han utilizado consistentemente WCAG como referencia en acuerdos de conciliación y decretos de consentimiento. El número de demandas de accesibilidad web relacionadas con la ADA sigue creciendo cada año, lo que convierte el cumplimiento proactivo de WCAG en una estrategia crítica de gestión de riesgos.

European Accessibility Act (EAA)

La European Accessibility Act, que entró en vigor en junio de 2025, exige que una amplia gama de productos y servicios comercializados en el mercado de la UE cumplan requisitos de accesibilidad. Esto incluye sitios web de comercio electrónico, servicios bancarios, servicios de transporte y comunicaciones electrónicas. La EAA referencia el estándar armonizado europeo EN 301 549, que a su vez mapea sus requisitos de accesibilidad web a WCAG 2.1 Nivel AA. La EAA se aplica a empresas de todos los tamaños con excepciones limitadas para microempresas con menos de 10 empleados y una facturación anual inferior a 2 millones de euros. El incumplimiento puede resultar en multas y restricciones de mercado determinadas por cada Estado miembro de la UE.

Section 508 y EN 301 549

La Section 508 de la Rehabilitation Act exige a las agencias federales de Estados Unidos que hagan accesibles sus tecnologías de la información y comunicaciones electrónicas para las personas con discapacidad. Los estándares de la Section 508, actualizados en 2017, incorporan WCAG 2.0 Nivel AA por referencia. Esto significa que las agencias federales y sus contratistas deben asegurar que los sitios web, documentos y software cumplan con los criterios de WCAG 2.0 AA. En la práctica, muchas agencias apuntan a WCAG 2.1 o 2.2 para anticiparse a posibles actualizaciones del estándar.

EN 301 549 es el estándar armonizado europeo para la accesibilidad de las TIC. Mapea los requisitos de contenido web directamente a WCAG, actualmente en la versión 2.1 Nivel AA, y cubre una gama más amplia de productos de TIC, incluyendo software, hardware y documentos. EN 301 549 es referenciada por la European Accessibility Act, la EU Web Accessibility Directive y los requisitos de contratación pública en los Estados miembros de la UE.

Cómo evaluar el cumplimiento de WCAG 2.2

Evaluar el cumplimiento de WCAG requiere una combinación de enfoques. Ningún método por sí solo puede detectar todos los problemas, pero juntos proporcionan una cobertura integral. Los tres pilares de las pruebas de accesibilidad son las pruebas automatizadas, las pruebas manuales por expertos y las pruebas con usuarios con discapacidad.

Pruebas automatizadas

Las herramientas de pruebas automatizadas escanean las páginas web de forma programática y señalan los problemas que pueden detectarse mediante el análisis del código. Estas herramientas son rápidas, consistentes y excelentes para detectar una amplia gama de problemas comunes como texto alternativo faltante en imágenes, relaciones de contraste de color insuficientes, etiquetas de formulario ausentes, jerarquía de encabezados incorrecta, atributos de idioma faltantes y errores en el uso de ARIA. El escaneo automatizado es el mejor punto de partida para cualquier esfuerzo de accesibilidad porque identifica rápidamente los problemas más evidentes. Puedes escanear tu sitio web para verificar el cumplimiento de WCAG 2.2 usando nuestra herramienta gratuita para obtener un informe completo de hallazgos automatizados en cuestión de segundos. Las investigaciones del sector sugieren que las herramientas automatizadas detectan aproximadamente entre el 30 y el 40 por ciento de todos los problemas de WCAG.

Pruebas manuales

Las pruebas manuales implican que un evaluador humano trabaje con el sitio web utilizando tecnologías de asistencia y metodologías de evaluación. Esto incluye navegar por todo el sitio usando únicamente el teclado para verificar que todos los elementos interactivos son alcanzables, operables y tienen indicadores de foco visibles; usar lectores de pantalla como NVDA (gratuito, Windows), JAWS (Windows) y VoiceOver (integrado en macOS e iOS) para experimentar el sitio como lo haría un usuario ciego o con baja visión; verificar que todo el contenido se redistribuye correctamente al 400 por ciento de zoom; comprobar que los componentes personalizados tienen los roles, estados y propiedades ARIA correctos; evaluar si el orden de lectura tiene sentido lógico; y valorar la calidad y precisión del texto alternativo. Las pruebas manuales detectan problemas que las herramientas automatizadas no pueden, como determinar si el texto alternativo de una imagen es realmente significativo o si un widget interactivo complejo es verdaderamente usable con un lector de pantalla.

Pruebas con usuarios con discapacidad

Las pruebas con personas que realmente tienen discapacidad son la forma más completa de evaluación de accesibilidad. Mientras que las herramientas automatizadas verifican el código y los evaluadores manuales simulan la experiencia, los usuarios con discapacidad revelan barreras del mundo real que incluso los evaluadores expertos pueden pasar por alto. Un usuario de lector de pantalla puede descubrir que un formulario técnicamente conforme resulta confuso porque el orden de tabulación no coincide con el diseño visual. Un usuario con discapacidad cognitiva puede encontrar que un proceso que cumple todos los criterios de WCAG sigue siendo demasiado complejo para completarlo. Las pruebas con usuarios proporcionan información que ninguna cantidad de pruebas automatizadas o manuales puede replicar. Las organizaciones comprometidas con una accesibilidad genuina deberían incluir a personas con diversos tipos de discapacidad en sus programas de pruebas.

Hoja de ruta para cumplir con WCAG 2.2

Lograr el cumplimiento de WCAG 2.2 es un camino, no un proyecto puntual. La siguiente hoja de ruta proporciona un enfoque estructurado que organizaciones de cualquier tamaño pueden seguir para mejorar sistemáticamente su postura de accesibilidad web.

1. Audita tu estado actual. Comienza estableciendo una comprensión de referencia de dónde se encuentra tu sitio web hoy. Usa nuestro escáner gratuito como punto de partida para obtener una evaluación automatizada de tus páginas más críticas, incluyendo la página de inicio, las páginas de destino principales, los flujos de inicio de sesión y registro, y los formularios de contacto o de compra. Documenta la cantidad y gravedad de los problemas encontrados.
2. Prioriza los problemas críticos y graves. No todos los problemas de accesibilidad tienen el mismo impacto. Céntrate primero en los problemas que bloquean completamente el acceso para los usuarios con discapacidad (incumplimientos de Nivel A), y luego en los que crean barreras significativas (incumplimientos de Nivel AA). Dentro de cada nivel, prioriza los problemas que afectan al mayor número de usuarios o que aparecen en las páginas con más tráfico.
3. Corrige los problemas por principio POUR. Organiza tu trabajo de corrección en torno a los cuatro principios POUR. Comienza con los problemas de Perceptibilidad (texto alternativo faltante, subtítulos ausentes, contraste insuficiente), luego aborda los problemas de Operabilidad (acceso por teclado, gestión del foco, tiempos), seguidos de los problemas de Comprensibilidad (etiquetas de formulario, mensajes de error, navegación consistente), y finalmente los problemas de Robustez (marcado válido, atributos ARIA, mensajes de estado). Este enfoque garantiza una cobertura sistemática en lugar de correcciones puntuales.
4. Prueba con tecnologías de asistencia. Después de corregir los problemas, prueba tus páginas con tecnologías de asistencia reales. Navega usando solo el teclado, prueba con NVDA o VoiceOver, verifica el comportamiento de zoom y redistribución del contenido, y comprueba los objetivos táctiles en dispositivos móviles. Este paso detecta problemas que el escaneo automatizado pasa por alto y verifica que tus correcciones realmente funcionan como se esperaba.
5. Documenta la conformidad. Crea una declaración de accesibilidad o un Voluntary Product Accessibility Template (VPAT) que documente tu nivel de conformidad, las limitaciones conocidas y los planes de corrección. Una declaración de accesibilidad demuestra transparencia y buena fe, lo que puede ser valioso tanto desde el punto de vista legal como en términos de confianza pública. Obtén más información sobre cómo funciona nuestro escáner y cómo puede apoyar tu proceso de documentación.
6. Establece un monitoreo continuo. La accesibilidad no es una casilla que se marca una vez; es un compromiso permanente. El nuevo contenido, los cambios de diseño y las actualizaciones de código pueden introducir nuevos problemas en cualquier momento. Establece un calendario regular de escaneo, integra las comprobaciones de accesibilidad en tu pipeline de CI/CD, forma a tu equipo de contenidos en buenas prácticas de accesibilidad y realiza auditorías manuales periódicas para mantener la conformidad a lo largo del tiempo.

Preguntas frecuentes

¿Es WCAG 2.2 un requisito legal?

WCAG 2.2 no está incorporada directamente en la legislación de la mayoría de jurisdicciones, pero numerosas leyes y regulaciones la referencian como el estándar técnico de accesibilidad. La ADA en Estados Unidos, la European Accessibility Act en la UE, la Section 508 para agencias federales estadounidenses y la EN 301 549 en Europa apuntan a WCAG (generalmente en el Nivel AA) como referencia. Los tribunales de Estados Unidos han utilizado cada vez más la conformidad con WCAG como medida de cumplimiento de la ADA para sitios web. En la práctica, cumplir con WCAG 2.2 Nivel AA es el enfoque más seguro para gestionar el riesgo legal.

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

WCAG 2.2 añade nueve nuevos criterios de conformidad respecto a WCAG 2.1 y elimina uno (4.1.1 Parsing). Los nuevos criterios se centran en mejorar la experiencia de los usuarios con discapacidades cognitivas (autenticación accesible, entrada redundante), usuarios con baja visión (foco no oscurecido, apariencia del foco), usuarios con discapacidades motoras (tamaño mínimo de objetivo, movimientos de arrastre) y todos los usuarios (ayuda consistente). WCAG 2.2 es retrocompatible con WCAG 2.1, por lo que un sitio que cumple con 2.2 automáticamente cumple con 2.1.

¿Necesito cumplir con el Nivel AAA?

El Nivel AAA no suele exigirse como objetivo general de conformidad en ninguna ley o regulación. El W3C no recomienda el AAA como política general porque no es posible satisfacer todos los criterios AAA para cada tipo de contenido. El Nivel AA es el objetivo estándar para la mayoría de las organizaciones y marcos legales. Sin embargo, cumplir criterios AAA individuales siempre que sea viable, como relaciones de contraste mejoradas o interpretación en lengua de signos, puede mejorar aún más la accesibilidad para tus usuarios.

¿Pueden las herramientas automatizadas detectar todos los problemas de WCAG?

No. Las herramientas automatizadas de pruebas de accesibilidad pueden detectar aproximadamente entre el 30 y el 40 por ciento de los problemas de WCAG. Son excelentes para encontrar violaciones técnicas como texto alternativo faltante, contraste de color insuficiente, etiquetas de formulario ausentes y estructura de encabezados incorrecta. Sin embargo, muchos criterios de conformidad requieren juicio humano para evaluarlos, como determinar si el texto alternativo es significativo, si el contenido tiene un orden lógico o si los atributos ARIA se utilizan correctamente en widgets complejos. Una evaluación de accesibilidad integral requiere escaneo automatizado, pruebas manuales por expertos y pruebas con usuarios con discapacidad.

¿Cuándo se publicó oficialmente WCAG 2.2?

WCAG 2.2 se convirtió en Recomendación oficial del W3C el 5 de octubre de 2023. Es la versión estable más reciente de las Web Content Accessibility Guidelines y reemplaza a WCAG 2.1 como estándar vigente. Puedes explorar nuestro blog de accesibilidad para encontrar guías más detalladas sobre criterios específicos de WCAG y estrategias de cumplimiento.