Lista de verificación de accesibilidad web: WCAG 2.2 para diseñadores que trabajan de verdad
Una lista de verificación de WCAG 2.2 organizada según dónde ocurre el trabajo: Figma, navegador, post-lanzamiento. Más un mapa de errores de diseñador por criterio.
La mayoría de las listas de verificación de accesibilidad web son inútiles para los diseñadores. Están organizadas por número de criterio de éxito de WCAG, que es como un abogado lee la especificación y como nadie construye software.
Los diseñadores no abren Figma pensando en el criterio 1.4.3. Abren Figma y eligen un color de texto. La lista de verificación útil se encuentra con el diseñador donde ocurre la decisión, lo que significa tres listas separadas: una para el archivo de diseño, una para el navegador, una para después del lanzamiento. Organízala de cualquier otra manera y se saltará.
Lo que WCAG 2.2 realmente requiere
WCAG 2.2 es el estándar global actual a partir de 2026, y agrega nueve nuevos criterios de éxito sobre WCAG 2.1, principalmente enfocados en móvil, objetivos táctiles, carga cognitiva y autenticación.
Los nueve nuevos criterios que importan a los diseñadores son una lista corta. La apariencia del foco se vuelve más estricta (2.4.11, 2.4.13). Los gestos de arrastre ahora necesitan una alternativa sin arrastre (2.5.7). Los objetivos táctiles tienen un tamaño mínimo de 24 por 24 píxeles CSS a menos que el objetivo tenga suficiente espacio alrededor (2.5.8). Se requiere una ubicación coherente de la ayuda en todas las páginas (3.2.6). Los formularios no pueden solicitar la misma información dos veces innecesariamente (3.3.7). La autenticación no puede depender de una prueba cognitiva como recordar una contraseña sin una alternativa (3.3.8, 3.3.9).
AA es el nivel requerido por la mayoría de las leyes de accesibilidad a nivel mundial, incluida la Ley Europea de Accesibilidad de la UE, la Sección 508 en los EE. UU. y las Regulaciones de Accesibilidad de Organismos del Sector Público del Reino Unido. AAA es más estricto y principalmente reservado para gobierno, salud y educación.
Una lista de verificación organizada por números de sección de WCAG es una especificación. Una lista de verificación organizada por dónde ocurre el trabajo es una herramienta.
El único formato de lista de verificación que funciona
Hay tres lugares donde se decide la accesibilidad. El archivo de diseño. La interfaz construida en un navegador. El sitio en producción después del lanzamiento.
Aproximadamente el 70% de los fallos de accesibilidad son decisiones tomadas en Figma, el 20% se toman en la implementación, y el 10% se filtran después del lanzamiento a través de cambios de contenido, incrustaciones de terceros o material generado por el usuario. Cualquier lista de verificación que no se mapee a esas tres fases está obligando al diseñador a traducir del lenguaje de la especificación al lenguaje del flujo de trabajo, y es en la traducción donde se saltan los elementos.
El resto de este artículo son las tres listas, en orden. Ejecútalas en orden. Cualquier cosa que falle la comprobación de la fase de diseño nunca debería llegar a la fase de construcción. Cualquier cosa que falle la fase de construcción nunca debería lanzarse.
Lista de verificación de la fase de diseño (lo que verificas en Figma)
Aproximadamente el 70% de los fallos de accesibilidad son decisiones tomadas en el archivo de diseño, lo que también significa que son los más baratos de corregir allí.
| Comprobación | Criterio WCAG 2.2 | Cómo verificar en Figma |
|---|---|---|
| El texto del cuerpo alcanza un contraste de 4.5:1 contra su fondo | 1.4.3 Contraste (Mínimo) | Stark, Able o el verificador de contraste integrado de Figma |
| El texto grande (18pt+ o 14pt+ negrita) alcanza 3:1 | 1.4.3 | Las mismas herramientas |
| Los elementos de interfaz no textuales (botones, bordes, iconos, anillos de foco) alcanzan 3:1 | 1.4.11 Contraste de elementos no textuales | Muestrear manualmente pares de colores en el lienzo |
| Los objetivos táctiles son de al menos 24 por 24 px CSS (se recomiendan 48 por 48) | 2.5.8 Tamaño del objetivo (Mínimo) | Medir las dimensiones del marco directamente |
| La información no se transmite únicamente por color | 1.4.1 Uso del color | Poner el marco en escala de grises (plugin de Figma o filtro de captura de pantalla) |
| Cada marco de imagen tiene texto alternativo en los metadatos de la capa | 1.1.1 Contenido no textual | Panel de accesibilidad de Figma o modo de desarrollo |
| Los encabezados se usan en un orden lógico (H1, H2, H3, no H1, H3, H2) | 1.3.1 Información y relaciones | Leer el árbol de encabezados de arriba hacia abajo |
| El estado de foco está diseñado para cada elemento interactivo | 2.4.7 Foco visible, 2.4.11 Foco no oscurecido | Cada componente interactivo tiene una variante de foco |
| El texto del enlace tiene sentido fuera de contexto | 2.4.4 Propósito del enlace | Sin etiquetas "haz clic aquí" o "saber más" |
| Las etiquetas de formulario son visibles, no solo de marcador de posición | 3.3.2 Etiquetas o instrucciones | Cada campo tiene una etiqueta persistente fuera del input |
El archivo de diseño es también donde se detectan los nuevos criterios móviles de WCAG 2.2. Los objetivos táctiles que fallan 2.5.8 casi siempre fallan porque el diseñador estaba pensando en píxeles de escritorio y el objetivo es un icono de 16 píxeles sin relleno.
Para una inmersión más profunda en el contraste específicamente, ver reglas de contraste y APCA. El trabajo de color en la fase de diseño es donde la mayoría de los sitios pierden la auditoría antes de que se escriba una línea de código.
Lista de verificación de la fase de construcción (lo que verificas en el navegador)
El navegador es donde las decisiones de accesibilidad se prueban o se exponen, porque es el primer lugar donde la tecnología de asistencia real toca tu trabajo.
| Comprobación | Criterio WCAG 2.2 | Cómo verificar en el navegador |
|---|---|---|
| Cada página funciona solo con teclado (tab, shift-tab, enter, espacio, teclas de flecha) | 2.1.1 Teclado | Desconectar el ratón y navegar por la página |
| El orden del foco sigue el orden visual (de izquierda a derecha, de arriba hacia abajo en LTR) | 2.4.3 Orden del foco | Usar Tab y observar el anillo de foco |
| El foco nunca está oculto por encabezados fijos, banners de cookies o modales | 2.4.11 Foco no oscurecido (Mínimo) | Desplazarse mientras se usa Tab para confirmar la visibilidad |
| Las interacciones de arrastre tienen una alternativa de clic o toque | 2.5.7 Movimientos de arrastre | Verificar controles deslizantes, listas ordenables, carruseles |
| El enlace "saltar al contenido" aparece en el primer Tab | 2.4.1 Omitir bloques | Presionar Tab una vez al cargar la página |
| Se usan puntos de referencia HTML (header, nav, main, footer, aside) | 1.3.1, 4.1.2 | Inspeccionar el esquema del DOM |
| Los errores de formulario se anuncian, no solo se codifican por color | 3.3.1, 3.3.3, 4.1.3 | Enviar un formulario con errores con un lector de pantalla |
| El lector de pantalla anuncia correctamente encabezados, listas y botones | 4.1.2 Nombre, Rol, Valor | NVDA en Windows, VoiceOver en Mac, TalkBack en Android |
| Los atributos de autocompletado están configurados en campos de datos personales | 1.3.5 Identificar el propósito del input | Inspeccionar autocomplete en campos de nombre, email, dirección |
| Los medios tienen subtítulos, transcripciones o descripciones de audio | 1.2.1 a 1.2.5 | Reproducir cada vídeo, verificar las pistas |
Las herramientas automatizadas detectan aproximadamente el 30% de estos. El resto necesita un humano presionando Tab y escuchando un lector de pantalla. Ambos importan, y ninguno reemplaza al otro.
El mejor conjunto de herramientas para la etapa del navegador en 2026 es pequeño: axe DevTools para escaneo automatizado, Lighthouse para auditorías a nivel de página, y un lector de pantalla real para el paso manual. Tres herramientas, diez minutos por página, detecta casi todo lo que una auditoría real marcaría.
Lista de verificación post-lanzamiento (lo que verificas en producción)
La accesibilidad no termina en el lanzamiento, porque el contenido, las incrustaciones de terceros y el material generado por el usuario se lanzan después de que el diseñador ha dado el visto bueno.
| Comprobación | Criterio WCAG 2.2 | Cómo verificar en producción |
|---|---|---|
| Las imágenes creadas por el CMS tienen texto alternativo obligatorio a nivel del editor | 1.1.1 | Probar el CMS: ¿puede un autor publicar sin alt? |
| Los widgets de terceros integrados (chat, mapas, formularios) son accesibles | Varía | Ejecutar axe en páginas con incrustaciones |
| Las descargas en PDF y los documentos están etiquetados y son legibles | 1.1.1, 1.3.1, 2.4.6 | Abrir en el verificador de accesibilidad de Acrobat |
| Los enlaces de ayuda, soporte y contacto están en el mismo lugar en cada página | 3.2.6 Ayuda coherente (novedad en WCAG 2.2) | Auditoría visual en todas las plantillas |
| Los formularios no solicitan información redundante en un flujo | 3.3.7 Entrada redundante (novedad en WCAG 2.2) | Recorrer formularios de varios pasos |
| La autenticación tiene una alternativa accesible (passkeys, enlaces por email, SSO) | 3.3.8, 3.3.9 Autenticación accesible (novedad en WCAG 2.2) | Probar el registro e inicio de sesión con un gestor de contraseñas bloqueado |
| El contenido dinámico (modales, notificaciones, regiones en vivo) se anuncia | 4.1.3 Mensajes de estado | Activar cada uno con un lector de pantalla abierto |
| La página continúa cumpliendo las reglas de contraste y tamaño de objetivo después de que el usuario escala al 200% de zoom | 1.4.4 Cambio de tamaño del texto, 1.4.10 Redistribución | Ampliar el navegador al 200% y verificar |
| No hay medios con reproducción automática, o los medios tienen un control de pausa | 1.4.2 Control de audio, 2.2.2 Pausar, detener, ocultar | Cargar la página desde cero |
| El banner de cookies no atrapa el foco del teclado | 2.1.2 Sin trampa de teclado | Usar Tab para entrar al banner y volver a salir |
La lista post-lanzamiento es donde la mayoría de los equipos fallan. El diseño se lanzó de forma accesible. Los autores del CMS lo llenan de PDFs sin etiquetar, vídeos con reproducción automática y un widget de chat con una relación de contraste de 2:1 en su lanzador. La accesibilidad es una propiedad del sistema, no un hito de lanzamiento.
Errores comunes de los diseñadores mapeados a criterios WCAG
Cada hallazgo de una auditoría de accesibilidad se remonta a un criterio de éxito de WCAG específico, y la mayoría de los diseñadores comete los mismos cinco errores contra los mismos cinco criterios.
| Error del diseñador | Lo que realmente es | Criterio WCAG 2.2 que viola |
|---|---|---|
| Texto de marcador de posición como única etiqueta | Los usuarios pierden la etiqueta en el momento en que empiezan a escribir | 3.3.2 Etiquetas o instrucciones |
| Botones solo con icono sin aria-label ni tooltip | Los lectores de pantalla anuncian "botón" sin ningún propósito | 4.1.2 Nombre, Rol, Valor |
| Mensajes de error mostrados solo con borde rojo o texto rojo | Los usuarios con daltonismo no ven ningún error | 1.4.1 Uso del color, 3.3.1 Identificación de errores |
| Anillo de foco eliminado por estética | Los usuarios de teclado no pueden ver dónde están | 2.4.7 Foco visible |
| Objetivos táctiles de menos de 24 por 24 px sin espaciado | Los usuarios móviles fallan continuamente al tocar | 2.5.8 Tamaño del objetivo (Mínimo) |
| Bajo contraste en la interfaz "sutil" (texto de marcador de posición, estados desactivados, texto de ayuda) | Los lectores bajo el sol o con baja visión no pueden leerlo | 1.4.3 Contraste (Mínimo), 1.4.11 Contraste de elementos no textuales |
| Modal que atrapa el foco pero no tiene cierre con ESC | Los usuarios de teclado quedan atrapados en el modal | 2.1.2 Sin trampa de teclado |
| Carruseles con navegación solo por arrastre | Los usuarios con discapacidad motora no pueden avanzar | 2.5.7 Movimientos de arrastre |
| Encabezado fijo que oculta el elemento enfocado al usar Tab | Los usuarios ven la página desplazarse pero pierden el rastro de su posición | 2.4.11 Foco no oscurecido |
| Inicio de sesión solo con contraseña, sin SSO ni enlace por email | Fallo de carga cognitiva | 3.3.8 Autenticación accesible |
Los mismos diez errores conforman la mayoría de cada informe de auditoría. Corrígelos y estarás al 80% del camino hacia WCAG 2.2 AA antes de que cualquier consultor abra una hoja de cálculo.
Los conceptos básicos de accesibilidad también se conectan con el resto de una buena jerarquía visual. El contraste, el tamaño del objetivo y los estados de foco son decisiones de jerarquía. Un diseño que domina la jerarquía domina la mayor parte de la lista de verificación de accesibilidad por defecto, por lo que la superposición entre una buena teoría del color y el diseño accesible es casi total.
Cómo ejecutar la lista de verificación sin quemar una semana
La lista de verificación solo es útil si ejecutarla lleva minutos, no días, lo que significa que las herramientas deben hacer la mayor parte del trabajo.
El ritmo de trabajo son tres pasadas, una por fase, cada una realizada en el momento en que el trabajo alcanza esa fase. No las tres al final. Ni una de ellas al final. Tres pasadas separadas, cada una económica, cada una aplicada por herramientas donde sea posible.
- Pasada de diseño: 10 minutos por pantalla. Stark o el verificador de contraste de Figma en cada par de texto, poner el marco en escala de grises para probar información solo por color, medir cada objetivo táctil. Hazlo antes de la entrega, no durante la revisión.
- Pasada de construcción: 10 minutos por plantilla. Escaneo de axe DevTools, prueba de navegación solo con teclado, una pasada de lector de pantalla en las páginas más visitadas. Integrar axe-core en CI para que el nuevo código no pueda fusionarse con regresiones.
- Pasada de lanzamiento: mensual, no por versión. Rastreo completo del sitio con axe o pa11y en producción, auditoría de PDF en cualquier biblioteca de documentos, recorrido manual de formularios y flujos de autenticación.
Eso es medio día de trabajo al mes por producto y quizás 15 minutos por entrega de diseño. Más que eso y el equipo dejará de ejecutarla. Menos que eso y las auditorías regresarán sin corregir.
Preguntas frecuentes
¿Es WCAG 2.2 legalmente obligatorio?
Sí, en la mayoría de los mercados principales. La Ley Europea de Accesibilidad entró en vigor en junio de 2025 y hace referencia como mínimo a WCAG 2.1, con 2.2 como el estándar de trabajo actual. La Sección 508 en los EE. UU. hace referencia a WCAG 2.0, pero los contratos de adquisición requieren cada vez más la versión 2.2. Canadá, el Reino Unido, Australia y Japón tienen requisitos similares vinculados a WCAG 2.1 o 2.2. Si distribuyes a alguno de esos mercados, AA de WCAG 2.2 es el objetivo seguro.
¿Cuáles son los nuevos criterios de WCAG 2.2 que realmente necesito conocer?
Cuatro importan más para los diseñadores. 2.5.7 Movimientos de arrastre requiere una alternativa sin arrastre para las interacciones de arrastre. 2.5.8 Tamaño del objetivo (Mínimo) requiere objetivos táctiles de al menos 24 por 24 píxeles CSS con suficiente espaciado. 2.4.11 Foco no oscurecido requiere que el elemento enfocado permanezca visible durante el desplazamiento y bajo superposiciones fijas. 3.3.8 Autenticación accesible prohíbe las pruebas cognitivas como recordar una contraseña sin una alternativa (SSO, passkey o enlace por email).
¿Necesito una lista de verificación separada para móvil?
No. WCAG 2.2 está escrito explícitamente para cubrir dispositivos móviles y táctiles, que es por qué tantos de sus nuevos criterios (tamaño de objetivo, arrastre, foco) son conscientes del móvil. La misma lista de verificación de tres fases funciona para web móvil y diseño responsivo. Las aplicaciones nativas tienen directrices adicionales específicas de la plataforma (HIG de Apple y Accesibilidad de Android), pero las reglas de WCAG siguen aplicando.
¿Cuál es el tamaño mínimo del objetivo táctil en WCAG 2.2?
24 por 24 píxeles CSS es el mínimo bajo 2.5.8 Tamaño del objetivo (Mínimo), pero hay excepciones si los objetivos tienen suficiente espaciado alrededor o están en línea con el texto. El objetivo práctico al que la mayoría de los diseñadores debería aspirar es 48 por 48 píxeles CSS, que coincide con las recomendaciones de plataforma de Apple y Google y evita los casos extremos de la especificación de WCAG.
Lanza la lista de verificación, no las suposiciones
La accesibilidad no es una tarea de cumplimiento. Es una propiedad del diseño, construida en tres momentos, aplicada por herramientas, verificada por humanos.
Los equipos que lanzan sitios accesibles sin dolor no son los que tienen los mejores auditores. Son los que movieron las comprobaciones a la fase de diseño, la fase de construcción y la fase de lanzamiento, y se negaron a dejar que el trabajo avanzara más allá de cualquiera de ellas con fallos conocidos.
Ejecuta las tres listas. Detecta los diez errores comunes antes de que se acumulen. Automatiza los escaneos de la etapa del navegador en CI. Audita la deriva post-lanzamiento mensualmente. WCAG 2.2 AA deja de ser una línea de llegada y se convierte en una propiedad de cómo trabaja el equipo.
Elige hoy una superficie de un producto en tu sitio. Ejecuta la lista de verificación de la fase de diseño contra su archivo de Figma. Cuenta las correcciones. Ese número es el coste de no haber ejecutado esto antes.
Lanza la lista de verificación, no las suposiciones.
Need a site that passes WCAG 2.2 without a three-month remediation cycle? Brainy ships accessible design from the first Figma frame.
Get Started
