El plazo de la Ley Europea de Accesibilidad venció en junio de 2025, convirtiendo el cumplimiento de WCAG 2.1 AA en un requisito legal para empresas del sector privado que venden en la UE. La mayoría de los bugs de accesibilidad son invisibles durante el desarrollo normal: aparecen cuando un usuario de teclado no puede llegar a un modal, un lector de pantalla anuncia un botón de icono simplemente como "botón", o un campo de formulario no da ningún contexto sobre qué ingresar. Detectarlos requiere combinar testing de teclado y uso básico de lectores de pantalla con escaneos automatizados de axe-core en Playwright CI.
Por qué importa el testing de accesibilidad en 2026
Aproximadamente el 15% de la población mundial vive con algún tipo de discapacidad. No es un caso extremo de poca importancia; es un segmento de usuarios más grande que el mayor grupo demográfico de la mayoría de las empresas. Pero hasta hace poco, la accesibilidad se trataba como un detalle de diseño o una casilla legal reservada para sitios web gubernamentales. Eso está cambiando rápido.
El plazo de la Ley Europea de Accesibilidad (EAA, por sus siglas en inglés) venció en junio de 2025. Las empresas del sector privado que venden productos o servicios en la UE deben cumplir los requisitos de accesibilidad o enfrentar acciones regulatorias y multas. El Reino Unido, Canadá y Australia tienen sus propios marcos superpuestos. En Estados Unidos, la ADA se ha aplicado a productos digitales a través de litigios durante años. WCAG 2.1 AA es el estándar internacional al que hace referencia la mayoría de estos marcos.
El riesgo legal es real, pero no es el único motivo para preocuparse. Las aplicaciones inaccesibles tienen tasas de abandono más altas, generan más solicitudes de soporte y exponen a las empresas a daños reputacionales. Un flujo de checkout que no se puede completar con teclado deja fuera a los usuarios que no pueden usar un mouse. Un formulario con campos sin etiquetar es inútil para un usuario de lector de pantalla. No son escenarios hipotéticos. Son patrones que aparecen en aplicaciones en producción todos los días, a veces durante años antes de que alguien lo note.
Los ingenieros QA que pueden detectar estos problemas antes de que lleguen a producción son genuinamente valiosos. Las herramientas existen. Las técnicas se pueden aprender. Lo que falta es conciencia.
WCAG 2.1 para testers: qué significa POUR en la práctica
WCAG 2.1 (Pautas de Accesibilidad para el Contenido Web) se organiza en torno a cuatro principios, abreviados como POUR: Perceptible, Operable, Comprensible y Robusto.
Perceptible significa que los usuarios pueden percibir todo el contenido a través de al menos un sentido. Las imágenes necesitan alternativas de texto. Los videos necesitan subtítulos. El contenido no puede depender únicamente del color para transmitir significado ("los campos obligatorios se muestran en rojo" es un fallo si el rojo es el único indicador). Operable significa que toda la funcionalidad está disponible sin mouse. La navegación por teclado debe alcanzar cada elemento interactivo. Los usuarios deben tener tiempo suficiente para completar las tareas (sin sesiones que expiran automáticamente sin advertencia). Nada parpadea más de tres veces por segundo (riesgo de convulsiones). Comprensible significa que la interfaz se comporta de forma predecible y los mensajes de error explican qué salió mal. Un formulario que dice "Entrada inválida" es un fallo. "El email debe incluir el símbolo @" no lo es. Robusto significa que el contenido puede ser interpretado por una amplia variedad de tecnologías de asistencia, incluyendo agentes de usuario actuales y futuros. Aquí es donde importa el HTML semántico: un con estilos para parecer un botón generalmente no lo es.
La conformidad AA, el estándar requerido por la EAA y la mayoría de los marcos legales, significa que se cumplen todos los criterios de éxito de Nivel A y Nivel AA. A y AA juntos cubren cosas como: las imágenes tienen texto alternativo (A), el color no es el único indicador visual (A), la relación de contraste es de al menos 4.5:1 para texto normal (AA), toda la funcionalidad es accesible por teclado (A), los indicadores de foco son visibles (AA), y los campos de formulario tienen etiquetas asociadas programáticamente (A).
Como tester, no necesitas memorizar toda la especificación. Necesitas saber qué criterios se violan con más frecuencia y cómo probarlos.
Testing de a11y manual: navegación por teclado y lectores de pantalla
Ninguna herramienta automatizada detectará todos los fallos de accesibilidad. El testing manual, especialmente con teclado y lector de pantalla, es irreemplazable.
La navegación por teclado es lo primero que hay que probar. Desconecta el mouse (o desactiva los eventos de puntero en DevTools) y navega tu aplicación usando solo Tab, Shift+Tab, Enter, Espacio y las teclas de flecha. Cada elemento interactivo (enlaces, botones, campos de formulario, desplegables, modales, selectores de fecha) debe ser alcanzable y operable. El orden de tabulación debe seguir una secuencia de lectura lógica, generalmente de izquierda a derecha y de arriba a abajo. El foco nunca debe quedar atrapado (presionas Tab y nada se mueve), excepto intencionalmente dentro de un modal, donde el foco debe estar limitado hasta que se cierre.
El patrón de fallo por teclado más común: un desarrollador construye un diálogo modal, pero al presionar Tab dentro de él, el foco escapa a la página de fondo. El modal está visualmente presente, pero el usuario de teclado ahora interactúa con el contenido detrás sin saberlo.
Los indicadores de foco son parte de este test. Cada elemento enfocado debe tener un indicador visible: el contorno predeterminado del navegador, un estilo personalizado, lo que sea. Los diseños que eliminan los estilos :focus con outline: none en CSS crean un foco invisible, lo que hace que la navegación por teclado sea completamente inútil. Busca esto en cada revisión de sprint.
El testing con lector de pantalla es más difícil y requiere práctica, pero incluso una familiaridad básica es enormemente valiosa. Los dos lectores de pantalla gratuitos más comunes son NVDA (Windows, gratuito) y VoiceOver (macOS e iOS, incluido en el sistema). JAWS es común en entornos empresariales, pero tiene costo.
Instala NVDA y abre tu aplicación. Apaga el monitor si quieres la experiencia completa. Navega con Tab para llegar a los elementos interactivos, y usa el modo de exploración de NVDA (teclas de flecha) para leer el contenido estático. Escucha lo que anuncia el lector de pantalla. Un botón que dice "Haz clic aquí" no le dice nada al usuario. Uno que dice "Enviar pago" le dice exactamente qué va a pasar. Un botón de icono sin aria-label anuncia su rol como "botón" pero nada sobre su función. Un campo de formulario sin etiqueta se anuncia como "editar" sin contexto sobre qué ingresar.
No necesitas convertirte en un usuario avanzado de lector de pantalla para encontrar bugs significativos. Dedica 30 minutos a navegar tus flujos principales con NVDA. Los problemas que hacen la experiencia rota o confusa van a aparecer rápido.
La combinación de testing de teclado y uso básico de lector de pantalla detectará la mayoría de los bugs graves de a11y que existen en una aplicación web típica.
Testing automatizado de a11y con axe-core y Playwright
Las herramientas automatizadas no pueden reemplazar el testing manual, pero detectan un subconjunto confiable de problemas (alt text faltante, contraste de color insuficiente, etiquetas de formulario faltantes, uso incorrecto de ARIA) de forma consistente y a escala. Ejecutarlas en CI significa que detectas las regresiones antes de que lleguen a los testers.
El motor más usado es axe-core, mantenido por Deque Systems. Impulsa extensiones de navegador (axe DevTools), Lighthouse y una serie de integraciones de frameworks. Para equipos que ya usan Playwright, el paquete @axe-core/playwright agrega escaneos de a11y con configuración mínima.
Este es un test básico de Playwright que escanea una página en busca de violaciones de accesibilidad:
import { test, expect } from '@playwright/test';
import AxeBuilder from '@axe-core/playwright';
test('la página de inicio no tiene violaciones de accesibilidad detectables automáticamente', async ({ page }) => {
await page.goto('/');
const accessibilityScanResults = await new AxeBuilder({ page }).analyze();
expect(accessibilityScanResults.violations).toEqual([]);
});
Esto hace fallar el test si axe encuentra alguna violación. En la práctica, especialmente en un codebase existente, querrás empezar registrando en lugar de bloqueando: registra las violaciones, corrígelas de forma incremental y agrega aserciones a medida que se va limpiando el backlog.
Para escaneos más específicos, puedes escanear componentes concretos y filtrar a un nivel de WCAG particular:
test('el formulario de checkout cumple con WCAG 2.1 AA', async ({ page }) => {
await page.goto('/checkout');
const results = await new AxeBuilder({ page })
.include('#checkout-form')
.withTags(['wcag2a', 'wcag2aa', 'wcag21aa'])
.analyze();
if (results.violations.length > 0) {
const violationDetails = results.violations.map(v => ({
id: v.id,
impact: v.impact,
description: v.description,
nodes: v.nodes.map(n => n.html),
}));
console.log('Violaciones:', JSON.stringify(violationDetails, null, 2));
}
expect(results.violations).toEqual([]);
});
El filtro .withTags() limita el escaneo a criterios WCAG específicos. wcag2a, wcag2aa y wcag21aa juntos cubren el nivel de conformidad AA. Agrega estos tests a tu pipeline de CI junto a tus tests funcionales existentes.
axe-core detecta aproximadamente el 30-40% de los problemas de WCAG automáticamente. No es razón para omitirlo; detectar un tercio de los problemas automáticamente y a escala es genuinamente valioso. Pero significa que un escaneo axe en verde no es una certificación de accesibilidad. Es un punto de partida, no un punto de llegada.
Lo que las herramientas automatizadas no pueden detectar
Aquí es donde viven los problemas de a11y más críticos, y por eso el testing manual no es negociable.
El texto alternativo significativo es el ejemplo más claro. Una herramienta automatizada puede detectar que un elemento ![]()
alt. Eso es una verificación de pasa/falla. No puede determinar si el texto alternativo es preciso o significativo. Una imagen de un gráfico de líneas que muestra ingresos en caída descrita como alt="gráfico" pasa la verificación automatizada. Un usuario de lector de pantalla escucha "gráfico" y no tiene información. El fallo es semántico, no estructural.
El orden de lectura lógico es otro caso. El orden del DOM determina cómo los lectores de pantalla recorren la página. Los estilos visuales pueden hacer que los elementos aparezcan en un orden completamente diferente al que existen en el DOM. Un usuario con visión lee el botón "Agregar al carrito" después de la descripción del producto porque está posicionado debajo. Si el orden del DOM pone el botón antes del título del producto, el usuario de lector de pantalla escucha el botón antes de entender con qué producto está interactuando. Las herramientas automatizadas pueden marcar algunos reordenamientos, pero los layouts complejos requieren que una persona evalúe la experiencia de escucha real.
El contraste de color en contexto es parcialmente automatizable pero puede producir falsos resultados. axe escanea los estilos computados, pero los elementos superpuestos, las imágenes de fondo y los fondos con degradados pueden engañar al escáner. Verifica el contraste manualmente con el verificador de contraste del navegador o herramientas como WebAIM Contrast Checker cuando veas diseños visuales complejos.
Los nombres accesibles para botones de icono son un fallo recurrente que las herramientas detectan parcialmente. Un Bugs de a11y comunes que encuentran los ingenieros QA
Estos patrones aparecen repetidamente en productos de todo tipo y escala. Conocerlos significa que los vas a reconocer de inmediato.
Las etiquetas de formulario faltantes son el más común. Un placeholder visible en un campo no es una etiqueta accesible. Cuando el usuario empieza a escribir, el placeholder desaparece, y un usuario de lector de pantalla que vuelve al campo escucha solo "editar" sin contexto. La solución es un elemento for/id, o un atributo aria-label o aria-labelledby. Búscalos tabulando a cada campo de formulario y escuchando en NVDA.
Los elementos interactivos no semánticos aparecen cuando un desarrollador construye un o role, tabindex y manejadores de eventos de teclado explícitos para ser accesible. Estas son correcciones costosas; encontrarlas temprano ahorra una refactorización significativa.
El manejo deficiente del foco en modales y paneles aparece en casi todos los componentes de diálogo construidos a medida. El modal se abre, pero el foco se queda en el botón que lo activó (ahora detrás del overlay). El orden de tabulación se filtra a la página de fondo. Cuando el modal se cierra, el foco cae al inicio del documento en lugar de volver al elemento activador. Prueba cada modal abriéndolo con Tab+Enter y navegando completamente por teclado.
Las actualizaciones de contenido dinámico sin anuncio afectan mucho a las apps de página única. Un usuario envía un formulario, la página muestra un mensaje de éxito, pero el mensaje aparece en una parte diferente del DOM sin cambio de foco y sin región live. El usuario de lector de pantalla no tiene idea de que el envío funcionó. Las regiones ARIA live (role="status" o aria-live="polite") resuelven esto, pero solo si alguien pensó en agregarlas.
Las trampas de teclado en widgets personalizados, en particular desplegables, selectores de fecha y editores de texto enriquecido, frecuentemente atrapan el foco del teclado o no implementan las interacciones de teclado estándar (teclas de flecha para navegación en desplegables, Escape para cerrar). Prueba cada componente interactivo personalizado solo con teclado.
Cómo escribir reportes de bugs de a11y
Los reportes de bugs de accesibilidad necesitan más contexto que los bugs de UI estándar porque el impacto depende de qué tecnología de asistencia se ve afectada y qué criterio de éxito de WCAG se viola. Un reporte vago ("el lector de pantalla no funciona aquí") no le da nada accionable al desarrollador.
Un buen reporte de bug de a11y incluye:
El criterio WCAG violado
Cada fallo se mapea a un criterio. Una etiqueta faltante viola WCAG 1.3.1 (Información y relaciones) y 4.1.2 (Nombre, función, valor). Un indicador de foco faltante viola WCAG 2.4.7 (Foco visible). Incluye el ID del criterio y el nombre. Esto le dice al desarrollador exactamente cuál es el requisito, y documenta la brecha de cumplimiento para cualquier auditoría.
La tecnología de asistencia y el navegador usados
"NVDA 2024.1 + Chrome 124 en Windows 11" es accionable. "Lector de pantalla" no lo es. Las distintas combinaciones de AT/navegador se comportan de forma diferente, y los desarrolladores necesitan el stack específico para reproducir el problema.
El anuncio esperado vs. el real
Para bugs de lector de pantalla, escribe lo que anunció el AT y lo que debería haber anunciado. "Anunció: 'botón'. Esperado: 'Enviar pago, botón'." Esta es la descripción real del fallo.
Pasos para reproducir que usan AT, no el mouse
"Tabular al campo de email, escuchar el anuncio de NVDA", no "hacer clic en el campo de email." Los pasos deben ser reproducibles usando solo el método de interacción afectado.
Calificación de impacto
Usa los niveles de impacto de WCAG: crítico (bloqueador para usuarios de AT), serio (dificultad mayor), moderado (alguna dificultad), menor. Una etiqueta de modal faltante es crítica. Una estructura de encabezados subóptima es menor a moderada. El impacto guía la prioridad de la corrección.
No marques los bugs de a11y como "nice to have" a menos que sean genuinamente menores. Un formulario que no se puede enviar por teclado es un bloqueador para los usuarios que solo usan teclado. Tiene la misma severidad que un botón de checkout que no funciona para los usuarios con mouse. Aplica los mismos estándares de severidad que aplicarías a cualquier fallo funcional.
Cómo aplicar esto el lunes a la mañana
No necesitas auditar todo tu producto en un sprint. Empieza pequeño y construye el hábito.
Esta semana
Instala NVDA (gratuito, Windows) o activa VoiceOver (macOS: Cmd+F5). Abre una página de tu aplicación, idealmente un formulario o un flujo con modal. Tabula por ella. Escucha lo que NVDA anuncia para cada elemento. Reporta todo lo que sea confuso o silencioso.
Este sprint
Agrega el paquete @axe-core/playwright a tu proyecto. Escribe un test que escanee tu página más crítica: login, checkout o incorporación. Ejecútalo en CI. No bloquees el build todavía; empieza registrando las violaciones para que el equipo vea la línea de base.
En el próximo mes
Agrega verificaciones de navegación por teclado a tu definición de hecho para las nuevas funcionalidades. Incluye "probado solo con teclado" en tu checklist de PR. Para cada funcionalidad con formularios o modales, dedica diez minutos a probar el orden de tabulación y el manejo del foco.
Para tus reportes de bugs de a11y
Crea una plantilla en tu rastreador de bugs con campos para el criterio WCAG, la AT afectada y el anuncio esperado. Usar la plantilla toma treinta segundos. Tener esa información en el reporte ahorra una hora de ida y vuelta con el desarrollador.
El plazo de la EAA ya pasó. Las empresas que no han abordado la accesibilidad operan ahora con exposición legal. Los ingenieros QA que pueden identificar, documentar y rastrear los fallos de accesibilidad están reduciendo directamente ese riesgo. Y las correcciones que detectas antes de producción llegan a los usuarios que las necesitan. Un usuario de lector de pantalla completando un checkout sin asistencia, un usuario de teclado navegando un formulario sin quedar atrapado: ese es el resultado. Las herramientas son el medio.
Empieza con un test de teclado. Construye desde ahí.
→ See also: Testing de Accesibilidad con Playwright: Verificaciones a11y Automatizadas | Eventos de Teclado y Ratón en Playwright | Fundamentos de Pruebas de Usabilidad: Lo que los Ingenieros QA Necesitan Saber
