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
Nivel | Descripción | Requisitos | Caso de Uso Típico |
---|---|---|---|
A | Nivel mínimo | Características esenciales de accesibilidad | Cumplimiento básico, requisito legal mínimo |
AA | Nivel medio | Estándar recomendado | La mayoría de sitios web, estándar de industria, requisito legal en muchos países |
AAA | Nivel más alto | Accesibilidad mejorada | Sitios 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:
- Navegar a página de producto usando tecla Tab
- Presionar Enter en botón “Agregar al Carrito”
- Modal se abre
- Intentar cerrar modal usando tecla Esc - FALLA
- 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:
Elemento | Primer plano | Fondo | Ratio Contraste | Requerido | Estado |
---|---|---|---|---|---|
Botón secundario | #999999 | #FFFFFF | 2.8:1 | 4.5:1 | FALLA |
Etiqueta formulario | #AAAAAA | #FFFFFF | 2.3:1 | 4.5:1 | FALLA |
Enlace pie de página | #888888 | #F5F5F5 | 3.2:1 | 4.5:1 | FALLA |
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:
- Agregar mensajes de error de texto
- Usar atributo aria-invalid
- Vincular errores con aria-describedby
- 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
Prioridad | Plazo | Problemas | Esfuerzo | Impacto |
---|---|---|---|---|
P0 - Crítico | Semana 1 | 12 | 8 días | Bloquea uso básico |
P1 - Alto | Semana 2-3 | 23 | 15 días | Impacta significativamente UX |
P2 - Medio | Semana 4-6 | 45 | 20 días | Mejora experiencia |
P3 - Bajo | Semana 7-8 | 18 | 8 días | Pulido 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.