Accesibilidad Web: Guía WCAG 2.2 para diseñadores

A partir del 28 de junio de 2025, el Acta Europea de Accesibilidad es obligatoria para todos los servicios digitales ofrecidos a ciudadanos de la UE: e-commerce, banca online, transporte, e-books y telecomunicaciones. Quienes no cumplan se arriesgan a sanciones de hasta 40.000 € por infracción, y el marco técnico de referencia es uno solo: las Web Content Accessibility Guidelines (WCAG) 2.2.

Si diseñas interfaces en 2026, conocer las WCAG ya no es opcional: es un requisito legal. En esta guía encontrarás todo lo que un diseñador debe saber para cumplir la normativa, explicado de forma práctica, sin lenguaje burocrático y con ejemplos concretos de errores y soluciones.

Qué aprenderás al leer esta guía:

• Qué son las WCAG y a quién se aplican en 2026
• Los 4 principios fundamentales (POUR) explicados con ejemplos
• La diferencia entre los 3 niveles de conformidad (A, AA, AAA)
• Las novedades de WCAG 2.2 respecto a WCAG 2.1
• Una checklist práctica para verificar tus interfaces
• Las herramientas de test gratuitas para integrar en tu workflow

¿Qué son las WCAG?

Las Web Content Accessibility Guidelines son el estándar internacional para hacer que los contenidos web sean accesibles para personas con discapacidades (visuales, motoras, auditivas, cognitivas). Son publicadas por el W3C (el consorcio que gobierna los estándares web) y se actualizan periódicamente.

La versión actual es WCAG 2.2, publicada como Recomendación del W3C el 5 de octubre de 2023. Sustituye a WCAG 2.1 de 2018, añadiendo 9 nuevos criterios de éxito para abordar necesidades surgidas con la difusión de dispositivos táctiles, la cognición y la movilidad reducida.

WCAG 2.2 es:

• Retrocompatible con WCAG 2.1: todo lo que era válido sigue siéndolo.
• Verificable técnicamente: cada criterio está escrito como una prueba de pasa/falla.
• Independiente de la tecnología: se aplica a HTML, PDF, apps nativas y documentos digitales.
• Obligatoria por ley en la UE desde el 28 de junio de 2025 para los servicios cubiertos por el Acta Europea de Accesibilidad.

Las WCAG no son burocracia: cada criterio existe porque, sin él, una categoría de personas no puede usar tu producto. Diseñar de forma accesible no es un favor, es hacer bien tu trabajo.

Los 4 principios (POUR)

WCAG 2.2 organiza todos los criterios de accesibilidad bajo 4 principios. El acrónimo para recordarlos es POUR:

P — Perceptible

El contenido debe ser perceptible por todos los sentidos disponibles.

Ejemplo concreto: una imagen sin alt es invisible para quien usa lectores de pantalla. Un vídeo sin subtítulos es inaccesible para personas sordas. Un texto con contraste insuficiente es ilegible para quien tiene baja visión.

Criterios principales:

• Alternativas textuales: cada imagen informativa tiene un alt descriptivo; las imágenes decorativas tienen alt="".
• Contraste de color: texto ≥ 4.5:1 (nivel AA), títulos grandes ≥ 3:1; para WCAG 2.2, también los controles de UI no textuales deben tener un contraste ≥ 3:1.
• Redimensionamiento de texto: el usuario debe poder ampliar el texto hasta un 200% sin pérdida de contenido o funcionalidad.
• Audio/vídeo: los vídeos deben tener subtítulos para todo el contenido hablado; el contenido solo de audio debe tener una transcripción.

O — Operable

Todas las funciones deben poder usarse sin ratón.

Millones de personas navegan solo con el teclado, con pulsadores o con control por voz. Si tu interfaz requiere un hover para acceder al menú, un usuario de teclado no puede usarla.

Criterios principales:

