Introducción a las Pruebas de Accesibilidad

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.1 y crear experiencias digitales inclusivas.

Niveles de Cumplimiento WCAG 2.1

Comprensión de Niveles de Conformidad

NivelDescripciónRequisitosCaso de Uso Típico
ANivel mínimoCaracterísticas esenciales de accesibilidadCumplimiento básico, requisito legal mínimo
AANivel medioEstándar recomendadoLa mayoría de sitios web, estándar de industria, requisito legal en muchos países
AAANivel más altoAccesibilidad mejoradaSitios gubernamentales, aplicaciones especializadas en accesibilidad

Principios WCAG 2.1 (POUR)

Perceptible: La información y componentes de interfaz de usuario deben ser presentables 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: Los componentes de interfaz de usuario y navegación deben ser operables

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

Comprensible: La información y operación de interfaz de usuario debe ser comprensible

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

Robusto: El contenido debe ser suficientemente robusto para ser interpretado por una amplia variedad de agentes de usuario, incluyendo tecnologías asistivas

  • Compatible con herramientas actuales y futuras
  • HTML válido y semántico
  • Uso apropiado de ARIA

Plantilla de Informe de Pruebas de Accesibilidad

Plantilla de Resumen Ejecutivo

# INFORME DE PRUEBAS DE ACCESIBILIDAD

## Resumen Ejecutivo

**Aplicación**: Plataforma Web E-Commerce
**Fecha de Prueba**: 8 de Octubre, 2025
**Tester**: Alex Rodriguez (Especialista en Accesibilidad)
**Cumplimiento Objetivo**: WCAG 2.1 Nivel AA
**Resultado General**: 78% Conforme (Necesita Mejora)

### Hallazgos Clave
- **Problemas Críticos**: 12 problemas bloqueando accesibilidad
- **Prioridad Alta**: 23 problemas impactando significativamente usabilidad
- **Prioridad Media**: 45 problemas afectando experiencia de usuario
- **Prioridad Baja**: 18 preocupaciones menores de accesibilidad

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

### Recomendación
Priorizar la corrección de todos los problemas Críticos y de Prioridad Alta dentro de 30 días para lograr cumplimiento WCAG 2.1 Nivel AA.

## 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, WAVE, Lighthouse
- **Manual**: NVDA Screen Reader, JAWS, VoiceOver
- **Navegación por Teclado**: Pruebas manuales
- **Contraste de Color**: Contrast Checker, Colorblind Simulator

### Tecnologías Asistivas Probadas
- NVDA 2024.3 (Windows)
- JAWS 2024 (Windows)
- VoiceOver (macOS, iOS)
- TalkBack (Android)
- Dragon NaturallySpeaking (Control por voz)

## Hallazgos Detallados

### Problemas Críticos (12 Encontrados)

#### Problema #1: Falta Texto Alt para Imágenes de Productos
**Criterio WCAG**: 1.1.1 Contenido No Textual (Nivel A)
**Severidad**: Crítico
**Impacto**: Usuarios de lectores de pantalla no pueden identificar productos

**Ubicación**: Página de listado de productos (/products)

**Descripción**:
Las imágenes de productos carecen de descripciones de texto alternativo. Los lectores de pantalla anuncian "imagen" sin proporcionar información significativa sobre el producto.

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

<!-- Debería ser -->
<img src="/images/product-123.jpg"
     alt="Camiseta de algodón azul con cuello redondo, talla mediana" />

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

Recomendación: Agregar texto alt descriptivo a todas las imágenes de productos. Incluir:

  • Nombre del producto
  • Características visuales clave (color, estilo)
  • Información de talla cuando sea visible

Prioridad: P0 - Crítico Esfuerzo Estimado: 2 días (100+ imágenes)


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

Criterio WCAG: 2.1.2 Sin Trampa de Teclado (Nivel A) Severidad: Crítico Impacto: Usuarios de teclado no pueden escapar de diálogos modales

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

Descripción: Cuando los usuarios abren diálogos modales usando navegación por teclado, el enfoque queda atrapado dentro del modal. Presionar Esc o Tab no cierra el modal ni permite navegación fuera.

Evidencia: Grabación de video muestra prueba de navegación por teclado donde usuario no puede salir del modal usando comandos de teclado estándar.

Pasos para Reproducir:

  1. Navegar a página de producto usando tecla Tab
  2. Presionar Enter en botón “Agregar al Carrito”
  3. Modal se abre
  4. Intentar cerrar modal usando tecla Esc - FALLA
  5. Intentar Tab fuera del modal - FALLA

