Testing de accesibilidad: la habilidad QA que casi nadie tiene (y todos necesitan)
Uno de cada seis usuarios vive con alguna discapacidad — y la mayoría de los equipos publica software que no pueden usar. Para QA, la accesibilidad es doble oportunidad: bugs de alto impacto que nadie más busca, y una especialización que las ofertas laborales piden cada vez más (la regulación aprieta: European Accessibility Act vigente desde 2025, ADA en EE.UU., y la tendencia llega a LatAm).
WCAG en dos minutos
Las WCAG (Web Content Accessibility Guidelines) se organizan en 4 principios — perceptible, operable, comprensible, robusto — con niveles A, AA (el estándar de facto y el que exigen las leyes) y AAA. No necesitas memorizarlas: necesitas el pase práctico.
El pase manual de 15 minutos
Sin herramientas, sin instalar nada:
- Solo teclado (5 min): Tab por el flujo principal. ¿Llegas a todo? ¿Se ve siempre dónde está el foco? ¿Escape cierra los modales? ¿El foco vuelve a un lugar lógico al cerrarlos? El teclado es también el proxy de lectores de pantalla y switch devices.
- Zoom 200% (3 min): ¿el layout sobrevive? ¿aparece scroll horizontal (violación)? ¿se corta texto?
- Los ojos entrecerrados (2 min): mira la pantalla achinando los ojos. Lo que desaparece tiene problema de contraste.
- Formularios (5 min): clickea cada label — ¿enfoca su campo? Envía con errores — ¿el mensaje dice qué campo y cómo arreglarlo, o solo se pone rojo (color-only, violación)?
Automatiza el 40% que es automatizable
Los checkers automáticos (axe es el motor estándar) detectan contraste, alts faltantes, labels rotos, jerarquía de headings, ARIA mal usado:
- En el navegador: extensión axe DevTools o el audit de Lighthouse — cero setup.
- En la suite:
cypress-axeo@axe-core/playwright, tres líneas por página (el cómo exacto está en la lección de a11y del curso de Cypress). - El truco compuesto: los locators
getByRolede Playwright ya son un test de accesibilidad encubierto — si no encuentran tu botón, un lector de pantalla tampoco.
El 60% restante — sentido del orden de foco, calidad de los textos alternativos, experiencia real con lector de pantalla — sigue siendo pase humano. Por eso es habilidad y no plugin.
Cómo reportar bugs de a11y que se arreglen
El error clásico es reportar "no cumple WCAG" (nadie lo agenda). El reporte que funciona:
Título: [Reservas] El modal de confirmación atrapa el foco y no se
puede cerrar con teclado
Impacto: usuarios de teclado y lector de pantalla NO PUEDEN completar
la reserva (flujo de ingreso bloqueado)
WCAG: 2.1.2 No Keyboard Trap (nivel A)
Pasos: 1. Tab hasta "Confirmar" y Enter · 2. Intentar Escape o Tab
Esperado: Escape cierra; el foco queda en el botón que abrió el modal
Impacto en usuarios primero, criterio WCAG después. La severidad se argumenta sola: un flujo de dinero inoperable con teclado no es "cosmético".
La oportunidad de carrera
QA + a11y es una intersección con demanda real y oferta escasa: audita el producto de tu empresa con el pase de 15 minutos y presenta los hallazgos — es de las formas más rápidas de destacar en un equipo. Y en entrevistas, tener un ejemplo de bug a11y bien reportado te separa del montón.
Practica ya: corre el pase de 15 minutos en cualquier sitio chileno grande. Encontrarás violaciones — escríbeles el reporte con la estructura del curso de QA Manual y súmalo a tu portafolio.