Guía práctica de pruebas de accesibilidad: desde comprobaciones automatizadas y revisiones manuales hasta pruebas con tecnologías de asistencia, integración en CI y criterios de aceptación

Resumen ejecutivo (puntos clave primero)

• La accesibilidad se protege menos con “conocimiento” y más con el hábito de verificar. El camino más corto es ejecutar comprobaciones automatizadas + comprobaciones manuales + pruebas con tecnologías de asistencia en ciclos pequeños y continuos.
• Las herramientas automatizadas son útiles, pero no pueden detectar cosas como el significado transmitido solo por color, el texto alternativo adecuado al contexto o la claridad y amabilidad de los mensajes de error.
• Empieza con una prueba de humo de 5 minutos para evitar fallos críticos, luego pasa a puntos de enfoque previos al lanzamiento, y por último crece hacia un CI resistente a regresiones, paso a paso.
• Los criterios de aceptación son más sólidos cuando se definen no solo con “números de WCAG”, sino también con resultados de interacción concretos (p. ej., “se puede completar con Tab”, “se puede saltar al resumen de errores”).
• Este artículo está compilado como un “libro de texto práctico” hands-on e incluye checklists, ejemplos de casos de prueba y plantillas de reporte que pueden usarse de inmediato en proyectos reales.

Público objetivo (específico): QA/Testers, Ingenieros Frontend, Diseñadores UI/UX, PMs/Directores, Responsables de Accesibilidad, Operadores de CMS, Revisores de Producción/Agencia
Nivel de accesibilidad: orientado a cumplimiento WCAG 2.1 AA (con un enfoque por fases recomendado de A → AA → AAA según el proyecto)

1. Introducción: la accesibilidad es una calidad protegida por las pruebas

La accesibilidad puede romperse fácilmente, incluso tras una implementación inicial cuidadosa, debido a actualizaciones o nuevas funciones. Esto es especialmente cierto en navegación, formularios, modales, tablas y vídeos—áreas donde los cambios de UI son frecuentes y los bugs de regresión son comunes.
Por eso, lo que de verdad importa no es solo el conocimiento de diseño, sino un sistema de verificación capaz de reproducir el mismo nivel de calidad en cualquier momento.
En esta guía explicamos cuidadosamente cómo introducir de forma incremental lo siguiente en flujos de trabajo reales, tanto si trabajas solo como en equipo:

• Comprobaciones automatizadas (Lighthouse, axe, etc.)
• Comprobaciones manuales (teclado, contraste, copy)
• Pruebas con tecnologías de asistencia (lectores de pantalla, etc.)
• Integración en CI (prevención de regresiones)

2. El panorama general de las pruebas: piensa en tres capas

2.1 Capa 1: comprobaciones automatizadas (lo que las máquinas pueden encontrar)

• Falta de atributos alt
• Falta de etiquetas (labels)
• Contraste insuficiente (dentro de ciertos límites)
• Mal uso de ARIA
• Algunos problemas de jerarquía de encabezados
• Comprobaciones básicas de elementos enfocables
  UUU es una herramienta conveniente para comprobaciones automatizadas

Fortalezas: rápidas, escalables a muchas páginas
Limitaciones: no pueden juzgar contexto, tono o adecuación semántica

2.2 Capa 2: comprobaciones manuales (lo que los humanos deben verificar)

• ¿Se pueden completar las tareas clave usando solo el teclado?
• Visibilidad del foco y orden lógico
• ¿Los mensajes de error explican “dónde”, “por qué” y “cómo arreglarlo”?
• ¿El significado se transmite solo por color?
• ¿El texto alternativo es adecuado al contexto?
• ¿El reflow responsive evita romper diseños?

2.3 Capa 3: pruebas con tecnologías de asistencia (validación final de la experiencia)

• Lectores de pantalla (NVDA / VoiceOver)
• Aumento de pantalla (lupa del SO)
• Entrada por voz (cuando sea posible)
• Acceso por switch (cuando sea posible)

El objetivo aquí no es la perfección, sino reproducir experiencias representativas de usuarios para prevenir fallos críticos.

3. Empieza aquí: la prueba de humo de 5 minutos (cada vez)

