Informe de Pruebas de Accesibilidad: Guía Completa para Cumplimiento WCAG

TL;DR

• Las herramientas automatizadas detectan 30-40% de problemas de accesibilidad—necesitas tanto pruebas automatizadas como manuales con tecnologías asistivas
• Estructura tus informes según los principios POUR de WCAG (Perceptible, Operable, Comprensible, Robusto) con niveles de severidad claros
• Incluye pasos de reproducción, grupos de usuarios afectados y código de remediación para cada problema para permitir correcciones rápidas

Mejor para: Equipos de QA realizando auditorías de accesibilidad, oficiales de cumplimiento documentando conformidad WCAG Omitir si: Solo necesitas un escaneo automatizado rápido—usa axe DevTools directamente en lugar de construir informes completos Tiempo de lectura: 15 minutos

Las pruebas de accesibilidad aseguran que los productos digitales sean usables por todos, incluyendo personas con discapacidades. Con más de 1 mil millones de personas en el mundo viviendo con alguna forma de discapacidad, la accesibilidad no es solo un requisito legal sino un imperativo moral y oportunidad de negocio.

Esta guía proporciona marcos completos para documentar resultados de pruebas de accesibilidad, asegurar cumplimiento con WCAG 2.2 y crear experiencias digitales inclusivas.

Cuándo Crear Informes Completos de Accesibilidad

Crear un informe completo cuando:

• Preparándose para auditorías de cumplimiento WCAG/ADA
• Lanzando o actualizando significativamente una aplicación de cara al público
• Respondiendo a quejas de accesibilidad o preocupaciones legales
• Estableciendo métricas base de accesibilidad para seguimiento de mejoras
• Trabajando con equipos externos de remediación que necesitan guía detallada

Usar documentación más ligera cuando:

• Ejecutando verificaciones automatizadas en CI/CD (registrar violaciones, fallar builds)
• Haciendo verificaciones manuales rápidas durante el desarrollo
• Ya tienes un proceso establecido de pruebas de accesibilidad

Niveles de Cumplimiento WCAG 2.2

Comprensión de Niveles de Conformidad

Adiciones de WCAG 2.2 (lanzado octubre 2023): Apariencia de enfoque, movimientos de arrastre, tamaño de objetivo, ayuda consistente, entrada redundante y criterios de éxito de autenticación accesible.

Principios WCAG (POUR)

Perceptible: La información debe ser presentable de formas que los usuarios puedan percibir

• Alternativas de texto para contenido no textual
• Subtítulos y transcripciones para multimedia
• Estructura de contenido adaptable
• Contenido visual y auditivo distinguible

Operable: La interfaz de usuario debe ser operable

• Accesibilidad por teclado
• Tiempo suficiente para leer y usar contenido
• Sin contenido que cause convulsiones
• Contenido navegable y localizable

Comprensible: La interfaz debe ser comprensible

• Contenido de texto legible
• Funcionalidad predecible
• Asistencia de entrada y prevención de errores

Robusto: El contenido debe funcionar con tecnologías asistivas actuales y futuras

• HTML válido y semántico
• Uso apropiado de ARIA
• Compatible con lectores de pantalla y otras herramientas

Plantilla de Informe de Pruebas de Accesibilidad

Sección de Resumen Ejecutivo

# INFORME DE PRUEBAS DE ACCESIBILIDAD

## Resumen Ejecutivo

**Aplicación**: Plataforma Web E-Commerce v3.2
**Fecha de Prueba**: 12 de Enero, 2026
**Tester**: Alex Rodriguez (IAAP WAS Certificado)
**Cumplimiento Objetivo**: WCAG 2.2 Nivel AA
**Resultado General**: 78% Conforme (Necesita Mejora)

### Resumen de Hallazgos Clave
| Severidad | Cantidad | Usuarios Bloqueados |
|-----------|----------|---------------------|
| Crítico | 12 | ~20% de usuarios discapacitados bloqueados |
| Alto | 23 | Fricción significativa |
| Medio | 45 | Experiencia degradada |
| Bajo | 18 | Problemas menores |

### Cumplimiento por Principio POUR
| Principio | Nivel A | Nivel AA | Nivel AAA |
|-----------|---------|----------|-----------|
| Perceptible | 85% | 72% | 45% |
| Operable | 90% | 78% | 52% |
| Comprensible | 88% | 81% | 60% |
| Robusto | 82% | 75% | N/A |

### Acciones Inmediatas Requeridas
1. Agregar texto alt a todas las imágenes de productos (12 páginas afectadas)
2. Corregir trampas de teclado en diálogos modales (bloquea 15% de usuarios con discapacidad motora)
3. Actualizar ratios de contraste de color (falla mínimo de 4.5:1)

