WCAG 2.2 AA: checklist completa de accesibilidad web (55 criterios)

Para alcanzar el nivel AA de WCAG 2.2 no basta con cumplir los criterios marcados como AA: hay que satisfacer todos los criterios de nivel A y AA que resulten aplicables, además de cumplir los requisitos de conformidad de WCAG.

En total, WCAG 2.2 contiene 55 criterios de éxito de nivel A y AA: 31 de nivel A y 24 de nivel AA. Esta checklist los reúne en una sola página y los traduce a una pregunta mucho más útil para equipos de producto, agencias, marketing y desarrollo: qué tengo que revisar, cómo puedo probarlo y qué parte puede automatizarse.

No hemos intentado sustituir el estándar del W3C. Sería una mala idea. El texto normativo oficial sigue siendo la referencia. Lo que hacemos aquí es convertirlo en una guía operativa para trabajar sobre una web real sin perderse entre documentación, técnicas y excepciones.

WCAG 2.2 AA en 30 segundos

WCAG 2.2 se organiza en 4 principios y 13 pautas.
Los criterios de éxito se clasifican en A, AA y AAA.
Para conformidad AA hay que cumplir todos los criterios A + AA aplicables.
Esta checklist contiene los 55 criterios A y AA: 31 A y 24 AA.
WCAG 2.2 añadió 9 criterios nuevos respecto a WCAG 2.1; seis de ellos son A o AA y, por tanto, entran en esta checklist.
El antiguo criterio 4.1.1 Parsing quedó obsoleto y fue eliminado de WCAG 2.2.
Un checker automático puede detectar una parte importante de los problemas, pero no puede demostrar por sí solo la conformidad WCAG.


55 criterios A + AA	31 criterios nivel A	24 criterios nivel AA	4 principios POUR

Antes de revisar 55 criterios: empieza por saber qué encuentra una máquina en tu propia web Sprout Scan realiza comprobaciones automáticas relacionadas con accesibilidad y te ayuda a localizar incidencias antes de entrar en la revisión manual criterio por criterio.

Automatiza: errores detectables por software.

Prioriza: qué merece revisión primero.

Completa: después con pruebas humanas.

El escaneo automático no constituye por sí solo una declaración de conformidad WCAG ni una certificación legal.

Índice

Qué es WCAG 2.2
Qué significa nivel AA
Qué cambió en WCAG 2.2
Cómo usar esta checklist
Principio 1: Perceptible
Principio 2: Operable
Principio 3: Comprensible
Principio 4: Robusto
Los 5 requisitos de conformidad
Qué puede automatizarse
Cómo priorizar
Preguntas frecuentes

Qué es WCAG 2.2

WCAG son las Web Content Accessibility Guidelines, las Pautas de Accesibilidad para el Contenido Web desarrolladas por el W3C Web Accessibility Initiative. WCAG 2.2 fue publicada como Recomendación del W3C el 5 de octubre de 2023 y el propio grupo de trabajo recomienda utilizarla como objetivo actualizado.

WCAG no es una lista de trucos para mejorar Lighthouse. Es un estándar técnico internacional que define criterios verificables para hacer contenido web más accesible a personas con diferentes discapacidades.

Esta página está pensada para ejecutar una revisión criterio por criterio. Si buscas primero una introducción, consulta qué es WCAG, cómo se estructura y qué significan sus niveles. Para una visión más amplia del problema, visita nuestra guía de accesibilidad web.

Sus 13 pautas se organizan bajo cuatro principios, conocidos por sus iniciales en inglés como POUR:

Perceptible: la información y los componentes deben poder percibirse.
Operable: la interfaz y la navegación deben poder utilizarse.
Comprensible: la información y el funcionamiento deben poder entenderse.
Robusto: el contenido debe poder interpretarse de forma fiable por distintos agentes de usuario y tecnologías de asistencia.

La diferencia entre una pauta y un criterio es importante. Las pautas marcan el objetivo general. Los criterios de éxito son los elementos verificables que determinan la conformidad.

