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

<https://www.fixreports.com/es/blog/wcag-2-2-checklist-saas-web-apps>

Actualizado el 2026-10-26

Un producto SaaS tiene dos superficies de accesibilidad: la web de marketing que lo vende y la aplicación que la gente usa a diario. La web de marketing falla de las mismas formas que cualquier otra web, con poco contraste, falta de texto alternativo y formularios sin etiquetas. La aplicación añade sus propios problemas: procesos de inicio de sesión que bloquean los gestores 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áficos sin texto, funciones de arrastrar y soltar sin alternativa y sesiones que caducan sin aviso. Esta lista de comprobació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 añadió nueve criterios de conformidad, seis de ellos de nivel A o AA ([W3C](https://www.w3.org/WAI/standards-guidelines/wcag/new-in-22/)).
- Autenticación accesible (3.3.8, AA) significa que un inicio de sesión no puede depender de recordar o transcribir una contraseña, salvo que se pueda pegar o usar un gestor de contraseñas ([W3C](https://www.w3.org/WAI/WCAG22/Understanding/accessible-authentication-minimum)).
- 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](https://www.w3.org/WAI/WCAG22/Understanding/target-size-minimum)).
- Mensajes como «Guardado» o «3 resultados» deben llegar a los lectores de pantalla sin mover el foco (4.1.3, AA) ([W3C](https://www.w3.org/WAI/WCAG22/Understanding/status-messages)).
- 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](https://www.itic.org/policy/accessibility/vpat)).

## ¿Por qué la accesibilidad importa más en un SaaS que en una web corporativa sencilla?

La gente usa un producto SaaS durante horas, a menudo porque lo eligió su empresa. 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 la web.

También importa porque las pruebas automatizadas solo detectan una parte del problema. Herramientas como axe-core encuentran fallos en el marcado, como etiquetas que faltan o poco contraste. No pueden saber si un cuadro de diálogo devuelve el foco al lugar correcto, si los datos de un gráfico están disponibles como texto o si un flujo de trabajo se puede completar con el teclado. Una aplicación necesita tanto comprobaciones 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 añadió el requisito nuevo más importante para los SaaS.

- **Permite pegar y usar gestores 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 gestores de contraseñas puedan rellenarlos.
- **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 comprobaciones que no requieren ninguna acción del usuario ([W3C](https://www.w3.org/TR/turingtest/)).
- **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, rellénalos o deja que la persona los seleccione en lugar de volver a escribirlos.
- **Mantén la ayuda en el mismo sitio (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 fallos?

Los formularios concentran la mayoría de los fallos 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](https://webaim.org/projects/million/)), y las aplicaciones tienen muchos más formularios que las páginas de inicio.

- Da 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 ver: 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 a 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 a menudo 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](https://www.w3.org/WAI/ARIA/apg/patterns/dialog-modal/)).

- **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 tras 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 puntero sin que desaparezcan y que permanezcan hasta que se cierren.
- **Atajos de una sola tecla (2.1.4, A)**: si pulsar 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 gestiona 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 puede que los lectores de pantalla no anuncien que ha pasado 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 educada (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 volver 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 los gráficos?

- **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 hacer bien.
- **Gráficos**: da a cada gráfico 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); añade etiquetas o tramas.
- **Contraste**: el texto necesita 4.5:1 (1.4.3, AA), y las líneas de los gráficos, los iconos y los bordes de los campos necesitan 3:1 frente a su fondo (1.4.11, AA). Comprueba el modo oscuro por separado. Nuestro [validador de contraste de color](/es/color-contrast-checker) prueba cualquier par de colores.
- **Mensajes de estado (4.1.3, AA)**: «Guardado», «Subida completada» y los recuentos de resultados deben usar `role="status"` o una región activa, para que los lectores de pantalla los oigan 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 coherente | 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 introducida en el mismo proceso se rellena automáticamente o se puede seleccionar |
| 3.3.8 Autenticación accesible (mínima) | AA | Inicio de sesión sin memorizar ni transcribir, salvo que se permita pegar, usar gestores 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](https://www.w3.org/WAI/standards-guidelines/wcag/new-in-22/)).

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

- **Caducidad de la sesión (2.2.1, A)**: avisa antes de que caduque una sesión y permite ampliarla con una acción sencilla, salvo que el límite de tiempo sea esencial o supere las 20 horas. Guardar el trabajo en curso evita el peor resultado.
- **Reajuste del contenido (1.4.10, AA)**: el contenido debe funcionar con un ancho de 320 píxeles CSS (el equivalente a ampliar 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, salvo 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](https://www.itic.org/policy/accessibility/vpat)).

Las agencias federales de Estados Unidos deben comprar tecnología accesible en virtud de la Sección 508 ([Section508.gov](https://www.section508.gov/)), y los organismos públicos de la UE se remiten a la EN 301 549, así que a los productos B2B que venden a esos clientes se les suele pedir un ACR durante la contratación. 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 rellenarlo.

Si vendes a consumidores de la UE, la Ley Europea de Accesibilidad también puede aplicarse a tu forma de vender online; nuestra [guía sobre la EAA](/es/blog/european-accessibility-act-online-stores) explica su alcance. Esto no es asesoramiento jurídico.

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

1. **Automatiza lo básico.** Ejecuta axe-core o un motor similar en tus pruebas de extremo a extremo y en la web de marketing, y haz que la compilación falle cuando aparezcan infracciones nuevas. Nuestro [validador de accesibilidad gratuito](/es/website-accessibility-checker) ejecuta el mismo motor en cualquier página pública.
2. **Prueba con el teclado.** Completa tus flujos principales, como darte de alta, crear un registro y cambiar la configuración, usando solo Tab, Mayús+Tab, Intro, la barra espaciadora, Escape y las teclas de flecha.
3. **Prueba con un lector de pantalla.** NVDA en Windows y VoiceOver en macOS e iOS son gratuitos. Comprueba que se anuncian los nombres, los roles, los estados y los mensajes.
4. **Amplía y cambia el tamaño.** Comprueba el texto ampliado al 200 % y una ventana de 320 píxeles de ancho.
5. **Corrige en el sistema de diseño.** La mayoría de los fallos proceden de componentes compartidos; corregir un botón o un cuadro de diálogo una vez lo corrige en todas partes.

## Preguntas frecuentes

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

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

### ¿Puede un overlay hacer accesible un producto SaaS?

No. Los overlays no cambian el código subyacente de los componentes personalizados, que es donde están los fallos de las aplicaciones. Nuestra guía sobre los [overlays de accesibilidad](/es/blog/accessibility-overlays-ftc-order) explica la actuación de la FTC contra uno de los principales proveedores de overlays.

### ¿Qué parte de WCAG pueden comprobar las herramientas automatizadas?

Solo una parte. Las reglas automatizadas detectan de forma fiable nombres y etiquetas que faltan y fallos de contraste, pero muchos criterios, como un orden del foco con sentido, un texto alternativo útil o unos mensajes de error comprensibles, necesitan que una persona los valore.

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

WCAG 2.2 nivel AA es la versión vigente. Muchas leyes y normas de contratación siguen remitiéndose a WCAG 2.1 AA; cumplir 2.2 AA también supone 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.

## Fuentes

- W3C: [What's new in WCAG 2.2](https://www.w3.org/WAI/standards-guidelines/wcag/new-in-22/)
- W3C: [Web Content Accessibility Guidelines (WCAG) 2.2](https://www.w3.org/TR/WCAG22/)
- W3C: [Understanding 3.3.8 Accessible Authentication (Minimum)](https://www.w3.org/WAI/WCAG22/Understanding/accessible-authentication-minimum)
- W3C: [Understanding 2.5.8 Target Size (Minimum)](https://www.w3.org/WAI/WCAG22/Understanding/target-size-minimum)
- W3C: [Understanding 4.1.3 Status Messages](https://www.w3.org/WAI/WCAG22/Understanding/status-messages)
- W3C: [ARIA Authoring Practices Guide: Dialog (modal) pattern](https://www.w3.org/WAI/ARIA/apg/patterns/dialog-modal/)
- W3C: [Inaccessibility of CAPTCHA](https://www.w3.org/TR/turingtest/)
- ITI: [Voluntary Product Accessibility Template (VPAT)](https://www.itic.org/policy/accessibility/vpat)
- GSA: [Section508.gov](https://www.section508.gov/)
- WebAIM: [The WebAIM Million (2026)](https://webaim.org/projects/million/)