### Recomendación de Plazos
- P0 Crítico: Corregir dentro de 7 días
- P1 Alto: Corregir dentro de 30 días
- P2/P3: Incluir en siguiente ciclo de sprint

Sección de Alcance de Pruebas

## Alcance de Pruebas

### Páginas Probadas
1. Página de Inicio (/)
2. Listado de Productos (/products)
3. Detalle de Producto (/products/[id])
4. Carrito de Compras (/cart)
5. Checkout (/checkout)
6. Cuenta de Usuario (/account)
7. Resultados de Búsqueda (/search)
8. Centro de Ayuda (/help)

### Herramientas de Prueba Usadas
**Automatizadas:**
- axe DevTools 4.8
- WAVE (WebAIM)
- Lighthouse (Chrome DevTools)
- IBM Equal Access Checker

**Manuales:**
- NVDA 2025.1 (Windows)
- JAWS 2025 (Windows)
- VoiceOver (macOS Sonoma, iOS 18)
- TalkBack (Android 15)
- Dragon NaturallySpeaking 16

### Matriz de Cobertura de Pruebas
| Área | Automatizado | NVDA | VoiceOver | Teclado | Cognitivo |
|------|--------------|------|-----------|---------|-----------|
| Inicio | ✓ | ✓ | ✓ | ✓ | ✓ |
| Productos | ✓ | ✓ | ✓ | ✓ | ✓ |
| Checkout | ✓ | ✓ | ✓ | ✓ | ✓ |
| Cuenta | ✓ | ✓ | Parcial | ✓ | - |

Documentación Detallada de Problemas

Plantilla de Problema Crítico

### Problema #1: Falta Texto Alt para Imágenes de Productos

**Criterio WCAG**: 1.1.1 Contenido No Textual (Nivel A)
**Severidad**: Crítico
**Usuarios Afectados**: Usuarios de lector de pantalla, usuarios con imágenes deshabilitadas
**Impacto de Negocio**: No pueden completar flujo de compra principal

**Ubicación**: Página `/products`, todas las tarjetas de producto

**Estado Actual (No conforme)**:
```html
<img src="/images/product-123.jpg" />

Estado Esperado (Conforme):

<img src="/images/product-123.jpg"
     alt="Camiseta de algodón azul con cuello redondo, talla mediana, $29.99" />

Pasos de Reproducción:

1. Navegar a /products usando NVDA + Firefox
2. Presionar B para navegar por imágenes
3. NVDA anuncia: “gráfico” (sin descripción)

Impacto en Usuario:

• Usuarios de lector de pantalla: No pueden identificar productos
• Usuarios con imágenes deshabilitadas: Sin información de producto
• Impacto SEO: Reducida visibilidad en búsqueda

Guía de Remediación:

1. Agregar texto alt descriptivo incluyendo: nombre de producto, características visuales clave, precio
2. Para imágenes decorativas, usar alt=""
3. Para imágenes complejas, usar aria-describedby para descripciones extendidas

Prueba de Verificación:

// Verificación de regla axe-core
const results = await axe.run(document, {
  rules: ['image-alt']
});
expect(results.violations).toHaveLength(0);

Prioridad: P0 - Crítico Esfuerzo Estimado: 2-3 días (300+ imágenes) Asignado A: Equipo Frontend

### Plantilla de Problema de Alta Prioridad

```markdown
### Problema #2: Trampa de Teclado en Diálogos Modales

**Criterio WCAG**: 2.1.2 Sin Trampa de Teclado (Nivel A)
**Severidad**: Crítico
**Usuarios Afectados**: Usuarios solo de teclado, discapacidades motoras (~15% de usuarios discapacitados)

**Ubicación**: Modal Agregar al Carrito, Popup de Login

**Descripción**:
El enfoque queda atrapado dentro de los diálogos modales. Presionar Escape o Tab no cierra el modal ni permite navegación fuera.

**Evidencia en Video**: [Enlace a grabación de pantalla mostrando trampa de teclado]

**Pasos de Reproducción**:
1. Navegar a página de producto usando tecla Tab
2. Presionar Enter en botón "Agregar al Carrito"
3. Modal se abre, enfoque se mueve dentro
4. Presionar tecla Escape → FALLA (modal permanece abierto)
5. Presionar Tab repetidamente → FALLA (enfoque cicla dentro del modal)

**Análisis de Causa Raíz**:
Componente modal sin:
- Manejador de tecla Escape
- Trampa de enfoque con mecanismo de escape
- Retorno de enfoque al elemento disparador al cerrar