Propósito: eliminar fallos críticos (UI inoperable, contenido ilegible, usuario perdido) lo más rápido posible.

1. Los flujos principales se pueden completar usando solo Tab
   • Navegación → Lista → Detalle → Volver
   • Búsqueda → Resultados → Filtros
   • Formulario → Enviar → Corregir errores → Completar
2. Foco visible en modo claro y oscuro
3. Posibilidad de saltar al contenido principal mediante enlace “saltar” (skip link)
4. Los modales soportan Abrir → Operar → Esc → Devolver foco
5. Imágenes con significado tienen alt; imágenes decorativas usan alt=""
6. Tablas usan <th> y scope (al menos en tablas básicas)
7. Vídeos tienen subtítulos y controles operables con teclado
8. No hay scroll horizontal al 200% de zoom (excepto tablas/código)

Aprobar solo estos ocho puntos evita la mayoría de desastres de accesibilidad.

4. Pruebas automatizadas: elección de herramientas y cómo usarlas

4.1 Qué atacar con comprobaciones automatizadas

• ARIA rota (atributos inválidos)
• Falta de labels (detección temprana de problemas de formularios)
• Contraste insuficiente (comprobación básica)
• Encabezados omitidos (parcial)

4.2 Por qué CI hace que esto sea potente

• Ejecuta comprobaciones en cada Pull Request
• En lugar de “fallar por cualquier issue”, un enfoque por fases (warnings → failures) es más amigable para el equipo

4.3 Conocer los límites de la automatización

• Un alt="image" técnicamente existe, así que pasa
• El significado solo por color suele ser indetectable
• Claridad del texto y lenguaje llano no son medibles

Por eso, un checklist manual es esencial.

5. Pruebas manuales: checklist por perspectiva (uso práctico)

5.1 Interacción por teclado

• Todas las acciones posibles con Tab / Enter / Space
• Orden lógico del foco (orden del DOM)
• Desplegables, tabs, menús operables con flechas cuando haga falta
• Cerrar con Esc y devolver foco al disparador (trigger)

5.2 Visibilidad del foco

• :focus-visible suficientemente grueso
• Contraste adecuado (3:1 para elementos no textuales)
• Visible incluso sobre imágenes de fondo

5.3 Texto y contraste

• 4,5:1 (texto normal) / 3:1 (texto grande)
• Enlaces no distinguibles solo por color (subrayado, etc.)
• Errores y advertencias no transmitidos solo por color

5.4 Formularios

• Labels visibles con <label for>
• Campos obligatorios indicados claramente en texto
• Resumen de errores + errores inline con guía
• Atributos autocomplete apropiados

5.5 Imágenes, gráficos y vídeo

• Imágenes: alt contextual; decorativas con alt vacío
• Gráficos: puntos clave explicados en texto; tablas si hace falta
• Vídeo: subtítulos, subtítulos, operabilidad con teclado

5.6 Tablas

• Celdas de encabezado (th) y scope
• Tablas complejas usan headers/id o se simplifican
• Sin pérdida de información en layouts responsive

6. Pruebas con tecnologías de asistencia: mínimo conjunto para máximo impacto

6.1 Lectores de pantalla (mínimo)

• Windows: NVDA
• macOS / iOS: VoiceOver

Patrón rápido de prueba

1. La estructura de la página se entiende con la lista de encabezados
2. Navegación por landmarks (nav / main / footer)
3. Formularios leen labels, estado de obligatorio y errores
4. Botones y enlaces tienen nombres significativos (no solo “Haz clic aquí”)
5. Los modales atrapan el foco y lo restauran al cerrar

6.2 Aumento de pantalla (experiencia representativa)

• Sin pérdida de información crítica a 200%–400% de zoom
• Interlineado y tamaño de fuente legibles
• Targets de clic no demasiado pequeños

6.3 Funciones asistivas móviles (si es posible)

• VoiceOver en iOS: verificar formularios y navegación
• Guía de tamaño de target (~44px)

7. Ejemplos de casos de prueba: criterios de aceptación por tipo de pantalla

7.1 Navegación