Qué significa realmente “cumplir WCAG 2.2 AA”

Hay tres niveles de conformidad: A, AA y AAA.

El error habitual es pensar que «nivel AA» significa revisar únicamente las filas marcadas como AA. No funciona así.

Para conformidad AA, una página debe satisfacer todos los criterios de nivel A y todos los criterios de nivel AA aplicables. Además, debe cumplir el resto de requisitos de conformidad que explicaremos más adelante.

Por eso esta guía contiene 55 criterios y no 24.

Una puntuación de 100 en una herramienta automática no equivale a conformidad WCAG 2.2 AA. La conformidad se determina mediante criterios y requisitos concretos. Una herramienta solo puede evaluar la parte que puede observar y testear de forma fiable.

Si quieres entender cómo combinar un checker con pruebas manuales, consulta nuestra guía sobre cómo comprobar la accesibilidad de una web.

Qué cambió de WCAG 2.1 a WCAG 2.2

WCAG 2.2 conserva esencialmente los criterios de 2.0 y 2.1, añade nuevos requisitos y elimina el antiguo criterio 4.1.1 Parsing, que quedó obsoleto.

Los nueve criterios nuevos son:

2.4.11 Focus Not Obscured (Minimum) — AA
2.4.12 Focus Not Obscured (Enhanced) — AAA
2.4.13 Focus Appearance — AAA
2.5.7 Dragging Movements — AA
2.5.8 Target Size (Minimum) — AA
3.2.6 Consistent Help — A
3.3.7 Redundant Entry — A
3.3.8 Accessible Authentication (Minimum) — AA
3.3.9 Accessible Authentication (Enhanced) — AAA

Para una organización que trabajaba contra WCAG 2.1 AA, los seis nuevos criterios A o AA son los que cambian directamente el objetivo de conformidad AA en 2.2.

Especialmente relevantes para interfaces actuales son el foco que queda oculto por cabeceras o banners, las interacciones que obligan a arrastrar, los objetivos táctiles demasiado pequeños, la repetición innecesaria de datos y las barreras cognitivas durante autenticación.

Cómo usar esta checklist WCAG 2.2 AA sin convertirla en una lista de casillas

Una checklist puede ser útil o puede crear una falsa sensación de seguridad.

La forma que recomendamos es esta:

Escanea primero. Deja que una herramienta localice los errores que puede comprobar de forma automática.
Trabaja por componentes y plantillas. Un fallo en un menú o formulario puede repetirse en cientos de URLs.
Prueba recorridos completos. No revises únicamente elementos aislados: compra, regístrate, busca, reserva o inicia sesión.
Evalúa criterio por criterio. Para cada criterio aplicable, conserva evidencia de cómo se ha comprobado.
No confundas “no detectado” con “cumplido”. Una herramienta puede no encontrar un error porque el criterio necesita contexto humano.
Repite después de cambios. La accesibilidad de una web viva puede degradarse.

La columna Automatización que verás a continuación no pertenece al W3C. Es una clasificación editorial de Sprout para ayudarte a decidir dónde puede aportar más valor un checker:

Alta: una parte importante de la comprobación puede automatizarse de forma determinista.
Parcial: la automatización puede detectar señales o fallos, pero necesita contexto humano.
Baja: la comprobación depende principalmente de interacción, intención, significado o recorrido.

Principio 1. Perceptible: 20 criterios A y AA

El principio perceptible busca que la información no dependa de una única capacidad sensorial. Texto alternativo, multimedia, estructura semántica, contraste, zoom y reflow viven aquí.