**Código de Remediación**:
```javascript
class ModalAccesible {
  constructor(modalElement, triggerElement) {
    this.modal = modalElement;
    this.trigger = triggerElement;
    this.focusableElements = this.getFocusableElements();
    this.firstFocusable = this.focusableElements[0];
    this.lastFocusable = this.focusableElements[this.focusableElements.length - 1];
  }

  open() {
    this.modal.setAttribute('aria-hidden', 'false');
    this.modal.style.display = 'block';
    this.firstFocusable.focus();
    this.addEventListeners();
  }

  close() {
    this.modal.setAttribute('aria-hidden', 'true');
    this.modal.style.display = 'none';
    this.trigger.focus(); // Retornar enfoque
    this.removeEventListeners();
  }

  handleKeydown = (e) => {
    if (e.key === 'Escape') {
      this.close();
      return;
    }

    if (e.key === 'Tab') {
      if (e.shiftKey && document.activeElement === this.firstFocusable) {
        e.preventDefault();
        this.lastFocusable.focus();
      } else if (!e.shiftKey && document.activeElement === this.lastFocusable) {
        e.preventDefault();
        this.firstFocusable.focus();
      }
    }
  }
}

Prioridad: P0 - Crítico Esfuerzo Estimado: 1 día

### Plantilla de Problema de Contraste de Color

```markdown
### Problema #3: Contraste de Color Insuficiente

**Criterio WCAG**: 1.4.3 Contraste (Mínimo) (Nivel AA)
**Severidad**: Alto
**Usuarios Afectados**: Baja visión, daltonismo, usuarios mayores, usuarios móviles al aire libre

**Elementos que Fallan**:
| Elemento | Primer plano | Fondo | Actual | Requerido | Diferencia |
|---------|-------------|-------|--------|-----------|------------|
| Botón secundario | #999999 | #FFFFFF | 2.8:1 | 4.5:1 | -1.7 |
| Etiqueta formulario | #AAAAAA | #FFFFFF | 2.3:1 | 4.5:1 | -2.2 |
| Enlace pie página | #888888 | #F5F5F5 | 3.2:1 | 4.5:1 | -1.3 |
| Texto placeholder | #CCCCCC | #FFFFFF | 1.6:1 | 4.5:1 | -2.9 |

**Remediación - Paleta de Colores Actualizada**:
```css
:root {
  /* Antiguo → Nuevo (con ratio de contraste) */
  --text-secondary: #595959;  /* Era #999999 → 7.0:1 ✓ */
  --text-label: #4A4A4A;      /* Era #AAAAAA → 9.7:1 ✓ */
  --text-footer: #545454;     /* Era #888888 → 7.5:1 ✓ */
  --text-placeholder: #767676; /* Era #CCCCCC → 4.5:1 ✓ */
}

Herramienta de Prueba: Usar WebAIM Contrast Checker o DevTools del navegador Prioridad: P1 - Alto Esfuerzo Estimado: 3 días (revisión de diseño + implementación + QA)

## Metodología de Pruebas

### Integración de Pruebas Automatizadas

```javascript
// accessibility-tests.js - integración CI/CD
const { AxePuppeteer } = require('@axe-core/puppeteer');
const puppeteer = require('puppeteer');

const WCAG_TAGS = ['wcag2a', 'wcag2aa', 'wcag21a', 'wcag21aa', 'wcag22aa'];

async function runAccessibilityAudit(urls) {
  const browser = await puppeteer.launch();
  const results = [];

  for (const url of urls) {
    const page = await browser.newPage();
    await page.goto(url, { waitUntil: 'networkidle0' });

    const axeResults = await new AxePuppeteer(page)
      .withTags(WCAG_TAGS)
      .analyze();

    results.push({
      url,
      violations: axeResults.violations,
      passes: axeResults.passes.length,
      timestamp: new Date().toISOString()
    });

    // Fallar CI si se encuentran violaciones críticas
    const critical = axeResults.violations.filter(v => v.impact === 'critical');
    if (critical.length > 0) {
      console.error(`CRÍTICO: ${url} tiene ${critical.length} violaciones críticas`);
      process.exitCode = 1;
    }
  }

  await browser.close();
  return results;
}

// Integración con GitHub Actions
// .github/workflows/accessibility.yml

Lista de Verificación de Pruebas Manuales

## Lista de Verificación de Pruebas de Accesibilidad Manual

### Navegación por Teclado
- [ ] Todos los elementos interactivos accesibles vía tecla Tab
- [ ] Orden de tabulación lógico sigue diseño visual
- [ ] Indicadores de enfoque visibles (contraste mínimo 3:1)
- [ ] Sin trampas de teclado
- [ ] Enlaces de omisión presentes y funcionales
- [ ] Diálogos modales atrapan y retornan enfoque correctamente