• Orden lógico de Tab: navegación global → main → footer
• Página actual indicada con aria-current="page" y de forma visual
• Mega menús se abren con botones y se cierran con Esc

7.2 Búsqueda y filtrado

• Recuento de resultados mostrado en texto
• El foco se mueve a resultados tras filtrar (o anuncio de estado)
• Guía alternativa incluso cuando resultados = 0

7.3 Formularios

• Enviar con campos vacíos mueve el foco al resumen de errores
• Errores inline enlazados con aria-describedby
• Mensajes de error incluyen sugerencias de corrección

7.4 Modales

• El foco se mueve al primer elemento interactivo al abrir
• Tab cicla dentro del modal
• Esc cierra y devuelve el foco al disparador

8. Cómo redactar reportes que lleven a correcciones

Los problemas de accesibilidad no se arreglan con “Esto viola tal norma”.
Necesitas pasos para reproducir, resultado esperado, resultado real, impacto y una propuesta.

Plantilla de reporte de ejemplo

• Pantalla: formulario de registro
• Pasos: enviar con campos obligatorios vacíos
• Esperado: el foco va al resumen de errores; links saltan a errores
• Real: el foco queda arriba; la ubicación del error no es clara
• Impacto: usuarios de teclado y lector de pantalla no pueden corregir errores
• Propuesta: resumen de errores con role="alert" + foco via tabindex="-1", links ancla a campos

9. Integración CI/CD: construir sistemas que previenen regresiones

9.1 Un enfoque por fases es amigable para el equipo

• Fase 1: solo medir (sin fallos)
• Fase 2: fallar en violaciones críticas
• Fase 3: bloquear releases según criterios definidos

9.2 Decide qué páginas proteger

Intentar testearlo todo a la perfección fracasa.
Empieza protegiendo rutas críticas representativas:

• Home
• List
• Detail
• Formularios (registro / compra / contacto)
• My Page / Cuenta

9.3 Combínalo con un sistema de diseño

El testing a nivel de componente reduce drásticamente regresiones.
(p. ej., botones, campos de formulario, modales, tabs, tablas, alerts)

10. Errores comunes y cómo evitarlos

11. Valor para cada audiencia

• QA/Testers: perspectivas claras para detectar fallos críticos rápido
• Ingenieros: criterios de aceptación concretos reducen incertidumbre de implementación
• Diseñadores: correcciones tempranas de foco, labels y dependencia de color
• PMs/Directores: quality gates claros y responsabilidad
• Usuarios: menos roturas tras actualizaciones; usabilidad sostenida

12. Evaluación del nivel de accesibilidad (lo que cubre esta guía)

• Cubre los principales criterios WCAG 2.1 AA, incluyendo:
  • 1.1.1 Contenido no textual
  • 1.3.1 / 1.3.2 / 1.3.5 Estructura y propósito de entrada
  • 1.4.1 / 1.4.3 / 1.4.10 / 1.4.11 Color, contraste, reflow
  • 2.1.1 / 2.1.2 Teclado
  • 2.4.1 / 2.4.3 / 2.4.6 / 2.4.7 Navegación y foco
  • 3.3.1 / 3.3.3 / 3.3.4 Manejo de errores
  • 4.1.2 Nombre, rol, valor
• Permite cumplimiento AA sostenible mediante operación basada en pruebas

13. Conclusión: la accesibilidad crece a través de una cultura de testing

1. Empieza con la prueba de humo de 5 minutos para prevenir fallos críticos.
2. Automatización = alerta temprana, pruebas manuales = control de calidad, tecnología asistiva = garantía de experiencia.
3. Define criterios de aceptación no solo por números de WCAG, sino por resultados de usuario descritos.
4. Introduce CI por etapas y céntrate en páginas y componentes representativos.
5. Redacta hallazgos con pasos de reproducción y propuestas para que lleven a correcciones.

La accesibilidad no puede protegerla una sola persona.
Acumulando pequeños hábitos de prueba, preservamos la “amabilidad” con cada actualización.
Espero que tu equipo pueda hacer crecer la calidad de accesibilidad de forma sostenible—y estaré encantado de apoyarte en cada paso del camino.