Pruebas de Accesibilidad (WCAG)

Por Qué Importan las Pruebas de Accesibilidad #

Las pruebas de accesibilidad aseguran que personas con discapacidades puedan usar tu producto. Esto incluye usuarios ciegos o con baja visión, sordos o con dificultades auditivas, con discapacidades motoras, cognitivas o impedimentos temporales.

Aproximadamente el 15% de la población mundial — más de mil millones de personas — experimenta alguna forma de discapacidad. Más allá del imperativo ético, la accesibilidad es cada vez más un requisito legal. Leyes como ADA (EE.UU.), la Directiva Europea de Accesibilidad y similares en todo el mundo exigen productos digitales accesibles.

Como ingeniero QA, las pruebas de accesibilidad no son opcionales — es un atributo de calidad fundamental que debes verificar.

WCAG 2.1: El Estándar #

Las Directrices de Accesibilidad para el Contenido Web (WCAG) 2.1, publicadas por el W3C, son el estándar global para accesibilidad web. Se organizan en cuatro principios conocidos como POUR.

Principios POUR #

Perceivable (Perceptible) — La información y componentes de UI deben ser presentables de formas que los usuarios puedan percibir.

• Alternativas de texto para imágenes (alt text)
• Subtítulos para video
• Contraste de color suficiente
• Contenido adaptable a diferentes presentaciones

Operable — Los componentes de UI y la navegación deben ser operables.

• Accesible por teclado (toda funcionalidad via teclado)
• Tiempo suficiente para leer y usar contenido
• Sin contenido que cause convulsiones (parpadeo)
• Navegable (encabezados claros, orden de foco, enlaces de salto)

Understandable (Comprensible) — La información y operación de UI deben ser comprensibles.

• Texto legible (idioma especificado, escritura clara)
• Comportamiento predecible (navegación consistente)
• Asistencia de entrada (identificación de errores, etiquetas)

Robust (Robusto) — El contenido debe ser suficientemente robusto para ser interpretado por tecnologías de asistencia.

• HTML válido
• Uso correcto de atributos ARIA
• Compatible con agentes de usuario actuales y futuros

Niveles de Conformidad #

Problemas Comunes de Accesibilidad #

Visuales #

• Alt text faltante: Imágenes sin atributos alt descriptivos
• Contraste de color pobre: Contraste texto-fondo debajo de 4.5:1
• Información solo por color: Usar color solo para transmitir significado
• Indicadores de foco faltantes: Sin contorno visible al navegar con Tab
• Texto en imágenes: Texto crítico incrustado en imágenes en lugar de HTML

Navegación por Teclado #

• Trampas de teclado: El foco queda atrapado sin forma de salir con Tab
• Orden de Tab ilógico: El foco salta por la página inesperadamente
• Skip links faltantes: Sin forma de saltar la navegación repetitiva
• Controles no accesibles por teclado: Dropdowns o modals que solo funcionan con mouse

Lector de Pantalla #

• Etiquetas ARIA faltantes: Elementos interactivos sin nombres accesibles
• Jerarquía de encabezados incorrecta: Saltar de <h1> a <h4>
• Etiquetas de formulario faltantes: Campos sin elementos <label> asociados
• Contenido dinámico no anunciado: Actualizaciones AJAX no detectadas

Multimedia #

• Subtítulos faltantes: Videos sin subtítulos sincronizados
• Sin audiodescripción: Información visual en video no descrita auditivamente
• Media con auto-reproducción: Audio o video que inicia automáticamente

Herramientas de Testing Automatizado #

Las herramientas automatizadas detectan aproximadamente 30-40% de problemas de accesibilidad. El resto requiere testing manual.

Técnicas de Testing Manual #

Testing de Teclado #

La prueba manual más importante. Navega toda la página usando solo el teclado:

• Tab: Avanzar por elementos interactivos
• Shift+Tab: Retroceder
• Enter/Espacio: Activar botones y enlaces
• Flechas: Navegar dentro de componentes
• Escape: Cerrar modales y popups

Testing con Lector de Pantalla #

Prueba con al menos un lector de pantalla: NVDA (Windows), VoiceOver (macOS/iOS), JAWS (Windows), TalkBack (Android).

Testing de Zoom #

Zoom al 200% y verifica: ¿Todo el contenido es visible? ¿El layout se adapta sin scroll horizontal? ¿El texto es legible?

Ejercicio: Auditoría WCAG 2.1 AA #

Realiza una auditoría de accesibilidad de un sitio web público apuntando a conformidad WCAG 2.1 Nivel AA.

Tarea #

Audita el sitio usando herramientas automatizadas y técnicas manuales. Documenta al menos 10 problemas.

Pasos #

1. Ejecuta escaneo axe DevTools y documenta problemas Critical y Serious
2. Ejecuta auditoría Lighthouse y anota la puntuación
3. Realiza prueba de navegación por teclado en homepage y una página con formulario
4. Prueba con VoiceOver o NVDA en al menos 3 páginas
5. Verifica contraste de color en todos los textos
6. Verifica que todas las imágenes tengan alt text apropiado
7. Revisa jerarquía de encabezados (h1 > h2 > h3)
8. Prueba con zoom al 200%

Tips Profesionales #

• Las herramientas automatizadas detectan solo 30-40%: Nunca dependas solo de herramientas. El testing de teclado y lector de pantalla son esenciales.
• Integra axe-core en CI/CD: Agrega @axe-core/playwright a tu suite automatizada para detectar regresiones antes del deployment.
• Prueba con usuarios reales: Si es posible, incluye usuarios con discapacidades en tus pruebas de usabilidad.
• ARIA es último recurso: Los atributos ARIA deben complementar HTML semántico, no reemplazarlo. Un <button> siempre es mejor que <div role="button">.
• La accesibilidad no es una auditoría única: Integra verificaciones en tu ciclo regular de testing.