Accesibilidad web y la European Accessibility Act: qué debe probar tu equipo QA

Respuesta corta: la European Accessibility Act (EAA) se aplica desde el 28 de junio de 2025 y obliga a que muchos productos y servicios digitales dirigidos a consumidores en la Unión Europea sean accesibles. En la práctica, los equipos apuntan a WCAG 2.2 nivel AA. La automatización detecta solo una parte de los problemas, así que se necesita combinar pruebas automáticas con revisión manual.

Este artículo es una guía técnica de QA, no asesoría legal. Para saber si la norma te aplica y en qué medida, consulta con un especialista.

Qué es la EAA y a quién puede afectar

Es una directiva europea que exige accesibilidad en determinados productos y servicios, entre ellos comercio electrónico, servicios bancarios, transporte de pasajeros, telecomunicaciones y libros electrónicos. Incluye excepciones, por ejemplo para microempresas que prestan servicios. Puede alcanzar también a empresas fuera de la UE que venden a consumidores europeos, por lo que importa a muchos negocios latinoamericanos que exportan servicios digitales.

La referencia técnica son las normas europeas de accesibilidad (EN 301 549), basadas en las pautas WCAG. Hoy el criterio más seguro es apuntar a WCAG 2.2 AA.

Qué detecta la automatización (y qué no)

Las herramientas basadas en axe-core encuentran bien problemas objetivos: imágenes sin texto alternativo, contraste insuficiente, campos sin etiqueta, roles ARIA incorrectos. Pero hay muchas cosas que ninguna herramienta puede juzgar por sí sola, como si un texto alternativo es significativo, si el orden de foco tiene sentido o si un mensaje de error se entiende. Las estimaciones habituales indican que la automatización cubre solo una fracción de los problemas reales, por lo que no alcanza por sí sola.

Un test automatizado con Playwright y axe

import { test, expect } from "@playwright/test";
import AxeBuilder from "@axe-core/playwright";

test("la home no tiene violaciones WCAG detectables", async ({ page }) => {
  await page.goto("/");

  const results = await new AxeBuilder({ page })
    .withTags(["wcag2a", "wcag2aa", "wcag21aa", "wcag22aa"])
    .analyze();

  expect(results.violations).toEqual([]);
});

Este tipo de prueba, ejecutada en CI sobre las páginas y flujos principales, evita que se cuelen regresiones evidentes.

Lista de pruebas manuales que no se pueden omitir

1. Navegación solo con teclado: ¿se llega a todo con Tab? ¿el foco es visible y sigue un orden lógico? ¿no hay "trampas de teclado"?
2. Lector de pantalla: recorre un flujo clave (registro, compra) con NVDA, VoiceOver o TalkBack y confirma que se entiende lo que se anuncia.
3. Zoom y reflow: al ampliar al 200 % o en pantallas pequeñas, ¿el contenido sigue usable sin scroll horizontal?
4. Formularios y errores: etiquetas claras, mensajes de error específicos y asociados al campo.
5. Contenido no textual: textos alternativos significativos, subtítulos en videos y alternativas a contenido solo visual o sonoro.
6. Objetivos táctiles y movimiento: tamaños mínimos de los controles y alternativas a gestos complejos.

Cómo organizarlo en un equipo

• Integra axe en CI para los flujos críticos y bloquea los Pull Requests con violaciones nuevas.
• Incluye accesibilidad en la definición de "listo" de cada historia de usuario.
• Programa una auditoría manual antes de lanzamientos grandes y cada cierto tiempo.
• Documenta lo que sabes y lo que corriges: la trazabilidad ayuda ante cualquier requerimiento.

La accesibilidad bien hecha no solo reduce riesgo normativo: también mejora la experiencia para todos los usuarios y suele tener impacto positivo en SEO.

Si quieres integrar estas pruebas a tu suite, mira qué automatizar primero y cómo evitar tests inestables.

¿Tu producto se vende en Europa y quieres saber qué tan lejos estás? Conversemos y armamos un diagnóstico de accesibilidad.