Accesibilidad AA Web: Comparativa de Herramientas 2026
Accesibilidad web AA se refiere al nivel de conformidad AA de las Pautas de Accesibilidad al Contenido Web (WCAG) 2.2, publicadas por el W3C, que requiere cumplir con los 30 criterios de Nivel A más 20 criterios de Nivel AA (50 en total). Para ello, los equipos combinan tres tipos de herramientas: auditores automatizados, asistentes de contraste y lectores de pantalla, además de una revisión manual.
Conclusiones clave
- El nivel AA de WCAG 2.2 agrupa 50 criterios de éxito (30 de nivel A + 20 de nivel AA); es el umbral de accesibilidad aa web que exigen la mayoría de legislaciones, incluida la europea EN 301 549.
- Ninguna herramienta detecta por sí sola todos los fallos: los auditores automatizados cubren en torno a un tercio de los criterios, así que la revisión manual y las pruebas con lectores de pantalla son obligatorias.
- La elección depende del flujo de trabajo: extensiones de navegador para desarrollo diario, suites con CI para equipos y auditorías externas para certificaciones formales.
- Los cuatro tipos de herramientas que necesitas son: auditores automatizados, verificadores de contraste, lectores de pantalla y validadores de estructura/HTML.
- Documentar cada decisión de accesibilidad (qué se probó, con qué versión y en qué navegador) es tan importante como corregir el fallo para demostrar conformidad.
Qué significa realmente “AA” en accesibilidad web
WCAG Nivel AA es el segundo de los tres niveles de conformidad (A, AA y AAA) definidos por el W3C. Cada nivel combina los criterios del nivel anterior: para declarar la conformidad AA, debe cumplir los 30 criterios del nivel A y los 20 criterios del nivel AA, lo que corresponde a 50 criterios de éxito. El nivel AAA suma 28 más y es raro que se exija al completo porque ciertos criterios son imposibles de cumplir en todos los contenidos.
La diferencia práctica entre A y AA es sustancial. El nivel A cubre lo esencial (texto alternativo, estructura semántica, navegación por teclado). El nivel AA añade requisitos que afectan al diseño y al color: contraste mínimo de 4.5:1 para texto normal y 3:1 para texto grande, redimensionado del texto hasta el 200 % sin pérdida de contenido, subtítulos en vídeo pregrabado, y encabezados y etiquetas que describen el propósito de cada campo.
Estos criterios son los que suelen romperse en sitios construidos con XHTML y CSS heredados, donde el color y el tamaño se fijaron en píxeles absolutos.
La referencia normativa que conviene citar es la especificación oficial de WCAG 2.2 del W3C, que incluye la lista completa de criterios y sus técnicas suficientes y de asesoramiento. En el contexto europeo, la norma EN 301 549 armoniza estos requisitos para la contratación pública y la Directiva de Accesibilidad Web, mientras que en Estados Unidos la referencia equivalente es la Sección 508 y el ADA. Conocer el marco legal de tu mercado es importante: en España y Latinoamérica, muchos clientes institucionales exigen conformidad AA explícita en los pliegos para asegurar la accesibilidad aa web.
Los cuatro tipos de herramientas que necesitas
Ninguna categoría de herramienta cubre todo el espectro de WCAG para la accesibilidad web. Un flujo de trabajo serio combina cuatro tipos, y cada uno responde a preguntas distintas.
Relacionado: — con plan gratuito para empezar hoy mismo.
Auditores automatizados. Escanean el DOM y el CSS en busca de patrones de fallo conocidos: imágenes sin alt, campos sin etiqueta, contraste insuficiente, encabezados saltados, atributos ARIA mal usados. Son rápidos y detectan errores repetitivos, pero su cobertura es parcial: los propios fabricantes reconocen que no pueden evaluar criterios que dependen del significado, como la calidad de un texto alternativo o la claridad de un mensaje de error.
Verificadores de contraste. Calculan la relación de contraste entre color de texto y fondo según la fórmula de luminancia relativa de WCAG. Son herramientas pequeñas pero críticas, porque el contraste es uno de los fallos más frecuentes y uno de los más fáciles de medir objetivamente.
Lectores de pantalla. NVDA (Windows, gratuito), JAWS (Windows, comercial) y VoiceOver (macOS/iOS, integrado) son la prueba de fuego. Un auditor puede decir que un formulario “pasa”, pero solo un lector de pantalla revela si el orden de tabulación tiene sentido o si un aria-label confunde más que ayuda.
Vale la pena echarle un vistazo: — Accesibilidad gestionada: automatización combinada con revisión humana.
Validadores de estructura y HTML. Aseguran que el marcado sea válido y semántico. En los sitios XHTML, un validador detecta anidamientos incorrectos, atributos obsoletos y problemas de codificación que luego afectan la interpretación del lector de pantalla.
Comparativa: qué herramienta elegir según tu caso
La siguiente tabla resume el criterio de decisión para asegurar la accesibilidad web AA. No es una lista de precios (que cambian con frecuencia y depende de la licencia), sino de encaje por escenario.
| Tipo de herramienta | Cuándo elegirla | Fortaleza principal | Limitación clave |
|---|---|---|---|
| Extensión de navegador (auditoría en vivo) | Desarrollo diario, revisión de una página concreta | Feedback inmediato sobre el DOM renderizado | Solo analiza lo que el navegador ha cargado; no cubre flujos completos |
| Suite con integración CI | Equipos con despliegue continuo | Detecta regresiones antes de publicar | Requiere configuración y mantenimiento de reglas |
| Verificador de contraste | Diseño y revisión de sistemas de color | Medición objetiva y exacta | No evalúa nada más allá del color |
| Lector de pantalla | Validación final y pruebas con usuarios | Reproduce la experiencia real | Curva de aprendizaje alta; lento de ejecutar |
| Auditoría externa | Certificación formal, pliegos públicos | Informe defendible ante terceros | Coste y dependencia de un proveedor |
La regla práctica: usa la extensión de navegador mientras desarrollas, la suite en CI para no romper lo que ya funcionaba, el verificador de contraste al definir la paleta, el lector de pantalla antes de cada entrega y la auditoría externa solo cuando necesites un documento formal.
Cómo evaluar una herramienta de accesibilidad antes de adoptarla
Elegir una herramienta en función de la popularidad es un error común. Estos criterios separan una herramienta útil de otra que genera ruido.
Cobertura de criterios y transparencia. Una buena herramienta indica qué criterio WCAG corresponde a cada alerta. Si solo muestra un “error de accesibilidad” sin asignarlo a un criterio de éxito, no puede documentar el cumplimiento ni priorizar.
Tasa de falsos positivos. Las alertas que no son fallos reales consumen tiempo y erosionan la confianza del equipo. Pruebe la herramienta en un sitio que ya sepa que cumple con los estándares web AA de accesibilidad y observe cuántas alertas genera.
Relacionado: — La que acredita tu experiencia en accesibilidad..
Compatibilidad con ARIA y componentes dinámicos. Los widgets modernos (menús desplegables, modales, pestañas, acordeones) dependen de los estados de ARIA. Una herramienta que no evalúa aria-expanded, aria-controls o la gestión de enfoque en modales deja pasar los errores más graves.
Integración con tu pila. Si estás trabajando con XHTML y CSS puro, verifica que la herramienta no asuma un marco concreto. Si está utilizando una canalización de compilación, verifique que exista integración de línea de comandos.
Accesibilidad de la herramienta en sí. Una ironía común: algunas herramientas de auditoría no son accesibles mediante el teclado. Si lo vas a utilizar a diario, asegúrate de que sea navegable sin ratón.
Actualización y mantenimiento. Las WCAG evolucionan (2.0, 2.1, 2.2) y los navegadores cambian. Una herramienta sin actualizaciones recientes puede aplicar reglas obsoletas.
Flujo de trabajo AA paso a paso para accesibilidad web
Un proceso repetible va más allá de cualquier herramienta simple. Este es el orden que funciona en proyectos reales.
Paso 1: Definir el alcance y el nivel. Decidir qué páginas y flujos se incluyen en la auditoría y confirme que el objetivo es AA (no A o AAA). Documentar la versión WCAG: 2.2 es la recomendación actual del W3C.
Paso 2: Auditoría automatizada inicial. Ejecutar las páginas clave a través de un auditor para obtener una línea de base. Tener en cuenta los fallos repetidos: normalmente se concentran en plantillas, no en páginas individuales.
Paso 3: Revisión manual de lo que la máquina no ve. Verifique el orden de las tabulaciones, la visibilidad del enfoque, la calidad de los textos alternativos, la claridad de los mensajes de error y la coherencia de los títulos. Aquí es donde se gana o se pierde el cumplimiento.
Paso 4: Prueba con un lector de pantalla. Realizar al menos un flujo completo (por ejemplo, un formulario de contacto o una compra) con NVDA o VoiceOver. Observar dónde te pierdes.
Paso 5: Pruebe con usuarios reales cuando sea posible. Las personas con discapacidad detectan barreras que ninguna herramienta o experto sin esa experiencia percibe. Éste es el criterio más valioso y el más difícil de sustituir.
Paso 6: Documentar y corregir. Registre cada hallazgo con su criterio WCAG, la técnica aplicada y la evidencia (captura de pantalla, versión del navegador, fecha). Este registro es lo que convierte “creemos que cumple” en “podemos demostrar que cumple”.
Errores frecuentes al perseguir el nivel AA de accesibilidad web
Confundir “cero errores del auditor” con cumplimiento. Un informe limpio de una herramienta automática no equivale a cumplimiento AA. Los auditores cubren sólo una fracción de los criterios; el resto requiere juicio humano.
Ignorar el contraste en estados interactivos. El contraste se suele revisar en el estado por defecto, pero los estados :hover, :focus y :disabled también deben cumplir. Un botón que pasa en reposo puede fallar al enfocarse.
Usar ARIA para arreglar HTML mal estructurado. La primera regla de ARIA no es usar ARIA si el HTML nativo ya resuelve el problema. Un <div> con role="button" nunca será tan robusto como un <button> real, que ya gestiona el foco y el teclado.
Olvidar el redimensionado del texto. El criterio 1.4.4 exige que el texto se pueda ampliar al 200 % sin pérdida de contenido ni funcionalidad. Los diseños con alturas fijas en píxeles suelen romperse aquí.
No probar en móvil. El reflujo (criterio 1.4.10) exige que el contenido funcione sin desplazamiento horizontal en pantallas estrechas. Muchos sitios de escritorio conformes fallan en este punto.
Preguntas frecuentes
¿Qué diferencia hay entre accesibilidad A, AA y AAA?
Los niveles de cumplimiento de las WCAG son acumulativos. El nivel A cubre 30 criterios básicos; AA suma 20 más (50 en total) y es el estándar requerido por la mayoría de leyes; AAA agrega 28 adicionales y no es obligatorio en forma general porque algunos criterios son inviables en todo el contenido. Para la mayoría de los proyectos web, AA es un objetivo realista y suficiente para la accesibilidad de una web.
¿Cuántos criterios de WCAG 2.2 hay que cumplir para el nivel AA?
WCAG 2.2 Nivel AA requiere cumplir 50 criterios de éxito: los 30 del Nivel A más los 20 del Nivel AA. La figura sigue siendo la misma que la WCAG 2.1, pero 2.2 también agregó nuevos criterios como tamaño objetivo (2.5.8) y ayuda consistente (3.2.6), algunos en el nivel A y otros en el nivel AA.
¿Basta con una herramienta automática para cumplir AA?
No. Las herramientas automatizadas detectan errores objetivos y repetitivos, pero no pueden evaluar criterios que dependen del significado o el contexto, como la calidad de un texto alternativo o la utilidad de un mensaje de error. El cumplimiento de AA requiere combinar auditoría automatizada, revisión manual y pruebas con lectores de pantalla y, cuando sea posible, con usuarios reales.
¿Qué lector de pantalla conviene usar para probar un sitio?
NVDA es gratuito y se usa ampliamente en Windows, lo que la convierte en la opción más accesible para comenzar. JAWS es comercial y común en entornos corporativos. VoiceOver viene integrado en macOS e iOS, por lo que es la ruta natural si trabajas en el ecosistema de Apple. Las pruebas con al menos dos combinaciones de navegador y lector de pantalla proporcionan una imagen más confiable.
¿La accesibilidad AA es obligatoria por ley?
Depende del país y del tipo de organización. En la Unión Europea, la Directiva de Accesibilidad Web y la norma EN 301 549 imponen requisitos al sector público y a muchos servicios privados. En Estados Unidos, la Sección 508 y la ADA generan obligaciones similares. En América Latina, varios países tienen sus propias regulaciones inspiradas en las WCAG. Es recomendable verificar la legislación aplicable a su mercado.
¿Cada cuánto hay que reauditar un sitio para mantener el nivel AA?
No existe un plazo universal, pero cualquier cambio en el diseño, plantilla o componente puede introducir regresiones. Un enfoque práctico es realizar auditorías automáticamente durante cada implementación a través de una integración continua y realizar una revisión manual completa al menos una vez al año o después de rediseños importantes. Documentar cada auditoría facilita demostrar el cumplimiento sostenido a lo largo del tiempo.
Conclusión
El cumplimiento del nivel AA de accesibilidad web no se compra ni se instala: se construye combinando herramientas y criterio. Los auditores automatizados aceleran el trabajo, los verificadores de contraste resuelven una falla objetiva, los lectores de pantalla revelan la experiencia real y la revisión manual cubre lo que ninguna máquina puede juzgar.
Elija sus herramientas según su flujo de trabajo, no según su popularidad, y documente cada decisión. Para profundizar en los criterios y técnicas, la referencia definitiva sigue siendo la documentación de WCAG del W3C y las pautas de la iniciativa WAI.
Fuentes y lecturas adicionales
- Pautas de accesibilidad al contenido web - Wikipedia: Las Pautas de accesibilidad al contenido web (WCAG) son parte de una serie publicada por la Iniciativa de Accesibilidad Web (WAI) del Consorcio World Wide Web (W3C),…
- Accesibilidad web — Wikipedia: La accesibilidad web, o eAccessibility, es la práctica inclusiva de garantizar que no existan barreras que impidan la interacción o el acceso a sitios web en el mundo…
¿Cumplir WCAG sin tocar el código?
Superposición de IA que promete cumplimiento WCAG en 48 horas