• Navegable por teclado: toda acción debe ser accesible con Tab, Enter, Espacio y las flechas. Sin "trampas de teclado".
• Foco visible: el elemento activo debe estar claramente resaltado (a menudo se prohíbe quitar el :focus con outline:none).
• Tiempo suficiente: si hay un temporizador, el usuario debe poder extenderlo o desactivarlo.
• Target size (WCAG 2.2): los botones y enlaces clicables deben ser de al menos 24×24 píxeles, un nuevo criterio pensado para personas con temblores o dificultades motoras.
• Sin convulsiones: ningún contenido debe parpadear más de 3 veces por segundo (riesgo de epilepsia).

U — Comprensible

El contenido y la interfaz deben ser comprensibles.

Criterios principales:

• Idioma declarado: el HTML debe tener <html lang="es"> (o el idioma correcto); las partes en otro idioma deben marcarse.
• Predecible: un elemento no debe cambiar de contexto sin que el usuario lo solicite explícitamente (nada de páginas que cambian al recibir el foco).
• Asistencia en la entrada de datos: los formularios deben tener etiquetas claras, mensajes de error específicos y ayudas contextuales.
• Sugerencias de corrección: si el usuario se equivoca en un campo, el mensaje de error debe indicar qué está mal y cómo corregirlo, no solo "error".

R — Robusto

El contenido debe funcionar con cualquier tecnología de asistencia, presente y futura.

Criterios principales:

• HTML válido: etiquetas cerradas correctamente, atributos bien formados, sin errores de parseo.
• Nombre, rol, valor: cada elemento interactivo debe tener un nombre (etiqueta), un rol (botón, enlace, input) y un valor (estado). Este es el trabajo de ARIA.
• Status messages (WCAG 2.1): los mensajes de confirmación, error o progreso deben ser anunciados por los lectores de pantalla sin cambiar el foco.

Los 3 niveles de conformidad

Cada criterio WCAG se clasifica en uno de tres niveles:

Nivel	Cuándo se aplica	Ejemplo práctico
A	Mínimo absoluto; sin él, el contenido es inutilizable para algunas personas	Texto alternativo en imágenes; sin trampas de teclado
AA	Estándar del sector exigido por la mayoría de las normativas	Contraste 4.5:1; tamaño de objetivo 24×24px
AAA	Nivel máximo, para sitios específicos (ej. servicios públicos)	Contraste 7:1; lengua de signos para cada vídeo

El nivel objetivo en 2026 es AA. Es el que exige el Acta Europea de Accesibilidad, la Section 508 de EE. UU. y la ley AODA de Canadá. El nivel AAA es un extra para sitios con usuarios específicos (ej. con discapacidades visuales graves), pero es muy restrictivo y no siempre compatible con las decisiones de marca.

Las novedades de WCAG 2.2

WCAG 2.2 añade 9 nuevos criterios de éxito (numerados del 2.4.11 al 3.3.9) y 4 actualizaciones a criterios existentes. Los 5 más importantes para un diseñador son:

1. Focus Not Obscured (2.4.11, nivel AA)

Cuando un elemento recibe el foco del teclado, debe ser totalmente visible. No puede estar parcial o totalmente oculto por un encabezado fijo (sticky header), un banner de cookies o un widget de chat.

Error común: una barra de navegación fija de 80px que cubre el campo de formulario que acaba de recibir el foco. El usuario de teclado no ve dónde está escribiendo.

Solución: añadir scroll-padding-top: 80px al CSS o gestionar el scroll al recibir el foco mediante JavaScript.

2. Target Size (2.5.8, nivel AA)

Los botones y enlaces clicables deben tener un tamaño de al menos 24×24 píxeles. El texto puede ser más pequeño, pero el área clicable debe cubrir 24×24.

Error común: iconos de redes sociales en el pie de página de 16×16 píxeles. Inaccesibles para personas con temblores.

Solución: aumentar el padding del elemento clicable o usar ::before para ampliar el área objetivo.

3. Consistent Help (3.2.6, nivel A)

Si tu interfaz ofrece mecanismos de ayuda (formulario de contacto, chat, enlace a FAQ), deben aparecer en la misma posición en cada página. El usuario no debería tener que "buscarlos" en el layout.

Error común: el enlace "Ayuda" arriba a la derecha en la home, abajo en el checkout y oculto en el menú hamburguesa en la página de producto.

