Tu web puede estar incumpliendo hasta 9 criterios de accesibilidad web sin que lo sepas. Las WCAG 2.2, la versión vigente de las pautas del W3C, incorporan nuevos requisitos que afectan a elementos tan cotidianos como el tamaño de los botones, los formularios de varios pasos o el inicio de sesión, y la mayoría de los fallos que detectamos en auditorías no son errores de código complejos: son decisiones de diseño que nadie revisó. Con la European Accessibility Act (EAA) ya en vigor desde junio de 2025 y la norma EN 301 549 apuntando a adoptar estas pautas como referencia, cumplir WCAG 2.2 ha dejado de ser una recomendación técnica para convertirse en una obligación con consecuencias reales. En este artículo repasamos los 9 nuevos criterios, los incumplimientos más habituales y cómo abordar su corrección paso a paso.
¿Qué son las WCAG 2.2 y por qué importan ahora?
Las WCAG 2.2 son las pautas de accesibilidad para el contenido web que publica el W3C. Su propósito no ha cambiado desde la primera versión: que cualquier persona, con o sin discapacidad, pueda percibir, entender, navegar e interactuar con una web. Lo que sí ha cambiado es el alcance y la exigencia técnica. La versión 2.2 se convirtió en Recomendación oficial del W3C el 5 de octubre de 2023 y fue republicada con correcciones editoriales el 12 de diciembre de 2024. Es, a día de hoy, la versión vigente de la familia WCAG 2.
La estructura se mantiene sobre los cuatro principios POUR o niveles de accesibilidad web WCAG: perceptible (texto alternativo, contraste, subtítulos), operable (navegación por teclado, gestos alternativos), comprensible (contenido claro y predecible) y robusto (compatibilidad con navegadores y tecnologías de asistencia). Sobre esa base, WCAG 2.2 incorpora 9 nuevos criterios de conformidad y deja obsoleto el criterio 4.1.1 (Procesamiento), que ya no aportaba valor real dado cómo funcionan hoy los navegadores y los lectores de pantalla.
El dato que más debería preocupar a cualquier responsable de web: la mayoría de los incumplimientos que detectamos en auditorías no son errores de código complejos. Son decisiones de diseño que nadie revisó frente a estas 9 pautas.
De WCAG 2.1 a WCAG 2.2: qué cambia y qué no
La transición de WCAG 2.1 a WCAG 2.2 es incremental, no una reescritura. Si partías de una web conforme con WCAG 2.1 nivel AA, el camino a WCAG 2.2 se reduce a revisar 9 criterios adicionales, ya que la compatibilidad es retroactiva: cumplir WCAG 2.2 implica automáticamente cumplir 2.1 y 2.0.
Cambio | Detalle |
|---|---|
Criterios añadidos | 9 nuevos: 2 de nivel A, 4 de nivel AA y 3 de nivel AAA. |
Criterio eliminado | 4.1.1 Procesamiento (Parsing) queda obsoleto. Las tecnologías de asistencia ya no analizan el HTML directamente. |
Colectivos beneficiados | Mayor atención a discapacidades cognitivas y de aprendizaje, limitaciones motoras y baja visión. |
Compatibilidad retroactiva | Cumplir WCAG 2.2 implica cumplir también WCAG 2.1 y 2.0. El trabajo previo no se pierde. |
El único criterio que desaparece es el 4.1.1 (Procesamiento). No es una concesión: los validadores automáticos que lo comprobaban siguen siendo útiles para detectar HTML con errores graves, pero el criterio en sí dejó de tener sentido cuando los lectores de pantalla pasaron a depender de las APIs de accesibilidad del sistema operativo, no del árbol HTML.
Los 9 nuevos criterios de WCAG 2.2
A continuación, se detallan los nueve criterios agrupados por nivel de conformidad. Para cada uno se incluye qué exige, a qué colectivo beneficia de forma más directa y un ejemplo real de incumplimiento con su solución.
Nivel A: mínimo obligatorio
El nivel A es el suelo de la conformidad. Estos dos criterios son especialmente relevantes para personas con discapacidad cognitiva y para cualquier usuario que se enfrente a procesos de varios pasos, como un proceso de compra o un formulario de registro.
1. 3.2.6 Ayuda consistente (Consistent Help) — Nivel A
Si una web ofrece mecanismos de ayuda (número de teléfono, chat, formulario de contacto, enlace a preguntas frecuentes), estos deben aparecer en el mismo orden relativo en todas las páginas. No se trata de que el botón de ayuda esté siempre en la esquina superior derecha, sino de que su posición sea predecible respecto al resto de elementos.
- Incumplimiento habitual: una tienda online muestra el chat de soporte en la barra superior en la página de inicio, pero lo traslada al pie de página en la ficha de producto. El usuario que lo busca mientras intenta completar un pedido no lo encuentra donde lo vio antes.
- Solución: fijar la posición del acceso a la ayuda en el layout global (cabecera o pie) y mantenerla en todas las plantillas.
2. 3.3.7 Entrada redundante (Redundant Entry) — Nivel A
Dentro de un mismo proceso no debe solicitarse dos veces la misma información al usuario. Si ya la introdujo, debe autocompletarse o poder seleccionarse de nuevo. Las excepciones son razonables: contraseñas, datos que requieren confirmación por razones de seguridad o información que ha quedado desactualizada.
- Incumplimiento habitual: un proceso de compra en varios pasos donde el usuario introduce su dirección de envío y, en el paso de facturación, el sistema vuelve a presentar el campo vacío. Si la dirección es la misma, el usuario ha tenido que teclearla dos veces.
- Solución: añadir una casilla «La dirección de facturación coincide con la de envío» o rellenar el campo automáticamente a partir de lo ya introducido.
Nivel AA: el estándar exigible por ley
El nivel AA es el que exige la normativa de accesibilidad web europea (EAA, EN 301 549) y el que habitualmente se incluye en los pliegos de contratación pública. Estos cuatro criterios son los que más webs suspenden en las auditorías que realizamos, con especial incidencia en las versiones móviles.
3. 2.4.11 Foco no oculto — mínimo (Focus Not Obscured, Minimum) — Nivel AA
Cuando un componente recibe el foco del teclado, no puede quedar completamente tapado por contenido generado por el propio sitio: banners de cookies, cabeceras fijas (sticky headers) o ventanas de chat flotantes. El criterio permite que el elemento quede parcialmente oculto, pero no que desaparezca del todo a la vista.
- Incumplimiento habitual: al navegar con el tabulador, el elemento enfocado queda detrás de la cabecera fija. El usuario que navega sin ratón no sabe dónde está el foco en pantalla.
- Solución: configurar scroll-padding-top en CSS para que el desplazamiento de página reserve espacio para la cabecera. También puede resolverse ajustando el z-index de los elementos flotantes para que no se superpongan al área de contenido.
4. 2.5.7 Movimientos de arrastre (Dragging Movements) — Nivel AA
Toda función que dependa del gesto de arrastre (drag) debe ofrecer una alternativa ejecutable con un solo toque o clic. Beneficia principalmente a personas con limitaciones de movilidad o con temblor, que no pueden controlar con precisión un movimiento sostenido.
- Incumplimiento habitual: un control deslizante de rango de precios que solo responde al arrastre. Sin alternativa, una persona con temblor esencial o con un puntero poco preciso no puede utilizarlo con fiabilidad.
- Solución: añadir botones de incremento y decremento (« – » y « + ») o campos numéricos editables que permitan introducir el valor directamente.
5. 2.5.8 Tamaño del objetivo — mínimo (Target Size, Minimum) — Nivel AA
Los elementos activables (botones, enlaces, iconos) deben tener un área de interacción mínima de 24 × 24 píxeles CSS, o bien disponer de suficiente espacio alrededor como para que no puedan activarse por error. Es uno de los criterios con mayor impacto en interfaces móviles.
- Incumplimiento habitual: iconos de redes sociales de 16 px colocados en el pie de página sin separación entre ellos. Un usuario con baja precisión motriz activa el icono equivocado por proximidad.
- Solución: ampliar el área táctil a un mínimo de 24 × 24 px mediante padding, o separar los iconos al menos 24 px entre sí si no puede aumentarse su tamaño visual.
6. 3.3.8 Autenticación accesible — mínimo (Accessible Authentication, Minimum) — Nivel AA
Ningún paso del inicio de sesión puede requerir una prueba de función cognitiva (recordar una contraseña, resolver un puzle, transcribir un CAPTCHA de texto distorsionado) sin ofrecer una alternativa. Debe permitirse pegar contraseñas y usar gestores de contraseñas.
- Incumplimiento habitual: un formulario de login que bloquea el atributo paste en el campo de contraseña y, además, obliga a superar un CAPTCHA de caracteres deformados sin alternativa accesible. Esto es una barrera doble para personas con dislexia, memoria reducida o dificultades cognitivas.
- Solución: eliminar la restricción de pegado, ofrecer alternativas al CAPTCHA (audio, enlace mágico por correo, autenticación biométrica) y permitir la integración con gestores de contraseñas.
Nivel AAA: máxima exigencia
El nivel AAA no se exige de forma global, pero es el estándar recomendable en servicios críticos: banca, salud, administración pública o cualquier portal donde el error de un usuario tenga consecuencias reales.
7. 2.4.12 Foco no oculto — mejorado (Focus Not Obscured, Enhanced) — Nivel AAA
Refuerza el criterio 2.4.11 eliminando la excepción parcial: el elemento con foco no debe quedar oculto ni siquiera de forma parcial por contenido del sitio. La visibilidad del foco debe ser total.
8. 2.4.13 Apariencia del foco (Focus Appearance) — Nivel AAA
El indicador de foco visible debe cumplir requisitos mínimos de tamaño y contraste: un área equivalente a un contorno de 2 px de grosor alrededor del componente y una relación de contraste de al menos 3:1 frente al color adyacente. Esto garantiza que el foco sea visible no solo cuando existe, sino cuando puede distinguirse con claridad.
9. 3.3.9 Autenticación accesible — mejorado (Accessible Authentication, Enhanced) — Nivel AAA
Igual que el 3.3.8, pero sin las excepciones de reconocimiento de objetos o de contenido personal. Es la versión más estricta del criterio de autenticación: ninguna prueba cognitiva, sin excepciones.
Tabla resumen de los 9 criterios
La siguiente tabla sirve como referencia rápida para auditorías y reuniones técnicas.
Nº | Criterio | Nivel | Colectivo principal |
|---|---|---|---|
3.2.6 | Ayuda consistente | A | Discapacidad cognitiva y de aprendizaje |
3.3.7 | Entrada redundante | A | Carga cognitiva y memoria |
2.4.11 | Foco no oculto (mínimo) | AA | Usuarios de teclado |
2.5.7 | Movimientos de arrastre | AA | Movilidad reducida y temblores |
2.5.8 | Tamaño del objetivo (mínimo) | AA | Motricidad fina y uso en móvil |
3.3.8 | Autenticación accesible (mínimo) | AA | Memoria y discapacidad cognitiva |
2.4.12 | Foco no oculto (mejorado) | AAA | Usuarios de teclado (refuerzo) |
2.4.13 | Apariencia del foco | AAA | Baja visión y usuarios de teclado |
3.3.9 | Autenticación accesible (mejorado) | AAA | Máxima exigencia de inicio de sesión |
Cómo abordar el cumplimiento: plan en 7 pasos
Conocer los criterios es la parte fácil. La parte difícil es convertirlos en tareas concretas dentro de un proyecto real, especialmente cuando hay que justificar el esfuerzo ante un cliente o un equipo de desarrollo. Este orden ha funcionado en los proyectos que hemos acompañado:
- Auditoría de partida. Combinar herramientas automáticas (axe, WAVE, TAW) con revisión manual de los 9 criterios. Ninguna herramienta automática detecta por sí sola el 100 % de los problemas.
- Priorización por nivel e impacto. Los criterios de nivel A y AA son los legalmente exigibles. Empezar por ellos. Los de nivel AAA se pueden planificar en una segunda fase.
- Revisión de formularios y autenticación. Los criterios 3.3.7 y 3.3.8 suelen resolverse con cambios de lógica de front-end o de configuración, sin tocar el back-end.
- Navegación por teclado. Recorrer la web completa con el tabulador y verificar que ningún elemento con foco quede oculto (2.4.11). No hay herramienta automática que lo haga bien.
- Inventario de objetivos táctiles. Revisar todos los botones, iconos y enlaces en vista móvil. El criterio 2.5.8 se incumple con frecuencia en componentes heredados de librerías de UI sin actualizar.
- Homogeneización de la ayuda. Verificar que los accesos a soporte (chat, teléfono, FAQ) aparecen en la misma posición en todas las plantillas (3.2.6).
- Documentación y monitorización. Publicar o actualizar la declaración de accesibilidad y establecer una cadencia de revisión periódica. La accesibilidad se degrada con el tiempo si no hay control.
Los incumplimientos que más se repiten
Tras auditar webs de sectores muy distintos, el patrón es recurrente. Estos son los fallos que aparecen una y otra vez:
- Banners de cookies que tapan el foco. El contenedor del banner tiene z-index alto y se superpone al elemento enfocado. Incumple 2.4.11 de forma casi sistemática en webs que han integrado soluciones de gestión de consentimiento sin ajustar la accesibilidad.
- CAPTCHAs sin alternativa. El CAPTCHA visual sin opción de audio ni alternativa de otro tipo bloquea a usuarios con dislexia, baja visión o discapacidad cognitiva. Incumple 3.3.8.
- Iconos de redes sociales en el pie. Por debajo de 24 × 24 px, suspenden el criterio 2.5.8. Es un error muy extendido porque muchas plantillas tienen estos iconos definidos a 16 o 18 px por defecto.
- Sliders sin alternativa al arrastre. Los controles deslizantes de precio o de filtrado de resultados son el caso más frecuente de incumplimiento del criterio 2.5.7. A menudo se resuelven en una tarde añadiendo inputs numéricos.
- Formularios de varios pasos que repiten campos. El criterio 3.3.7 no se vulnera solo en los checkouts: también en formularios de solicitud de presupuesto, registros de usuario o procesos de tramitación que preguntan lo mismo en pasos distintos.
WCAG 2.2 y el marco legal vigente: EAA y EN 301 549
La European Accessibility Act (EAA) es aplicable desde el 28 de junio de 2025 y afecta a empresas privadas de sectores como el comercio electrónico, la banca, el transporte y las telecomunicaciones. En España se traspuso mediante la Ley 11/2023. No es, por tanto, una perspectiva futura: es una obligación en vigor.
El estándar técnico de referencia para el cumplimiento legal es la norma EN 301 549, que actualmente incorpora WCAG 2.1 nivel AA como base técnica. Se espera una actualización de la norma que adopte WCAG 2.2. Mientras esa actualización no se produce, cumplir WCAG 2.2 ya garantiza el cumplimiento de la versión vigente de la norma y anticipa la siguiente.
Un matiz importante: el Real Decreto 1112/2018, que sigue siendo la referencia para webs del sector público, también toma como base la EN 301 549. La secuencia de actualizaciones normativas apunta en una sola dirección: adoptar WCAG 2.2 ahora es la opción con menor riesgo de quedar desactualizados.
Qué esperamos cuando empezamos una auditoría WCAG 2.2
Los criterios que más sorprenden a los equipos de desarrollo no son los más técnicos. Son el 2.5.8 (tamaño de objetivo) y el 3.3.8 (autenticación accesible). Casi nadie los tiene en su radar cuando empieza el proyecto, y sin embargo son dos de los incumplimientos más frecuentes que encontramos.
Una auditoría rigurosa no consiste en pasar un validador automático y exportar el informe. Implica navegar la web completa con teclado, probar con lectores de pantalla como NVDA o JAWS en entornos Windows y VoiceOver en macOS/iOS, y revisar cada formulario y proceso de autenticación como lo haría un usuario real. La herramienta automática detecta quizá un 30-40 % de los problemas reales; el resto requiere criterio humano.
Cuando detectamos un incumplimiento, lo documentamos con el criterio de éxito afectado, el nivel de impacto, la URL y el elemento concreto, y una propuesta de solución con el nivel de esfuerzo estimado. El objetivo no es generar un informe extenso, sino que el equipo de desarrollo pueda priorizar y actuar sin ambigüedad.
Preguntas frecuentes sobre WCAG 2.2
¿Cuántos criterios nuevos añade WCAG 2.2?
Nueve: 2 de nivel A, 4 de nivel AA y 3 de nivel AAA. Además, elimina el criterio 4.1.1 (Procesamiento), que quedó obsoleto.
¿Cumplir WCAG 2.2 implica cumplir también las versiones anteriores?
Sí. La compatibilidad es retroactiva: una web conforme con WCAG 2.2 cumple automáticamente con WCAG 2.1 y WCAG 2.0.
¿Es obligatorio cumplir WCAG 2.2 en España?
La obligación legal vigente se apoya en WCAG 2.1 nivel AA a través de la EN 301 549 y la EAA. WCAG 2.2 será el estándar de referencia en la próxima actualización de la norma. Aplicarla ya, además de ser la opción técnicamente correcta, elimina el riesgo de tener que hacer una segunda ronda de correcciones cuando la actualización normativa se produzca.
¿Cuál es el criterio que más se incumple en la práctica?
En nuestra experiencia, el 2.5.8 (tamaño del objetivo) y el 2.4.11 (foco no oculto) lideran el ranking de incumplimientos, con especial incidencia en webs que tienen cabeceras fijas o que han integrado banners de gestión de consentimiento sin revisar el comportamiento del foco.
¿Por qué se eliminó el criterio 4.1.1 Procesamiento?
Porque los lectores de pantalla modernos ya no analizan el HTML directamente: utilizan las APIs de accesibilidad del sistema operativo (MSAA, UIA, ATK). Los errores de HTML que antes impactaban en la accesibilidad ahora se detectan y corrigen en esas capas intermedias. El criterio 4.1.1 había perdido su razón de ser.
WCAG 2.2 no reinventa la accesibilidad. Añade nueve criterios específicos que responden a necesidades reales de usuarios con discapacidades cognitivas, motoras y de baja visión, y elimina uno que ya no era útil. La mayoría de los incumplimientos que generan tienen solución técnica sencilla: ajustar un tamaño de elemento, añadir un campo alternativo, corregir un z-index. La complejidad no está en la solución, sino en saber que el problema existe.
Integrar estas pautas desde el diseño cuesta una fracción de lo que cuesta corregirlas en una web ya publicada. Y el beneficio en usabilidad no se limita a los colectivos con discapacidad: un botón con área táctil suficiente, un formulario que no repite preguntas o un login que acepta gestores de contraseñas mejora la experiencia de cualquier usuario.
