La WCAG 2.1 AA exige cumplir todos los criterios de éxito de nivel A y de nivel AA, que suman 50 puntos de control organizados bajo cuatro principios: perceptible, operable, comprensible y robusto. Este checklist recorre las áreas prácticas que más importan para el sitio web de una empresa típica, agrupadas según esos cuatro principios, para que pueda revisar su propio sitio de forma sistemática en lugar de adivinar qué cubre realmente “cumplir con AA”.
Dos cosas vale la pena saber antes de recorrer esta lista. Primero, es un recorrido práctico por las áreas que más importan para un sitio empresarial típico, no una reproducción literal de los 50 criterios de éxito; la documentación oficial del W3C es la fuente autorizada si necesita el lenguaje legal exacto. Segundo, “AA” es un nivel, no un estándar aparte: el nivel AA incluye todo lo exigido en el nivel A más los criterios adicionales de nivel AA, así que un sitio que afirma cumplir con AA necesita satisfacer ambos niveles juntos, no los criterios de AA de forma aislada.
Perceptible: si los usuarios pueden percibir el contenido en primer lugar
Contraste de color. El texto necesita una relación de contraste de al menos 4,5:1 frente a su fondo (3:1 para texto grande). Vale la pena revisar esto primero: el informe WebAIM Million de 2026 encontró que el 83,9% de las páginas de inicio tenía texto de bajo contraste, lo que lo convierte en el fallo más común de todo el conjunto de datos. El texto gris claro sobre fondo blanco, una elección de diseño todavía habitual en muchas plantillas de sitio modernas, es un culpable frecuente que vale la pena revisar específicamente.
Texto alternativo para las imágenes. Toda imagen con significado necesita una alternativa textual que describa su propósito o contenido; las imágenes puramente decorativas deben tener atributos alt vacíos para que los lectores de pantalla las omitan en lugar de anunciar algo sin sentido. Las fotos de producto, los gráficos informativos y los iconos que transmiten significado (como una marca de verificación que indica éxito) son las categorías que más se pasan por alto.
Subtítulos y transcripciones. El vídeo pregrabado necesita subtítulos, y el contenido exclusivamente de audio necesita una transcripción. Esto se aplica a cualquier contenido de vídeo incrustado, no solo al que haya producido usted mismo.
Texto ajustable. El texto debe poder ampliarse hasta el 200% sin pérdida de contenido ni de funcionalidad, y el contenido no debe depender de un diseño de píxeles fijo que se rompa al ampliar.
No depender solo del color. Cualquier información transmitida por el color (un borde rojo que indica un error de formulario, por ejemplo) necesita también un segundo indicador, como un icono o una etiqueta de texto, para los usuarios que no pueden percibir la diferencia de color.
Operable: si los usuarios pueden navegar e interactuar con todo
Acceso completo por teclado. Todo elemento interactivo (enlaces, botones, campos de formulario, widgets personalizados como menús desplegables o ventanas modales) debe poder operarse usando solo el teclado, sin trampas de teclado que impidan al usuario salir tabulando hacia atrás.
Indicador de foco visible. Cuando un usuario llega a un elemento con la tecla Tab, debe haber un indicador visible que muestre dónde está el foco en ese momento. Esta es un área que la WCAG 2.2 amplió más adelante, pero ya es un requisito de nivel AA bajo la 2.1.
Sin cambios de contenido inesperados. Los elementos no deben desencadenar automáticamente un cambio importante de contexto (como la carga de una nueva página) solo por recibir el foco, y el contenido no debe moverse de forma impredecible durante la interacción.
Texto de enlace y encabezados descriptivos. El texto de los enlaces debe tener sentido fuera de contexto (evite enlaces genéricos de “haga clic aquí”), y las páginas necesitan una estructura de encabezados lógica para que los usuarios de lectores de pantalla puedan navegar por nivel de encabezado.
Varias formas de encontrar el contenido. Un sitio generalmente necesita más de una forma de localizar una página determinada, como una función de búsqueda más un menú de navegación más un mapa del sitio, en lugar de exigir que los usuarios conozcan una ruta exacta.
Comprensible: si el contenido y el comportamiento son predecibles
Lenguaje e instrucciones claros. Los campos de formulario necesitan etiquetas claras, y las instrucciones deben ser comprensibles, en particular en torno a los campos obligatorios y los formatos de entrada esperados.
Navegación coherente. Los menús de navegación y los componentes repetidos deben aparecer en el mismo orden relativo en todas las páginas, para que los usuarios construyan un modelo mental preciso del sitio.
Identificación de errores y sugerencias. Cuando falla el envío de un formulario, el error concreto debe identificarse mediante texto (no solo con color) y, cuando sea posible, debe ofrecerse una sugerencia para corregirlo.
Comportamiento predecible al introducir datos. Cambiar el valor o la configuración de un campo de formulario no debe desencadenar automáticamente un cambio de contexto inesperado, como enviar el formulario o salir de la página, sin que el usuario realice una acción explícita.
Robusto: si el contenido funciona con la tecnología de asistencia
Marcado válido y bien estructurado. Aunque el antiguo criterio 4.1.1 Análisis se retiró en la WCAG 2.2, tener un HTML limpio y conforme con los estándares sigue importando en la práctica para un soporte fiable de la tecnología de asistencia.
Nombre, rol y valor adecuados para los componentes personalizados. Todo componente interactivo personalizado (un menú desplegable, un panel de pestañas o una ventana modal construidos desde cero en lugar de con elementos HTML nativos) necesita los roles, estados y propiedades ARIA correctos para que la tecnología de asistencia pueda identificarlo y usarlo correctamente.
Mensajes de estado. Las actualizaciones de estado dinámicas, como una confirmación de “producto añadido al carrito” o el resultado de la validación de un formulario, deben anunciarse a los usuarios de lectores de pantalla sin exigirles que muevan el foco manualmente.
Un orden sencillo para recorrer la lista
Intentar corregir los 50 criterios a la vez suele estancar un proyecto antes de que empiece, así que una priorización aproximada ayuda. Empiece por los problemas de alto impacto y fáciles de verificar: el contraste de color y el texto alternativo ausente, ya que ambos son comunes (los fallos de contraste por sí solos aparecieron en el 83,9% de las páginas de inicio en el estudio WebAIM Million de 2026) y sencillos de comprobar con un escáner. Pase después al acceso por teclado en sus flujos de conversión principales, ya que un usuario que no pueda completar el checkout o el registro solo con el teclado queda totalmente bloqueado, no solo incomodado. Luego trabaje en el etiquetado de formularios y los mensajes de error, que suele ser donde muchos componentes construidos a medida fallan en silencio, incluso en sitios que por lo demás parecen razonablemente accesibles. Deje para el final los criterios que requieren más juicio, como si la estructura de encabezados es realmente lógica o si un mensaje de estado se anuncia correctamente a un lector de pantalla, para una pasada de pruebas manuales dedicada una vez resueltos los problemas más mecánicos.
Cómo recorrer realmente este checklist
Las herramientas de escaneo automatizado, incluidas las construidas sobre el motor axe-core de Deque, muy utilizado, son una primera pasada genuinamente útil y detectarán rápidamente una parte real de estos problemas, en particular los de contraste y texto alternativo ausente. Pero las herramientas automatizadas no pueden evaluar todo lo de esta lista: si una estructura de encabezados es lógica, si una etiqueta ARIA es realmente precisa, o si un usuario de lector de pantalla puede completar su flujo de checkout en un orden razonable, todo eso requiere un evaluador humano, idealmente uno que use tecnología de asistencia real en sus flujos de usuario clave. Algunos proveedores, como Wawsome, combinan comprobaciones automatizadas basadas en widget con un verificador revisado por personas específicamente para cubrir esa carencia, mientras que otros, como UserWay, ofrecen un escaneo automatizado con un complemento opcional de auditoría manual profesional para una pasada más profunda.
Si no está seguro de si integrar este checklist en un proceso interno o buscar ayuda externa, nuestra guía sobre cómo elegir entre un widget y una auditoría manual explica cómo tomar esa decisión según los recursos de su equipo.