Lista de verificación WCAG 2.2 AA para productos SaaS y aplicaciones web

WCAG 2.2 AA para SaaS: login, formularios, diálogos, navegación SPA, tablas, gráficas, arrastrar y soltar, sesiones y el ACR que piden los compradores.

Equipo editorial de FixReportsActualizado el 26 de octubre de 202610 min de lectura

Un producto SaaS tiene dos superficies de accesibilidad: el sitio de marketing que lo vende y la aplicación que la gente usa todos los días. El sitio de marketing falla de las mismas formas que cualquier sitio web, con poco contraste, falta de texto alternativo y formularios sin etiquetas. La aplicación suma sus propios problemas: procesos de inicio de sesión que bloquean los administradores de contraseñas, cuadros de diálogo que atrapan el foco del teclado, navegación de una sola página que los lectores de pantalla no detectan, tablas de datos y gráficas sin texto, funciones de arrastrar y soltar sin alternativa y sesiones que vencen sin aviso. Esta lista de verificación recorre el nivel AA de WCAG 2.2 según las partes de un producto SaaS típico.

Puntos clave

WCAG 2.2 se convirtió en Recomendación del W3C en octubre de 2023 y agregó nueve criterios de conformidad, seis de ellos de nivel A o AA (W3C (se abre en una pestaña nueva)).
Autenticación accesible (3.3.8, AA) significa que un inicio de sesión no puede depender de recordar o transcribir una contraseña, a menos que se pueda pegar o usar un administrador de contraseñas (W3C (se abre en una pestaña nueva)).
Los objetivos interactivos deben medir al menos 24 por 24 píxeles CSS o tener suficiente espacio a su alrededor (2.5.8, AA) (W3C (se abre en una pestaña nueva)).
Mensajes como “Guardado” o “3 resultados” deben llegar a los lectores de pantalla sin mover el foco (4.1.3, AA) (W3C (se abre en una pestaña nueva)).
Los compradores de empresas y del sector público suelen pedir un informe de conformidad de accesibilidad (ACR, Accessibility Conformance Report), normalmente redactado con la plantilla VPAT del Information Technology Industry Council (ITI (se abre en una pestaña nueva)).

¿Por qué la accesibilidad importa más en un SaaS que en un sitio informativo?

La gente usa un producto SaaS durante horas, muchas veces porque lo eligió su empleador. Una barrera en una página de marketing hace perder un visitante; una barrera en el producto puede impedir que alguien haga su trabajo. Por eso los clientes grandes, las universidades y los organismos públicos preguntan cada vez más por la accesibilidad antes de comprar, y por eso la respuesta tiene que abarcar la aplicación, no solo el sitio web.

También importa porque las pruebas automatizadas solo detectan una parte del problema. Herramientas como axe-core encuentran fallas en el marcado, como etiquetas faltantes o poco contraste. No pueden saber si un cuadro de diálogo devuelve el foco al lugar correcto, si los datos de una gráfica están disponibles como texto o si un flujo de trabajo se puede completar con el teclado. Una aplicación necesita tanto revisiones automatizadas como pruebas manuales.

¿Cómo se hacen accesibles el registro y el inicio de sesión?

La autenticación es donde WCAG 2.2 agregó el requisito nuevo más importante para los SaaS.

Permite pegar y usar administradores de contraseñas (3.3.8, AA). No bloquees la acción de pegar en los campos de contraseña o de código, y usa autocomplete="username", autocomplete="current-password" y autocomplete="one-time-code" para que los navegadores y los administradores de contraseñas puedan completarlos.
Evita que los acertijos sean la única forma de entrar. Un CAPTCHA que pide transcribir texto distorsionado o resolver un rompecabezas es una prueba de función cognitiva. Ofrece una alternativa, y da preferencia a las verificaciones que no requieren ninguna acción del usuario (W3C (se abre en una pestaña nueva)).
Etiqueta todos los campos (1.3.1 y 3.3.2, A). Usa una <label> visible conectada a su campo; el texto de marcador de posición desaparece cuando alguien escribe y no es una etiqueta.
Identifica los errores con texto (3.3.1, A) y sugiere cómo corregirlos (3.3.3, AA). “La contraseña debe tener al menos 12 caracteres” ayuda; un borde rojo por sí solo no.
No preguntes dos veces (3.3.7, A). Si un registro de varios pasos ya pidió el nombre de la empresa o una dirección, complétalos automáticamente o deja que la persona los seleccione en lugar de volver a escribirlos.
Mantén la ayuda en el mismo lugar (3.2.6, A). Si ofreces chat, un enlace de ayuda o datos de contacto, colócalos en la misma posición relativa en todas las páginas del proceso.

¿Qué patrones de formularios y errores causan más fallas?

Los formularios concentran la mayoría de las fallas de las aplicaciones. El estudio de WebAIM de 2026 sobre un millón de páginas de inicio encontró campos de formulario sin etiqueta en el 51% de ellas (WebAIM (se abre en una pestaña nueva)), y las aplicaciones tienen muchos más formularios que las páginas de inicio.