Criterio	Nivel	Nombre práctico	Qué exige	Prueba recomendada	Automatización
1.1.1	A	Contenido no textual	Todo contenido no textual relevante debe tener una alternativa que cumpla la misma función o transmita la información equivalente.	Oculta las imágenes o usa un lector de pantalla y comprueba si se pierde información necesaria.	Parcial
1.2.1	A	Solo audio y solo vídeo pregrabado	El contenido pregrabado que solo usa audio o solo vídeo necesita una alternativa adecuada, salvo excepciones previstas por WCAG.	Revisa cada pieza multimedia y confirma que existe una alternativa equivalente.	Baja
1.2.2	A	Subtítulos en contenido pregrabado	El audio hablado de vídeos pregrabados necesita subtítulos sincronizados cuando corresponda.	Reproduce el vídeo sin sonido y verifica que el contenido hablado y los sonidos relevantes siguen siendo comprensibles.	Baja
1.2.3	A	Audiodescripción o alternativa para vídeo pregrabado	La información visual relevante de vídeo pregrabado debe disponer de una alternativa accesible adecuada.	Revisa si una persona que no ve la imagen pierde información que no aparece en el audio.	Baja
1.2.4	AA	Subtítulos en directo	El contenido de audio en directo debe ofrecer subtítulos cuando el criterio resulte aplicable.	Comprueba retransmisiones y eventos en directo con el audio desactivado.	Baja
1.2.5	AA	Audiodescripción en vídeo pregrabado	La información visual necesaria para comprender un vídeo pregrabado debe poder percibirse mediante audiodescripción cuando corresponda.	Escucha el vídeo sin mirar la pantalla y detecta si faltan acciones, textos o cambios visuales esenciales.	Baja
1.3.1	A	Información y relaciones	La estructura, relaciones y significado que se perciben visualmente deben poder determinarse también por software o estar disponibles en texto.	Inspecciona encabezados, listas, tablas, labels y grupos de controles; después prueba con tecnología de asistencia.	Parcial
1.3.2	A	Secuencia significativa	Cuando el orden del contenido cambia su significado, ese orden debe poder determinarse correctamente.	Compara el orden visual con el orden del DOM y la lectura mediante teclado o lector de pantalla.	Parcial
1.3.3	A	Características sensoriales	Las instrucciones no deben depender exclusivamente de forma, tamaño, posición, orientación o sonido.	Busca textos como «pulsa el botón rojo de la derecha» y comprueba que exista otra forma de identificar el control.	Parcial
1.3.4	AA	Orientación	El contenido no debe obligar a usar una única orientación de pantalla salvo que sea esencial.	Gira el dispositivo o emula portrait y landscape y verifica que la funcionalidad se mantiene.	Parcial
1.3.5	AA	Identificar el propósito de los campos	Determinados campos que recogen datos personales deben permitir identificar programáticamente su propósito.	Revisa atributos de autocompletado y semántica de inputs habituales como nombre, email, dirección o teléfono.	Alta
1.4.1	A	Uso del color	El color no puede ser el único medio para transmitir información, indicar una acción o distinguir un elemento.	Visualiza la interfaz en escala de grises y comprueba errores, estados, enlaces y gráficas.	Parcial
1.4.2	A	Control del audio	Si una página reproduce audio automáticamente durante más de un breve periodo, el usuario debe poder detenerlo, pausarlo o controlar su volumen de forma independiente.	Carga la página con sonido activado y comprueba cualquier reproducción automática.	Parcial
1.4.3	AA	Contraste mínimo	El texto y las imágenes de texto deben alcanzar los ratios mínimos de contraste definidos por WCAG, salvo excepciones.	Mide texto normal, texto grande, enlaces y estados con una herramienta de contraste.	Alta
1.4.4	AA	Redimensionar texto	El texto debe poder ampliarse significativamente sin perder contenido ni funcionalidad, salvo excepciones.	Aumenta el zoom del navegador hasta el nivel exigido por el criterio y recorre la página.	Parcial
1.4.5	AA	Imágenes de texto	Siempre que sea posible, debe utilizarse texto real en lugar de imágenes que contienen texto, salvo excepciones.	Busca banners, creatividades y botones cuyo texto forme parte de una imagen.	Parcial
1.4.10	AA	Reflow	El contenido debe adaptarse a una ventana estrecha o a una ampliación elevada sin exigir desplazamiento en dos dimensiones, salvo contenido esencialmente bidimensional.	Prueba el ancho equivalente a 320 CSS px y revisa que tareas y contenido sigan disponibles.	Parcial
1.4.11	AA	Contraste no textual	Componentes de interfaz y objetos gráficos necesarios deben tener contraste suficiente respecto a colores adyacentes.	Mide bordes de inputs, iconos, estados seleccionados y controles que necesiten verse para operar.	Parcial
1.4.12	AA	Espaciado de texto	El contenido debe seguir funcionando cuando el usuario aumenta determinados valores de espaciado entre líneas, párrafos, letras y palabras.	Aplica los valores de espaciado indicados por WCAG mediante CSS y comprueba solapamientos o pérdidas.	Parcial
1.4.13	AA	Contenido al pasar el puntero o recibir foco	El contenido adicional que aparece con hover o foco debe poder descartarse, permanecer disponible cuando proceda y ser utilizable.	Prueba tooltips, menús y popovers con ratón, teclado y zoom.	Parcial