Impacto en Usuario:

  • Usuarios solo de teclado: No pueden continuar comprando
  • Usuarios de lector de pantalla: Atascados en contexto modal
  • Afecta: ~15% de usuarios con discapacidades motoras

Recomendación: Implementar gestión de enfoque apropiada:

// Agregar manejador de evento de teclado
modal.addEventListener('keydown', (e) => {
  if (e.key === 'Escape') {
    cerrarModal();
    devolverEnfoqueADisparador();
  }
});

// Atrapar enfoque dentro del modal
atraparEnfoque(modal);

// Devolver enfoque al cerrar
function cerrarModal() {
  modal.close();
  botonDisparador.focus();
}

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

Problemas de Prioridad Alta (23 Encontrados)

Problema #3: Contraste de Color Insuficiente

Criterio WCAG: 1.4.3 Contraste (Mínimo) (Nivel AA) Severidad: Alto Impacto: Usuarios con baja visión no pueden leer texto

Ubicación: Múltiples páginas - botones secundarios, etiquetas de formulario, enlaces de pie de página

Descripción: Elementos de texto no cumplen con el requisito mínimo de ratio de contraste de 4.5:1. Particularmente problemático para texto gris claro sobre fondos blancos.

Evidencia:

ElementoPrimer planoFondoRatio ContrasteRequeridoEstado
Botón secundario#999999#FFFFFF2.8:14.5:1FALLA
Etiqueta formulario#AAAAAA#FFFFFF2.3:14.5:1FALLA
Enlace pie de página#888888#F5F5F53.2:14.5:1FALLA

Impacto en Usuario:

  • Usuarios con baja visión: No pueden leer texto
  • Usuarios daltónicos: Reducida legibilidad
  • Usuarios mayores: Fatiga visual y dificultad
  • Usuarios al aire libre: Resplandor solar hace texto invisible

Recomendación: Actualizar paleta de colores para cumplir requisitos de contraste:

/* Actualizar CSS */
.secondary-button {
  color: #595959; /* Era #999999 - Nuevo ratio: 7.0:1 ✓ */
}

.form-label {
  color: #4A4A4A; /* Era #AAAAAA - Nuevo ratio: 9.7:1 ✓ */
}

.footer-link {
  color: #666666; /* Era #888888 - Nuevo ratio: 5.7:1 ✓ */
}

Prioridad: P1 - Alto Esfuerzo Estimado: 3 días (revisión de diseño + implementación)


Problema #4: Validación de Formulario Sin Alternativa de Texto

Criterio WCAG: 3.3.1 Identificación de Errores (Nivel A) Severidad: Alto Impacto: Usuarios no pueden entender errores de formulario

Ubicación: Formulario de checkout, Formulario de registro

Descripción: Los errores de validación de formulario se indican solo por borde rojo sin explicación de texto. Los lectores de pantalla no anuncian errores.

Evidencia:

<!-- Actual (No conforme) -->
<input type="email"
       class="error"
       value="invalid-email" />

<!-- Debería ser -->
<input type="email"
       class="error"
       value="invalid-email"
       aria-invalid="true"
       aria-describedby="email-error" />
<span id="email-error" role="alert">
  Por favor ingrese una dirección de email válida
</span>

Impacto en Usuario:

  • Usuarios de lector de pantalla: Sin notificación de error
  • Usuarios daltónicos: No pueden ver borde rojo
  • Discapacidad cognitiva: Sin orientación clara

Recomendación: Implementar validación de formulario accesible:

  1. Agregar mensajes de error de texto
  2. Usar atributo aria-invalid
  3. Vincular errores con aria-describedby
  4. Anunciar errores con role=“alert”

Prioridad: P1 - Alto Esfuerzo Estimado: 2 días

Problemas de Prioridad Media (45 Encontrados)

Problema #5: Falta Regiones Landmark

Criterio WCAG: 2.4.1 Bloques de Bypass (Nivel A) Severidad: Medio Impacto: Ineficiencia de navegación con lector de pantalla

Recomendación:

<header role="banner">
  <nav role="navigation" aria-label="Navegación principal">
    <!-- Contenido de navegación -->
  </nav>
</header>

<main role="main">
  <!-- Contenido principal -->
</main>

<footer role="contentinfo">
  <!-- Contenido de pie de página -->
</footer>

Prioridad: P2 - Medio Esfuerzo Estimado: 1 día

Metodología de Pruebas

