Por Qué Importa el Testing de Accesibilidad
La accesibilidad web (frecuentemente abreviada como a11y) asegura que personas con discapacidades puedan percibir, entender, navegar e interactuar con sitios web. Esto incluye personas ciegas o con baja visión, sordas o con dificultades auditivas, con discapacidades motoras, cognitivas o impedimentos temporales.
La accesibilidad no es opcional para QA:
- Requisito legal — Leyes como ADA (EE.UU.), EAA (UE) y AODA (Canadá) exigen accesibilidad web
- Impacto de negocio — 15-20% de la población global tiene alguna forma de discapacidad
- Beneficio SEO — Muchas prácticas de accesibilidad mejoran la optimización para motores de búsqueda
- Indicador de calidad — Los sitios accesibles tienden a estar mejor estructurados
Resumen de WCAG 2.2
WCAG se organiza en cuatro principios (POUR):
Perceptible
El contenido debe ser presentable de formas que los usuarios puedan percibir: alternativas de texto para imágenes, subtítulos para video/audio, contenido adaptable, contraste de color suficiente.
Operable
La interfaz debe ser navegable y operable: toda la funcionalidad disponible por teclado, tiempo suficiente para leer e interactuar, sin contenido que cause convulsiones, navegación clara.
Comprensible
El contenido e interfaz deben ser comprensibles: texto legible, comportamiento predecible, asistencia de entrada (identificación de errores, labels).
Robusto
El contenido debe funcionar con tecnologías actuales y futuras: HTML válido, uso correcto de ARIA, compatibilidad con tecnologías asistivas.
Niveles de Conformidad
| Nivel | Descripción | Requisito Típico |
|---|---|---|
| A | Accesibilidad mínima | Raramente suficiente |
| AA | Cumplimiento estándar | Mayoría de requisitos legales |
| AAA | Accesibilidad mejorada | Solo contextos específicos |
La mayoría de organizaciones apuntan a WCAG 2.2 Nivel AA.
Técnicas de Testing Manual
Testing de Navegación por Teclado
La prueba manual más impactante que puedes realizar:
- Deja el mouse a un lado. Navega toda la página usando solo el teclado.
- Tabula por todos los elementos interactivos. ¿Puedes llegar a cada link, botón, campo de formulario y menú?
- Verifica visibilidad del focus. ¿Hay un indicador de focus visible en el elemento actualmente enfocado?
- Prueba trampas de teclado. ¿Puedes entrar y salir con Tab de modales, dropdowns y contenido embebido?
- Verifica orden lógico de tabulación. ¿El focus se mueve en orden lógico de lectura?
| Tecla | Acción Esperada |
|---|---|
| Tab | Mover al siguiente elemento interactivo |
| Shift+Tab | Mover al elemento interactivo anterior |
| Enter | Activar links y botones |
| Espacio | Alternar checkboxes, activar botones |
| Flechas | Navegar dentro de menús, radio groups, tabs |
| Escape | Cerrar modales, dropdowns, popups |
Testing con Screen Reader
Prueba con al menos un screen reader:
| Plataforma | Screen Reader | Navegador |
|---|---|---|
| Windows | NVDA (gratuito) | Firefox |
| macOS | VoiceOver (integrado) | Safari |
| iOS | VoiceOver (integrado) | Safari |
| Android | TalkBack (integrado) | Chrome |
Testing Visual y de Color
- Prueba la página en escala de grises — ¿se transmite información solo por color?
- Verifica ratios de contraste con extensiones del navegador (WAVE, axe DevTools)
- Haz zoom al 200% — ¿el layout sigue funcionando? ¿El contenido es legible?
- Prueba con modo de alto contraste en Windows
Herramientas de Testing Automatizado
axe-core
El motor de testing de accesibilidad más utilizado:
const { test, expect } = require('@playwright/test');
const AxeBuilder = require('@axe-core/playwright').default;
test('la página no tiene violaciones de accesibilidad', async ({ page }) => {
await page.goto('/');
const results = await new AxeBuilder({ page }).analyze();
expect(results.violations).toEqual([]);
});
WAVE Browser Extension
Extensión gratuita del navegador que proporciona una superposición visual de problemas de accesibilidad directamente en la página.
Ejercicio: Auditoría de Accesibilidad de una Página Web
Realiza una auditoría integral de accesibilidad combinando testing automatizado y manual.
Parte 1: Escaneo Automatizado
Ejecuta un escaneo axe-core en una página de tu elección:
- Instala la extensión axe DevTools del navegador
- Abre la página y ejecuta un escaneo completo
- Documenta todos los hallazgos:
| Problema | Impacto | Elemento | Criterio WCAG |
|---|---|---|---|
| Crítico/Serio/Moderado/Menor |
Parte 2: Auditoría de Teclado
Navega la misma página usando solo el teclado:
| Verificación | Pasa/Falla | Notas |
|---|---|---|
| Todos los elementos interactivos alcanzables con Tab | ||
| Indicador de focus visible en cada elemento | ||
| Orden de tabulación lógico | ||
| Se puede entrar y salir de modales con teclado | ||
| Menús dropdown operables con flechas | ||
| Link de saltar navegación presente | ||
| Sin trampas de teclado |
Parte 3: Verificación con Screen Reader
Habilita VoiceOver (Mac) o NVDA (Windows) y navega la página:
| Verificación | Pasa/Falla | Notas |
|---|---|---|
| Todas las imágenes tienen alt text significativo | ||
| Los encabezados forman una jerarquía lógica | ||
| Los campos de formulario tienen labels asociados | ||
| Los links tienen texto descriptivo | ||
| Los cambios de contenido dinámico se anuncian | ||
| El idioma de la página está declarado |
Parte 4: Verificaciones Visuales
| Verificación | Pasa/Falla | Notas |
|---|---|---|
| Todo el texto cumple contraste 4.5:1 (normal) | ||
| Todo el texto cumple contraste 3:1 (grande) | ||
| La página funciona al 200% de zoom | ||
| La información no se transmite solo por color |
Solución: Reporte de Auditoría de Accesibilidad de Ejemplo
Página auditada: example-shop.com/products
Automatizado (axe-core) — 8 problemas encontrados:
| Problema | Impacto | Cantidad | Corrección |
|---|---|---|---|
| Imágenes sin alt text | Crítico | 4 | Agregar atributos alt descriptivos |
| Inputs de formulario sin labels | Crítico | 2 | Asociar <label> con cada input |
| Contraste de color insuficiente | Serio | 3 | Aumentar contraste a mínimo 4.5:1 |
| Idioma de página faltante | Serio | 1 | Agregar lang="en" al <html> |
Teclado — 3 problemas encontrados:
- Dropdown de filtro de productos no operable con flechas — FALLA
- Modal no tiene trampa de focus — Tab se mueve detrás del modal — FALLA
- Sin link de saltar navegación — usuario debe tabular por 15 items de nav — FALLA
Screen Reader — 2 problemas encontrados:
- Precios de productos se leen como números sin moneda — confuso
- Confirmación de “Agregar al carrito” no se anuncia a usuarios de screen reader
Correcciones prioritarias:
- Agregar alt text a imágenes de productos (Crítico, corrección fácil)
- Agregar labels de formulario (Crítico, corrección fácil)
- Corregir contraste de color (Serio, cambios CSS)
- Agregar trampa de focus al modal (Serio, corrección JavaScript)
- Agregar atributo
lang(Serio, corrección de una línea) - Anunciar confirmación del carrito usando región aria-live
Integrando A11y en Tu Flujo de Trabajo
Enfoque Shift-Left
- Fase de diseño: Revisar mockups para contraste, estados de focus, jerarquía de encabezados
- Desarrollo: Usar linter axe-core en IDE para detectar problemas antes del commit
- Code review: Verificar alt text, atributos ARIA, HTML semántico
- Testing: Escaneos axe automatizados + testing manual con teclado/screen reader
- CI/CD: Fallar builds en violaciones críticas de accesibilidad
Puntos Clave
- El testing de accesibilidad requiere tanto herramientas automatizadas como testing manual — ninguno solo es suficiente
- El testing de teclado es la prueba manual más impactante para accesibilidad
- Apunta a cumplimiento WCAG 2.2 Nivel AA como estándar mínimo
- Usa axe-core en tu automatización de tests y pipeline de CI/CD
- Prueba con al menos un screen reader para detectar problemas que las herramientas automatizadas no encuentran
- Los bugs de accesibilidad suelen ser los más fáciles de corregir pero los más impactantes para los usuarios