Principio 2. Operable: 20 criterios A y AA

Aquí se concentra una parte enorme de los problemas de experiencia real: teclado, foco, tiempos, destellos, navegación, gestos y tamaño de los controles.

Criterio	Nivel	Nombre práctico	Qué exige	Prueba recomendada	Automatización
2.1.1	A	Teclado	Toda funcionalidad debe poder operarse mediante teclado cuando la interacción no dependa esencialmente de una trayectoria física.	Guarda el ratón y completa las tareas esenciales usando solo teclado.	Parcial
2.1.2	A	Sin trampas de teclado	Si el foco entra en un componente mediante teclado, el usuario debe poder salir también mediante teclado.	Recorre modales, widgets, menús, reproductores y componentes incrustados con Tab y Shift+Tab.	Parcial
2.1.4	A	Atajos con teclas de caracteres	Los atajos basados únicamente en letras, números, signos o puntuación deben poder desactivarse, reasignarse o funcionar solo con foco cuando corresponda.	Prueba interfaces con atajos y confirma que no se activan accidentalmente durante escritura o dictado.	Baja
2.2.1	A	Tiempo ajustable	Cuando existe un límite de tiempo, el usuario debe poder desactivarlo, ampliarlo o ajustarlo salvo excepciones.	Busca sesiones, formularios, reservas y avisos temporizados y prueba qué ocurre al agotarse el tiempo.	Baja
2.2.2	A	Pausar, detener u ocultar	Contenido que se mueve, parpadea, se desplaza o se actualiza automáticamente debe poder pausarse o controlarse cuando cumpla las condiciones del criterio.	Revisa carruseles, tickers, banners rotatorios y bloques que se refrescan.	Parcial
2.3.1	A	Tres destellos o por debajo del umbral	El contenido no debe producir destellos que superen los límites definidos y puedan desencadenar convulsiones.	Revisa animaciones, vídeos y campañas con flashes; usa herramientas especializadas cuando sea necesario.	Parcial
2.4.1	A	Saltar bloques repetidos	Debe existir un mecanismo para evitar bloques repetidos y llegar al contenido principal de forma eficiente.	Pulsa Tab al cargar la página y comprueba si existe un enlace de salto o una estructura equivalente útil.	Parcial
2.4.2	A	Página con título	Cada página debe tener un título que describa su tema o propósito.	Revisa la pestaña del navegador y el elemento title en páginas representativas.	Alta
2.4.3	A	Orden del foco	El foco debe seguir un orden que preserve significado y operabilidad.	Navega con Tab y compara la secuencia con el orden visual y lógico de la tarea.	Parcial
2.4.4	A	Propósito de los enlaces en contexto	El propósito de cada enlace debe poder entenderse por su texto o por su contexto programáticamente asociado.	Busca enlaces genéricos como «más», «aquí» o «leer» y comprueba si su destino puede determinarse.	Parcial
2.4.5	AA	Múltiples vías	Dentro de un conjunto de páginas debe existir más de una forma de localizar una página, salvo pasos de un proceso o resultados.	Comprueba navegación, buscador, mapa del sitio, índices o enlaces contextuales.	Baja
2.4.6	AA	Encabezados y etiquetas	Los encabezados y labels deben describir el tema o propósito de forma útil.	Lee solo los encabezados y labels y comprueba si permiten anticipar el contenido o la acción.	Baja
2.4.7	AA	Foco visible	Los controles operables mediante teclado deben mostrar visualmente cuándo tienen el foco.	Recorre la página con Tab y verifica que nunca pierdes de vista el elemento activo.	Parcial
2.4.11	AA	Foco no oculto, mínimo	Cuando un componente recibe foco de teclado, no debe quedar completamente oculto por contenido creado por el autor.	Prueba cabeceras fijas, banners de cookies, chats y barras flotantes mientras navegas con teclado.	Parcial
2.5.1	A	Gestos del puntero	Las funciones que requieren gestos multipunto o basados en una trayectoria deben tener una alternativa de puntero simple, salvo que el gesto sea esencial.	Busca zoom, sliders, mapas o controles que exijan pellizcar, dibujar o seguir una trayectoria.	Baja
2.5.2	A	Cancelación del puntero	Las acciones activadas con un puntero deben permitir cancelar o deshacer activaciones accidentales según las condiciones del criterio.	Comprueba botones y controles con ratón y táctil, prestando atención al evento de pulsación.	Baja
2.5.3	A	Etiqueta incluida en el nombre	Cuando un control tiene texto visible, su nombre accesible debe contener ese texto para facilitar voz y tecnologías de asistencia.	Compara el texto visible del botón con su accessible name usando las herramientas del navegador.	Parcial
2.5.4	A	Activación por movimiento	Las funciones que responden al movimiento del dispositivo o del usuario deben poder operarse también mediante controles de interfaz y permitir desactivar el movimiento salvo excepciones.	Busca gestos de agitar, inclinar o mover el dispositivo y verifica alternativas.	Baja
2.5.7	AA	Movimientos de arrastre	Las funciones que requieren arrastrar deben ofrecer una alternativa que pueda realizarse sin arrastre, salvo que sea esencial.	Prueba sliders, ordenación, kanban, mapas y cargas de archivos buscando una alternativa de clic o teclado.	Baja
2.5.8	AA	Tamaño mínimo del objetivo	Los objetivos de puntero deben alcanzar el tamaño mínimo definido por WCAG o cumplir alguna de sus excepciones.	Mide iconos, enlaces pequeños, controles de carrusel, chips y botones próximos entre sí.	Parcial

