Accesibilidad AA Web: Comparativa de Herramientas 2026

W3C, which requires meeting the 30 Level A criteria plus 20 Level AA criteria (50 in total). For this, teams combine three types of tools: automated auditors, contrast assistants and screen readers, in addition to a manual review.

Key Takeaways

• 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 Level AA is the second of three conformance levels (A, AA and AAA) defined by the W3C. Each level combines the criteria of the previous level: to declare AA conformity, you must satisfy the 30 level A criteria and the 20 level AA criteria, which corresponds to 50 success criteria. The AAA level adds 28 more and it is rare that it is demanded in full because certain criteria are impossible to fulfill in all contents.

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 describan 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 Section 508 y el ADA. Conocer el marco legal de tu mercado importa: 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 aa web. Un flujo de trabajo serio combina cuatro tipos, y cada uno responde a preguntas distintas.

Related: UserWay — Widget de accesibilidad 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.

Worth a look: AudioEye — Accesibilidad gestionada: automatización combinada con revisión humana.

Structure and HTML validators. Ensure markup is valid and semantic. On XHTML sites, a validator detects incorrect nesting, obsolete attributes and coding issues which then affect the screen reader’s interpretation.

Comparativa: qué herramienta elegir según tu caso

La siguiente tabla resume el criterio de decisión para asegurar la accesibilidad AA web. No es una lista de precios (que cambian con frecuencia y dependen 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

Choosing a tool based on popularity is a common mistake. These criteria separate a useful tool from one that generates noise.

Coverage of criteria and transparency. A good tool indicates which WCAG criterion corresponds to each alert. If it only shows an “accessibility error” without mapping it to a success criterion, you cannot document compliance or prioritize.

False positive rate. Alerts that are not real failures consume time and erode the team’s trust. Test the tool on a site that you already know meets accessibility AA web standards and observe how many alerts it generates.

Related: IAAP CPACC / WAS Certification — La certificación profesional que acredita tu experiencia en accesibilidad.

ARIA support and dynamic components. Modern widgets (drop-down menus, modals, tabs, accordions) depend on ARIA states. A tool that does not evaluate aria-expanded, aria-controls, or focus management in modals lets the most serious errors pass through.

Integration with your stack. If you are working with pure XHTML and CSS, check that the tool does not assume a concrete framework. If you are using a build pipeline, verify that there is command line integration.

Accessibility of the tool itself. A common irony: some auditing tools are not themselves accessible by keyboard. If you are going to use it daily, ensure it is navigable without a mouse.

If you are shopping: accessiBe — Superposición de IA que promete cumplimiento WCAG en 48 horas.

Update and maintenance. WCAG evolves (2.0, 2.1, 2.2) and browsers change. A tool without recent updates may apply obsolete rules.

Step-by-step AA workflow for web accessibility

A repeatable process goes further than any simple tool. This is the order that works in real projects.

Step 1 — Define the scope and level. Decide which pages and flows are included in the audit and confirm that the goal is AA (not A or AAA). Document the WCAG version: 2.2 is the current W3C recommendation.

Step 2 — Initial automated audit. Run the key pages through an auditor to obtain a baseline. Note the repeated failures: they are usually concentrated in templates, not in individual pages.

Step 3 — Manual review of what the machine does not see. Check the tab order, focus visibility, the quality of alternative texts, the clarity of error messages, and the consistency of headings. This is where compliance is won or lost.

Step 4 — Test with a screen reader. Go through at least one complete flow (for example, a contact form or a purchase) with NVDA or VoiceOver. Note where you get lost.

Step 5 — Try with real users when possible. People with disabilities detect barriers that no tool or expert without that experience perceives. This is the most valuable criterion and the most difficult to replace.

Step 6 — Document and correct. Record each finding with its WCAG criterion, the applied technique, and the evidence (screenshot, browser version, date). This record is what turns “we believe it complies” into “we can prove it complies”.

Errores frecuentes al perseguir el nivel AA de accesibilidad web

Confusing “zero auditor errors” with compliance. A clean report from an automatic tool does not equate to AA compliance. Auditors cover only a fraction of the criteria; the rest requires human judgment.

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 es no 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?

WCAG compliance levels are cumulative. Level A covers 30 basic criteria; AA adds 20 more (50 total) and is the standard required by the majority of laws; AAA adds an additional 28 and is not required in a general form because some criteria are inviable across all content. For most web projects, AA is a realistic and sufficient goal for accesibilidad aa web.

¿Cuántos criterios de WCAG 2.2 hay que cumplir para el nivel AA?

WCAG 2.2 Level AA requires meeting 50 success criteria: the 30 from Level A plus the 20 from Level AA. The figure remains the same as WCAG 2.1, but 2.2 also added new criteria like target size (2.5.8) and consistent help (3.2.6), some at level A and some at level AA.

¿Basta con una herramienta automática para cumplir AA?

No. Automated tools detect objective and repetitive errors, but they cannot evaluate criteria that depend on meaning or context, such as the quality of alternative text or the usefulness of an error message. AA compliance requires combining automated auditing, manual review, and testing with screen readers and, when possible, with real users.

¿Qué lector de pantalla conviene usar para probar un sitio?

NVDA is free and widely used on Windows, making it the most accessible option to start. JAWS is commercial and common in corporate environments. VoiceOver comes integrated into macOS and iOS, so it is the natural route if you work in the Apple ecosystem. Testing with at least two combinations of browser and screen reader provides a more reliable image.

¿La accesibilidad AA es obligatoria por ley?

It depends on the country and the type of organization. In the European Union, the Web Accessibility Directive and the EN 301 549 standard impose requirements on the public sector and many private services. In the United States, Section 508 and the ADA generate similar obligations. In Latin America, several countries have their own regulations inspired by WCAG. It is advisable to verify the legislation applicable to your market.

¿Cada cuánto hay que reauditar un sitio para mantener el nivel AA?

There is no universal timeframe, but any change in design, template, or component can introduce regressions. A practical approach is to audit automatically during each deployment via continuous integration and perform a full manual review at least once a year or after significant redesigns. Documenting each audit makes it easier to demonstrate sustained compliance over time.

Conclusión

Web accessibility AA compliance is not bought or installed: it is built by combining tools and judgment. Automated auditors speed up the work, contrast checkers solve an objective failure, screen readers reveal the real experience, and manual review covers what no machine can judge.

Choose your tools according to your workflow, not according to their popularity, and document every decision. To delve deeper into the criteria and techniques, the definitive reference remains the documentación de WCAG del W3C and the pautas de la iniciativa WAI.

Sources & Further Reading

• Web Content Accessibility Guidelines — Wikipedia: The Web Content Accessibility Guidelines (WCAG) are part of a series published by the Web Accessibility Initiative (WAI) of the World Wide Web Consortium (W3C),…
• Web accessibility — Wikipedia: Web accessibility, or eAccessibility, is the inclusive practice of ensuring there are no barriers that prevent interaction with, or access to, websites on the World…

P.S. A few readers have asked which superposición de accesibilidad (overlay) we actually reach for — it's accessiBe; take a look here if you want the current details.