Dale a cada campo un nombre programático y agrupa los controles relacionados, como los botones de opción, con <fieldset> y <legend>.
Informa de los errores donde la persona los vaya a notar: mueve el foco a un resumen de errores al principio del formulario, o al primer campo no válido, y enlaza cada elemento del resumen con su campo.
Indica los campos obligatorios con texto, no solo con el color (1.4.1, A).
No envíes el formulario ni cambies de contexto cuando alguien solo selecciona una opción (3.2.2, A); espera una acción explícita.

¿Cómo deben comportarse los cuadros de diálogo, los menús y las ventanas emergentes?

Los componentes personalizados son donde más seguido falla la compatibilidad con el teclado y con los lectores de pantalla. La Guía de prácticas de creación de WAI-ARIA (ARIA Authoring Practices Guide) describe el comportamiento esperado de cada patrón (W3C (se abre en una pestaña nueva)).

Cuadros de diálogo: mueve el foco al cuadro de diálogo cuando se abre, mantén el Tab dentro de él mientras esté abierto, ciérralo con Escape y devuelve el foco al control que lo abrió. Usa el elemento nativo <dialog> o role="dialog" con aria-modal="true" y un nombre.
Sin trampas para el teclado (2.1.2, A): de todos los componentes se debe poder salir con el teclado.
Foco visible (2.4.7, AA) que no quede oculto detrás de encabezados fijos, banners de cookies o widgets de chat (2.4.11, AA, nuevo en 2.2).
Información emergente y ventanas emergentes (1.4.13, AA) que se puedan cerrar con Escape, sobre las que se pueda pasar el cursor sin que desaparezcan y que permanezcan hasta que se cierren.
Atajos de una sola tecla (2.1.4, A): si presionar una letra ejecuta una acción, permite desactivar los atajos o reasignarlos, o haz que solo funcionen cuando el componente correspondiente tiene el foco.

¿Cómo se maneja la navegación en una aplicación de una sola página?

En una aplicación de una sola página (SPA), la URL cambia sin que se cargue una página nueva, así que es posible que los lectores de pantalla no anuncien que pasó algo.

Actualiza el título del documento en cada cambio de ruta, para que cada vista tenga un título descriptivo (2.4.2, A).
Mueve el foco al encabezado principal de la nueva vista, o anuncia el cambio en una región activa no intrusiva (polite); frameworks como Next.js incluyen un anunciador de rutas para esto.
Mantén un orden del foco lógico (2.4.3, A): después de eliminar un elemento, el foco debe ir a un elemento cercano que tenga sentido, no regresar al principio de la página.
Ofrece una forma de saltar la navegación repetida (2.4.1, A), como un enlace para saltar al contenido o regiones de referencia (landmarks).

¿Cómo se hacen accesibles los paneles, las tablas de datos y las gráficas?

Tablas: usa un marcado <table> real, con <th> y scope para los encabezados, y un título (1.3.1, A). Las cuadrículas construidas con elementos <div> necesitan el patrón grid de ARIA completo, que es mucho más difícil de implementar bien.
Gráficas: dale a cada gráfica una alternativa textual que exponga la idea principal, y ofrece los datos en una tabla (1.1.1, A). No dependas solo del color para distinguir las series (1.4.1, A); agrega etiquetas o tramas.
Contraste: el texto necesita 4.5:1 (1.4.3, AA), y las líneas de las gráficas, los íconos y los bordes de los campos necesitan 3:1 frente a su fondo (1.4.11, AA). Revisa el modo oscuro por separado. Nuestro verificador de contraste de color prueba cualquier par de colores.
Mensajes de estado (4.1.3, AA): “Guardado”, “Carga completa” y los conteos de resultados deben usar role="status" o una región activa, para que los lectores de pantalla los escuchen sin perder su posición.

¿Qué cambian los nuevos criterios de WCAG 2.2 en las aplicaciones web?

Criterio	Nivel	Qué significa en una aplicación
2.4.11 Foco no oculto (mínimo)	AA	Las barras de herramientas fijas, los banners y los widgets de chat no deben tapar por completo el elemento con el foco
2.5.7 Movimientos de arrastre	AA	Todo lo que se hace arrastrando, como reordenar un tablero kanban, necesita una alternativa con un solo puntero, por ejemplo un menú o botones de subir y bajar
2.5.8 Tamaño del objetivo (mínimo)	AA	Botones y enlaces de al menos 24 × 24 píxeles CSS, o separados de forma que un círculo de 24 píxeles alrededor de cada uno no se superponga con otro
3.2.6 Ayuda consistente	A	Enlaces de ayuda, chat y datos de contacto en el mismo lugar relativo en todas las páginas
3.3.7 Entrada redundante	A	La información ya ingresada en el mismo proceso se completa automáticamente o se puede seleccionar
3.3.8 Autenticación accesible (mínima)	AA	Inicio de sesión sin memorizar ni transcribir, a menos que se permita pegar, usar administradores de contraseñas u otro método