Si todavía no has probado tu web, esta checklist es teoría Escanea una URL, mira qué problemas aparecen y vuelve a la tabla con un caso real delante. Es mucho más fácil entender WCAG cuando puedes relacionar cada criterio con tu propia interfaz.

Diagnóstico automático gratuito · Sin registro

Principio 3. Comprensible: 13 criterios A y AA

Una interfaz no es accesible si técnicamente puede operarse pero el usuario no entiende qué está ocurriendo. Idioma, consistencia, formularios, errores y autenticación son esenciales aquí.

Criterio	Nivel	Nombre práctico	Qué exige	Prueba recomendada	Automatización
3.1.1	A	Idioma de la página	El idioma principal de cada página debe poder determinarse programáticamente.	Comprueba el atributo `lang` del documento y que corresponda al idioma principal real.	Alta
3.1.2	AA	Idioma de las partes	Los fragmentos en otro idioma deben poder identificarse programáticamente cuando corresponda.	Busca citas, botones, frases o bloques en otros idiomas y revisa el atributo `lang` apropiado.	Parcial
3.2.1	A	Al recibir foco	Un componente no debe provocar un cambio inesperado de contexto simplemente por recibir foco.	Navega con Tab y verifica que el foco no abre ventanas, navega o envía datos por sí solo.	Baja
3.2.2	A	Al introducir datos	Cambiar el valor de un control no debe provocar un cambio inesperado de contexto sin aviso previo.	Prueba selects, radios, filtros y campos que actualizan o navegan automáticamente.	Baja
3.2.3	AA	Navegación consistente	Los mecanismos de navegación repetidos deben conservar un orden relativo coherente entre páginas, salvo cambios iniciados por el usuario.	Compara cabecera, menú, navegación secundaria y pie entre diferentes plantillas.	Baja
3.2.4	AA	Identificación consistente	Los componentes con la misma función deben identificarse de forma consistente dentro del sitio.	Compara iconos, botones, acciones y nombres usados para la misma función en distintas páginas.	Baja
3.2.6	A	Ayuda consistente	Si existen mecanismos de ayuda repetidos, deben aparecer en un orden relativo consistente entre páginas.	Compara contacto, ayuda, chat, FAQ o soporte en diferentes plantillas.	Baja
3.3.1	A	Identificación de errores	Cuando se detecta un error de entrada, debe identificarse el elemento afectado y describirse el error en texto.	Envía formularios con datos incorrectos y comprueba qué recibe cada usuario.	Parcial
3.3.2	A	Etiquetas o instrucciones	Cuando una entrada requiere información del usuario, deben proporcionarse labels o instrucciones suficientes.	Revisa formularios sin contexto visual y prueba si sigue estando claro qué debe introducirse.	Parcial
3.3.3	AA	Sugerencias ante errores	Si se conoce una forma de corregir un error, debe ofrecerse una sugerencia cuando sea posible y segura.	Provoca errores habituales y comprueba si el mensaje explica cómo resolverlos.	Baja
3.3.4	AA	Prevención de errores legales, financieros o de datos	En operaciones con consecuencias importantes deben existir mecanismos para revisar, corregir, confirmar o revertir según el caso.	Prueba compra, firma, eliminación de datos, transferencias y otros procesos críticos.	Baja
3.3.7	A	Entrada redundante	La información introducida previamente dentro del mismo proceso no debería volver a exigirse si puede autocompletarse o seleccionarse, salvo excepciones.	Recorre checkout, alta y formularios multipaso buscando datos que el usuario tenga que repetir.	Baja
3.3.8	AA	Autenticación accesible, mínimo	La autenticación no debe depender de una prueba cognitiva salvo que exista una alternativa o ayuda permitida por el criterio.	Prueba login y 2FA: copiar y pegar contraseñas, gestores, códigos y alternativas disponibles.	Baja