### Pruebas con Lector de Pantalla
- [ ] Todas las imágenes tienen texto alt apropiado
- [ ] Etiquetas de formulario apropiadamente asociadas (`for`/`id` o envolviendo)
- [ ] Mensajes de error anunciados con `role="alert"`
- [ ] Contenido dinámico anunciado con regiones ARIA live
- [ ] ARIA landmarks presentes (banner, main, navigation, contentinfo)
- [ ] Encabezados crean esquema lógico de documento

### Pruebas Visuales
- [ ] Contraste de color cumple 4.5:1 para texto normal, 3:1 para texto grande
- [ ] Texto permanece legible al 200% de zoom
- [ ] Sin información transmitida solo por color
- [ ] Contenido refluye a 320px de ancho sin scroll horizontal
- [ ] Enfoque visible en todos los elementos interactivos

### Formularios
- [ ] Todos los campos tienen etiquetas visibles asociadas
- [ ] Campos requeridos marcados (no solo con color de asterisco)
- [ ] Mensajes de error específicos y útiles
- [ ] Atributos autocomplete presentes donde aplique

### Multimedia
- [ ] Videos tienen subtítulos precisos
- [ ] Contenido de audio tiene transcripciones
- [ ] Auto-play puede pausarse dentro de 3 segundos
- [ ] Sin contenido parpadeando >3 veces por segundo

Midiendo el Éxito

Señales de advertencia de que no está funcionando:

• Escaneo automatizado muestra 0 problemas pero quejas de usuarios continúan (faltan pruebas manuales)
• Porcentaje de cumplimiento estancado (equipo no prioriza correcciones de accesibilidad)
• Nuevas características introducen consistentemente violaciones (falta accesibilidad en proceso de diseño/desarrollo)

Enfoques Asistidos por IA

Las herramientas de IA han transformado las pruebas de accesibilidad, pero con limitaciones claras. Tasas actuales de detección por IA por tipo de problema:

• Alt text faltante: 95%+
• Contraste de color: 90%+
• Etiquetas de formulario faltantes: 90%+
• Jerarquía de encabezados: 85%+
• Accesibilidad de teclado: 70%+
• Corrección de ARIA: 60-80%
• Evaluación de calidad de contenido: 30-50%

Lo que la IA hace bien:

• Escanear sitios grandes rápidamente para violaciones comunes
• Detectar atributos faltantes (alt, etiquetas, ARIA)
• Verificar ratios de contraste de color matemáticamente
• Identificar problemas estructurales (niveles de encabezados, landmarks)
• Generar sugerencias de código de remediación

Lo que todavía necesita humanos:

• Evaluar si el texto alt describe con precisión las imágenes
• Probar el flujo real de navegación por teclado
• Evaluar carga cognitiva y comprensibilidad
• Verificar calidad de anuncios del lector de pantalla
• Probar con combinaciones reales de tecnología asistiva

Prompt útil para análisis de accesibilidad:

Analiza este HTML para problemas de cumplimiento WCAG 2.2 AA:
[pegar HTML]

Para cada problema encontrado:
1. Citar el criterio de éxito WCAG específico
2. Explicar el impacto en el usuario
3. Proporcionar ejemplo de código conforme
4. Estimar severidad (Crítico/Alto/Medio/Bajo)

Lista de Verificación de Mejores Prácticas

Conclusión

Las pruebas de accesibilidad son un proceso continuo que requiere herramientas automatizadas, pruebas manuales con tecnologías asistivas y documentación clara. El objetivo de un informe de pruebas de accesibilidad no es solo listar violaciones—es habilitar remediación rápida y efectiva.

Los mejores informes combinan datos cuantitativos (porcentajes de cumplimiento, conteo de violaciones) con contexto cualitativo (impacto en usuario, pasos de reproducción, correcciones de código). Esta combinación da a los equipos de desarrollo todo lo que necesitan para hacer sus aplicaciones verdaderamente accesibles.

Artículos relacionados:

• Pruebas de Accesibilidad Móvil: WCAG para iOS y Android - Pruebas de accesibilidad específicas por plataforma
• Mejores Prácticas de Diseño de Casos de Prueba - Estructurar escenarios de prueba efectivos
• Guía de Pruebas Exploratorias - Descubrir problemas a través de exploración guiada
• Reportes con Allure Framework - Documentación visual de pruebas
• Pruebas Continuas en DevOps - Integrar accesibilidad en CI/CD