WCAG 2.2 también eliminó el 4.1.1 Procesamiento, que ya no tiene ningún efecto práctico en la accesibilidad (W3C (se abre en una pestaña nueva)).

¿Y los tiempos de espera, el diseño y el zoom?

Vencimiento de la sesión (2.2.1, A): avisa antes de que venza una sesión y permite extenderla con una acción sencilla, a menos que el límite de tiempo sea esencial o supere las 20 horas. Guardar el trabajo en curso evita el peor resultado.
Reflujo (1.4.10, AA): el contenido debe funcionar con un ancho de 320 píxeles CSS (el equivalente a hacer zoom al 400% en una pantalla de 1280 píxeles) sin desplazarse en dos direcciones; las tablas de datos y los contenidos similares están exentos.
Espaciado del texto (1.4.12, AA): aumentar el interlineado y el espaciado entre letras no debe cortar el texto, algo que suelen hacer los contenedores de altura fija.
Orientación (1.3.4, AA): no bloquees la aplicación en vertical o en horizontal, a menos que sea esencial.

¿Qué es un ACR y lo necesitas?

Un informe de conformidad de accesibilidad (ACR) documenta cómo cumple un producto cada criterio de accesibilidad: lo admite, lo admite parcialmente o no lo admite, con observaciones. La mayoría se redactan con la plantilla VPAT que publica el Information Technology Industry Council, que tiene ediciones para WCAG, para las normas de la Sección 508 de Estados Unidos y para la norma europea EN 301 549 (ITI (se abre en una pestaña nueva)).

Las agencias federales de Estados Unidos deben comprar tecnología accesible conforme a la Sección 508 (Section508.gov (se abre en una pestaña nueva)), y los organismos públicos de la UE se basan en la EN 301 549, así que a los productos B2B que venden a esos clientes se les suele pedir un ACR durante el proceso de compra. Un ACR honesto, que enumera las carencias conocidas, es más útil para los compradores que uno que afirma una compatibilidad total. Debe basarse en pruebas del producto, incluidas pruebas manuales; un análisis automatizado no basta para completarlo.

Si vendes a consumidores de la UE, la Ley Europea de Accesibilidad también puede aplicarse a tu forma de vender en línea; nuestra guía sobre la EAA explica su alcance. Esto no es asesoría legal.

¿Cómo debe probar la accesibilidad un equipo de SaaS?

Automatiza lo básico. Ejecuta axe-core o un motor similar en tus pruebas de extremo a extremo y en el sitio de marketing, y haz que el build falle cuando aparezcan infracciones nuevas. Nuestro verificador de accesibilidad gratuito ejecuta el mismo motor en cualquier página pública.
Prueba con el teclado. Completa tus flujos principales, como registrarte, crear un registro y cambiar la configuración, usando solo Tab, Shift+Tab, Enter, la barra espaciadora, Escape y las teclas de flecha.
Prueba con un lector de pantalla. NVDA en Windows y VoiceOver en macOS e iOS son gratuitos. Revisa que se anuncien los nombres, los roles, los estados y los mensajes.
Haz zoom y cambia el tamaño. Revisa el texto ampliado al 200% y una ventana de 320 píxeles de ancho.
Corrige en el sistema de diseño. La mayoría de las fallas vienen de componentes compartidos; corregir un botón o un cuadro de diálogo una vez lo corrige en todas partes.

Preguntas frecuentes

¿WCAG aplica a las partes de una aplicación web que requieren iniciar sesión?

WCAG aplica a cualquier contenido web, incluidas las páginas a las que se accede después de iniciar sesión. Que una ley obligue a un producto específico a cumplir WCAG depende de la jurisdicción y del cliente, pero los compradores que preguntan por la accesibilidad suelen referirse al producto completo.

¿Un overlay puede hacer accesible un producto SaaS?

No. Los overlays no cambian el código subyacente de los componentes personalizados, que es donde están las fallas de las aplicaciones. Nuestra guía sobre los overlays de accesibilidad explica la acción de la FTC contra uno de los principales proveedores de overlays.

¿Qué parte de WCAG pueden revisar las herramientas automatizadas?

Solo una parte. Las reglas automatizadas detectan de forma confiable nombres y etiquetas faltantes y fallas de contraste, pero muchos criterios, como un orden del foco con sentido, un texto alternativo útil o mensajes de error comprensibles, necesitan que una persona los evalúe.

¿A qué versión de WCAG deberíamos apuntar?

WCAG 2.2 nivel AA es la versión vigente. Muchas leyes y reglas de compras públicas todavía hacen referencia a WCAG 2.1 AA; cumplir 2.2 AA también implica cumplir 2.1 AA, salvo por el criterio Procesamiento, que se eliminó.

¿Necesitamos cumplir el nivel AAA?

El W3C no recomienda exigir AAA para productos completos, porque hay contenidos que no pueden cumplir todos los criterios AAA. El nivel AA es el objetivo habitual.