Principio 4. Robusto: 2 criterios A y AA

El objetivo es que componentes y mensajes puedan interpretarse de forma fiable por navegadores y tecnologías de asistencia, también cuando la interfaz utiliza JavaScript y controles personalizados.

Criterio	Nivel	Nombre práctico	Qué exige	Prueba recomendada	Automatización
4.1.2	A	Nombre, función y valor	Los componentes de interfaz deben exponer correctamente nombre, rol, estado y valor a navegadores y tecnologías de asistencia.	Inspecciona componentes personalizados con el árbol de accesibilidad y prueba cambios de estado.	Parcial
4.1.3	AA	Mensajes de estado	Los mensajes de estado relevantes deben poder ser detectados por tecnologías de asistencia sin obligar a mover el foco.	Añade un producto al carrito, filtra resultados o envía un formulario y comprueba cómo se anuncia el cambio.	Baja

Notarás que 4.1.1 Parsing no aparece. No es un olvido: W3C lo declaró obsoleto y lo eliminó de WCAG 2.2. Si una obligación contractual o política exige seguir reportando contra WCAG 2.0 o 2.1, puede ser necesario tratarlo separadamente.

Los 55 criterios no son toda la historia: los 5 requisitos de conformidad WCAG 2.2

Este punto separa una checklist útil de una afirmación seria de conformidad.