4. Redundant Entry (3.3.7, nivel A)

Si pides al usuario una información que ya ha proporcionado en un paso anterior del mismo flujo, debes pre-rellenarla u ofrecerla para autocompletar.

Error común: un proceso de compra en 3 pasos que pide el "email" en el paso 1 y luego el "email de facturación" en el paso 3 sin pre-rellenarlo.

5. Accessible Authentication (3.3.8, nivel AA)

Los procesos de login no pueden requerir pruebas de memoria o transcripción cognitiva al usuario (ej. transcribir caracteres de una imagen CAPTCHA, recordar un código visto 10 segundos antes). Deben existir alternativas: biometría, gestores de contraseñas, enlaces por email.

Este criterio combate las "barreras cognitivas" en los inicios de sesión, que excluyen a personas con dificultades cognitivas o dislexia.

Checklist práctica WCAG 2.2 (Nivel AA)

Usa esta checklist antes de lanzar cualquier interfaz. Es la versión práctica, no la del W3C.

Perceptible:

• Cada <img> informativa tiene un alt descriptivo.
• Cada <img> decorativa tiene alt="".
• El contraste del texto es ≥ 4.5:1 (≥ 3:1 para texto ≥ 18pt).
• Los controles de UI (botones, campos, iconos activos) tienen un contraste ≥ 3:1 con su entorno.
• Los vídeos tienen subtítulos, y el audio, transcripción.
• La página es legible con un zoom del 200%.

Operable:

• Todas las acciones se pueden completar solo con el teclado.
• El elemento con foco es siempre visible (:focus-visible personalizado o por defecto).
• Ningún encabezado fijo oculta el elemento con foco.
• Los botones y enlaces tienen un área objetivo ≥ 24×24px.
• Ningún contenido parpadea más de 3 Hz.
• Hay un enlace "Saltar al contenido" al principio de cada página.

Comprensible:

• <html lang="es"> es correcto.
• Todos los inputs tienen una etiqueta (visible o con aria-label).
• Los mensajes de error indican qué está mal y cómo corregirlo.
• El texto de los enlaces describe su destino (nada de "clic aquí").
• Los elementos no cambian de contexto al recibir el foco.

Robusto:

• El HTML es válido (pasa el validador del W3C).
• Los componentes personalizados tienen el role, aria-label y estados de ARIA correctos.
• Los mensajes dinámicos (toasts, alertas) usan aria-live.

Herramientas de test gratuitas

Ninguna herramienta automática detecta el 100% de los problemas de accesibilidad —estudios de Nielsen Norman Group estiman que encuentran un 30-40%—, pero reducen significativamente el trabajo manual.

• axe DevTools: extensión para Chrome/Firefox de Deque. Gratuita, sin falsos positivos, es el estándar del mercado. Analiza una página y te dice exactamente dónde están los problemas y cómo solucionarlos.
• Lighthouse: integrado en las DevTools de Chrome. Da una puntuación de accesibilidad de 0 a 100. Menos preciso que axe, pero útil como prueba rápida.
• WAVE: de WebAIM. Visualiza los errores directamente sobre la página de forma gráfica. Útil para presentar problemas a stakeholders no técnicos.
• Stark: plugin para Figma que comprueba el contraste y simula daltonismos mientras diseñas. Excelente para diseñadores de UI.
• Contrast Checker de WebAIM: herramienta web sencilla para verificar el ratio de contraste entre dos colores.

Para profundizar en el tema de los colores accesibles, lee nuestra guía sobre diseño y daltonismo.

Errores comunes de accesibilidad en proyectos de España y LATAM

Estos son los que encontramos más a menudo en auditorías para clientes como Glovo, Cabify o startups en crecimiento:

• Placeholder en lugar de label: los placeholders desaparecen en cuanto el usuario empieza a escribir, y los lectores de pantalla los leen de forma inconsistente. Usa siempre <label> explícitas.
• Iconos sin texto: un icono de hamburguesa sin aria-label="Menú" es invisible para un lector de pantalla. Dos líneas de CSS no son suficientes: se necesita el nombre accesible.
• Carruseles que no se pueden detener: slideshows que se mueven automáticamente sin un botón de "pausa". Inaccesibles para personas con dificultades cognitivas que necesitan más tiempo para leer.
• Desplegables personalizados: componentes creados desde cero con <div> en lugar del <select> nativo. Casi siempre están rotos para los lectores de pantalla. Si no eres experto en ARIA, usa elementos HTML nativos.
• Texto sobre imagen sin contraste: banners principales con texto blanco sobre una foto colorida. Una capa oscura semitransparente detrás del texto suele ser suficiente para solucionarlo.

Preguntas frecuentes (FAQ)

¿Son obligatorias las WCAG 2.2 en España?

Sí. A partir del 28 de junio de 2025, son obligatorias para todos los servicios cubiertos por el Acta Europea de Accesibilidad: e-commerce, banca online, transporte, etc. Además, para el sector público en España, el Real Decreto 1112/2018 ya exige la conformidad con WCAG 2.1 AA. El incumplimiento puede acarrear sanciones significativas que pueden superar los 100.000 €.

¿Qué diferencia hay entre WCAG 2.1 y 2.2?

WCAG 2.2 añade 9 nuevos criterios de éxito (numerados del 2.4.11 al 3.3.9) sin eliminar ni modificar los anteriores. Si ya cumplías con la 2.1, para pasar a la 2.2 solo necesitas verificar los 9 nuevos. Los de mayor impacto son Focus Not Obscured, Target Size (mínimo 24×24px), Dragging Movements y Accessible Authentication.

¿Cuánto cuesta hacer accesible una web existente?

Depende del estado inicial y la complejidad. Un audit en España puede costar entre 2.000 y 5.000 €. La corrección de errores puede ir desde 5.000 € (web estática pequeña) hasta más de 50.000 € (un e-commerce complejo como el de Idealista). En LATAM, los costes en MXN o ARS pueden ser diferentes, pero el principio es el mismo: siempre es más económico diseñar de forma accesible desde el inicio. Añadir accesibilidad a posteriori puede costar 10 veces más.

¿Puede un diseñador sin perfil técnico trabajar en accesibilidad?

Sí, de hecho es fundamental. El 80% de los problemas de accesibilidad son problemas de diseño: contraste, tamaño del texto, jerarquía, claridad del copy, nombres de los componentes. El diseñador decide estas cosas antes de que el desarrollador escriba código. Un diseñador UX que conoce las WCAG previene el 80% de los problemas de raíz, dejando al desarrollador solo la implementación correcta del código.

¿Cómo aprendo WCAG en profundidad?

La documentación oficial del W3C es completa pero densa. Para un enfoque práctico, consulta las guías de WebAIM (en inglés), los artículos de NN/g o las guías del Observatorio de Accesibilidad Web del gobierno de España. El libro "Inclusive Design Patterns" de Heydon Pickering es el mejor manual en inglés. Si quieres una ruta de aprendizaje guiada en español, nuestro curso de Diseño UX tiene un módulo dedicado de 8 horas con ejercicios prácticos.

Próximos pasos

La accesibilidad es la habilidad que más distingue a un diseñador senior en 2026. Con la entrada en vigor del Acta Europea de Accesibilidad, empresas como Glovo, Cabify, Rappi o Nubank buscan activamente diseñadores con experiencia en WCAG, ofreciendo salarios más altos, especialmente en los sectores de finanzas, salud y sector público.

El curso completo de Diseño UX de CorsoUX incluye un módulo vertical sobre accesibilidad: teoría WCAG 2.2 aplicada, ejercicios de auditoría en proyectos reales, integración con Figma y un caso de estudio final de rediseño de una landing page no conforme. Al terminar, tendrás uno de los pocos certificados en español con un enfoque específico en WCAG 2.2 y el Acta Europea de Accesibilidad.

Mientras tanto, para empezar ahora mismo:

• Diseño y daltonismo: cómo diseñar pensando en el color — la parte visual de la accesibilidad
• Las 10 heurísticas de Nielsen — principios fundamentales que anticipan las WCAG
• La guía de Design Thinking — cómo integrar la accesibilidad en el proceso de diseño