Pruebas Automatizadas

// Ejemplo: Integración axe-core para pruebas automatizadas
const { AxePuppeteer } = require('@axe-core/puppeteer');
const puppeteer = require('puppeteer');

async function ejecutarPruebaAccesibilidad(url) {
  const browser = await puppeteer.launch();
  const page = await browser.newPage();
  await page.goto(url);

  const results = await new AxePuppeteer(page)
    .withTags(['wcag2a', 'wcag2aa', 'wcag21a', 'wcag21aa'])
    .analyze();

  console.log(`Violaciones encontradas: ${results.violations.length}`);

  results.violations.forEach(violation => {
    console.log(`
      Problema: ${violation.description}
      WCAG: ${violation.tags.join(', ')}
      Impacto: ${violation.impact}
      Elementos afectados: ${violation.nodes.length}
    `);
  });

  await browser.close();
  return results;
}

// Ejecutar pruebas
const paginas = [
  'https://example.com/',
  'https://example.com/products',
  'https://example.com/checkout'
];

paginas.forEach(async (pagina) => {
  await ejecutarPruebaAccesibilidad(pagina);
});

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 claramente visibles
- [ ] Sin trampas de teclado
- [ ] Toda funcionalidad disponible vía teclado
- [ ] Enlaces de omisión presentes y funcionales
- [ ] Diálogos modales gestionan enfoque correctamente

### Pruebas con Lector de Pantalla
- [ ] Todas las imágenes tienen texto alt apropiado
- [ ] Etiquetas de formulario apropiadamente asociadas
- [ ] Mensajes de error anunciados
- [ ] Actualizaciones de contenido dinámico anunciadas
- [ ] Landmarks ARIA apropiadamente implementados
- [ ] Regiones live ARIA para actualizaciones
- [ ] Encabezados de tabla apropiadamente asociados
- [ ] Estructuras de lista apropiadamente marcadas

### Pruebas Visuales
- [ ] Contraste de color cumple estándares WCAG AA
- [ ] Texto permanece legible al 200% de zoom
- [ ] Sin información transmitida solo por color
- [ ] Espaciado de texto ajustable
- [ ] Contenido refluye a 320px de ancho
- [ ] Sin desplazamiento horizontal al 100% de zoom

### Multimedia
- [ ] Videos tienen subtítulos
- [ ] Audio tiene transcripciones
- [ ] Auto-play puede ser pausado
- [ ] Sin contenido parpadeante >3 veces por segundo

### Formularios
- [ ] Todos los campos de formulario tienen etiquetas
- [ ] Campos requeridos claramente marcados
- [ ] Mensajes de error son claros y útiles
- [ ] Prevención de errores para acciones críticas
- [ ] Confirmación de éxito proporcionada

### Accesibilidad Cognitiva
- [ ] Navegación consistente entre páginas
- [ ] Funcionalidad predecible
- [ ] Encabezados y etiquetas claros
- [ ] Lenguaje simple y claro
- [ ] Ayuda y documentación disponible

Plan de Remediación

Matriz de Prioridad

PrioridadPlazoProblemasEsfuerzoImpacto
P0 - CríticoSemana 1128 díasBloquea uso básico
P1 - AltoSemana 2-32315 díasImpacta significativamente UX
P2 - MedioSemana 4-64520 díasMejora experiencia
P3 - BajoSemana 7-8188 díasPulido y refinamiento

Monitoreo Continuo

Pruebas Automatizadas en CI/CD

# .github/workflows/accessibility.yml
name: Pruebas de Accesibilidad

on: [push, pull_request]

jobs:
  a11y-tests:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2

      - name: Instalar dependencias
        run: npm install

      - name: Construir aplicación
        run: npm run build

      - name: Iniciar servidor
        run: npm start &

      - name: Ejecutar pruebas axe
        run: npm run test:a11y

      - name: Subir resultados
        uses: actions/upload-artifact@v2
        with:
          name: reporte-accesibilidad
          path: reporte-accesibilidad.html

Conclusión

Las pruebas de accesibilidad son un proceso continuo que requiere herramientas automatizadas, pruebas manuales y retroalimentación de usuarios. Siguiendo las directrices WCAG 2.1 e implementando estrategias de prueba completas, las organizaciones pueden crear experiencias digitales inclusivas que sirvan efectivamente a todos los usuarios.

Las auditorías de accesibilidad regulares, monitoreo continuo y remediación priorizada aseguran que las aplicaciones permanezcan accesibles a medida que evolucionan.