WCAG 2.2 establece cinco requisitos de conformidad:

Nivel de conformidad. Para AA deben satisfacerse todos los criterios A y AA, o proporcionarse una versión alternativa conforme en los términos previstos.
Páginas completas. La conformidad se aplica a páginas completas; no se puede excluir una parte problemática de la página.
Procesos completos. Si una página forma parte de un proceso, todas las páginas del proceso deben conformar al nivel declarado.
Uso de tecnologías de forma compatible con accesibilidad. Las formas de utilizar tecnologías de las que depende la conformidad deben estar soportadas de manera accesible.
No interferencia. Las tecnologías que no se usan de forma compatible con accesibilidad no pueden impedir que el resto de la página cumpla determinados requisitos esenciales.

Esto explica por qué «la home pasa el checker» no es una declaración válida de conformidad para un ecommerce entero.

Si el proceso de compra incluye producto, carrito, autenticación, dirección, pago y confirmación, el recorrido completo importa.

Qué parte de WCAG 2.2 AA puede comprobarse automáticamente

No existe un porcentaje universal que sirva para todas las herramientas y todas las webs. Depende de las reglas implementadas, la tecnología del sitio y la cantidad de contexto que necesita cada criterio.

Lo que sí puede decirse con seguridad es que la automatización funciona especialmente bien para detectar determinados fallos técnicos repetibles, por ejemplo:

ausencia de ciertos atributos;
idioma de página no declarado;
títulos ausentes;
determinadas relaciones semánticas incorrectas;
parte de los problemas de contraste;
determinados problemas de nombre, rol o valor;
patrones que pueden repetirse a escala en plantillas.

Y funciona peor cuando la pregunta requiere entender intención o experiencia:

si un texto alternativo explica realmente la imagen;
si un encabezado describe adecuadamente la sección;
si el orden del foco tiene sentido;
si un mensaje de error ayuda de verdad;
si un checkout completo puede realizarse con tecnología de asistencia;
si una autenticación introduce una barrera cognitiva.

La estrategia eficiente no es elegir entre máquina o persona. Es utilizar automatización para ampliar cobertura y encontrar patrones, y reservar el tiempo humano para los criterios que necesitan contexto.

Cómo pasar de 55 criterios a un plan de trabajo que un equipo pueda ejecutar

Si esta es la primera vez que tu organización trabaja sistemáticamente WCAG, no conviertas la checklist en 55 tickets independientes sin contexto.

Empieza por cuatro capas:

1. Bloqueos de negocio y usuario

Prioriza cualquier barrera que impida comprar, iniciar sesión, contactar, reservar, registrarse o completar una tarea esencial.

2. Componentes compartidos

Un menú inaccesible, un modal defectuoso o un campo de formulario mal construido puede estar presente en cientos de páginas. Corregir el componente base ofrece mucho más impacto que corregir URLs una a una.

3. Plantillas y sistemas de contenido

Si el CMS permite publicar imágenes informativas sin alternativa, si los editores pueden saltarse jerarquías o si una plantilla rompe el reflow, el problema está en el sistema, no en la persona que publicó la última página.

4. Monitorización

Una web que cumple hoy puede dejar de hacerlo después del siguiente release. Incorpora comprobaciones automáticas al flujo y programa revisiones manuales sobre recorridos y componentes clave.

El objetivo maduro no es «pasar WCAG una vez». Es construir una infraestructura y un proceso que hagan difícil volver a introducir los mismos errores.

Si además necesitas entender cómo encaja todo esto con obligaciones normativas en España, consulta nuestra guía sobre Ley 11/2023 y accesibilidad web.

Preguntas frecuentes sobre WCAG 2.2 AA

¿Cuántos criterios hay que cumplir para WCAG 2.2 AA? WCAG 2.2 contiene 55 criterios de éxito de nivel A y AA: 31 A y 24 AA. Para conformidad AA deben satisfacerse los criterios A y AA aplicables, además de los demás requisitos de conformidad.

¿WCAG 2.2 AA significa cumplir solo los criterios AA? No. El nivel AA incluye los requisitos del nivel A y del nivel AA. Los criterios AAA no son necesarios para declarar conformidad AA.

¿Cuántos criterios nuevos añadió WCAG 2.2? WCAG 2.2 añadió nueve criterios nuevos respecto a WCAG 2.1. Seis son de nivel A o AA y tres son AAA. Además, el criterio 4.1.1 Parsing fue eliminado por obsoleto.

¿Un checker automático puede certificar WCAG 2.2 AA? No por sí solo. Las herramientas automáticas pueden detectar muchos errores y ampliar la cobertura, pero varios criterios requieren contexto y evaluación humana. W3C también exige requisitos de conformidad que van más allá de obtener una puntuación.

¿Una web con 100 en Lighthouse Accessibility cumple WCAG? No necesariamente. El score de Lighthouse resume los tests que esa herramienta ejecuta. WCAG 2.2 AA exige evaluar criterios concretos y cumplir los requisitos de conformidad; una puntuación automática no es equivalente.

¿WCAG 2.2 reemplaza a WCAG 2.1? WCAG 2.2 amplía 2.1 y W3C recomienda adoptarla como objetivo actualizado. Sin embargo, una obligación legal, contractual o política concreta puede seguir haciendo referencia a otra versión o estándar relacionado.

¿Hay que cumplir WCAG 2.2 AAA? No para conformidad AA. Además, W3C no recomienda exigir AAA como política general para sitios completos porque algunos contenidos no pueden satisfacer todos los criterios AAA.

¿La checklist sirve como auditoría oficial? No. Sirve como guía operativa. Una evaluación de conformidad necesita aplicar la metodología adecuada, revisar las páginas y procesos relevantes y conservar evidencia suficiente de las pruebas.

¿WCAG 2.2 AA equivale automáticamente a cumplir la Ley 11/2023? No debe expresarse como una equivalencia automática. WCAG es un estándar técnico y la Ley 11/2023 es un marco jurídico. Para una conclusión legal hay que analizar la norma y los estándares aplicables al servicio concreto.

55 criterios son manejables cuando sabes por dónde empezar Utiliza Sprout Scan para detectar primero incidencias automatizables y después completa la evaluación manual sobre los criterios, componentes y recorridos que necesitan contexto.

Gratis · Sin registro · Resultado en aproximadamente 10 segundos. Sprout Scan es una herramienta de diagnóstico automático. No constituye por sí solo una declaración de conformidad WCAG, una auditoría manual completa ni asesoramiento jurídico.

WCAG 2.2 deja de parecer enorme cuando la conviertes en un sistema

Leída de principio a fin, WCAG puede parecer una especificación difícil de llevar al día a día de marketing, producto o una agencia.

La forma práctica de trabajarla es distinta: automatiza lo que pueda automatizarse, prueba manualmente lo que necesita contexto, corrige los componentes compartidos y vuelve a medir después de cada cambio importante.

Así, los 55 criterios dejan de ser una lista que se revisa una vez antes de una auditoría y se convierten en requisitos de calidad integrados en la forma de construir y mantener la web.

Ese es también el motivo por el que la accesibilidad escala mejor cuando se diseña en la infraestructura que cuando se añade al final.

Fuentes oficiales

W3C — Web Content Accessibility Guidelines (WCAG) 2.2.
W3C WAI — WCAG 2 Overview.
W3C WAI — What’s New in WCAG 2.2.
W3C WAI — Understanding Conformance.
W3C WAI — Selecting Web Accessibility Evaluation Tools.

Esta guía resume y parafrasea los criterios con finalidad práctica. Para realizar una evaluación formal, utiliza el texto normativo de WCAG 2.2 y la documentación oficial del W3C.