9 min lectura • Guide 756 of 877
Accesibilidad en Proyectos de Desarrollo
La accesibilidad no es opcional - es esencial. GitScrum ayuda a los equipos a rastrear requisitos de accesibilidad y garantizar que a11y sea parte de cada característica desarrollada.
Fundamentos de Accesibilidad
Por Qué Importa la A11y
IMPACTO DE LA ACCESIBILIDAD:
┌─────────────────────────────────────────────────────────────┐
│ │
│ QUIÉNES SE BENEFICIAN: │
│ │
│ DISCAPACIDADES PERMANENTES: │
│ • Usuarios ciegos (lectores de pantalla) │
│ • Usuarios sordos (subtítulos, transcripciones) │
│ • Discapacidades motrices (navegación por teclado) │
│ • Discapacidades cognitivas (diseño claro) │
│ │
│ CONDICIONES TEMPORALES: │
│ • Brazo roto (no puede usar ratón) │
│ • Infección ocular (no puede ver bien) │
│ • Ambiente ruidoso (no puede escuchar) │
│ │
│ SITUACIONALES: │
│ • Luz solar directa (bajo contraste) │
│ • Una mano ocupada (cargando bebé) │
│ • Conexión lenta (necesita contenido ligero) │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ CASO DE NEGOCIO: │
│ │
│ LEGAL: Muchos países requieren accesibilidad │
│ • ADA (EE.UU.), EN 301 549 (UE), Ley 51/2003 (España) │
│ • Las demandas aumentan anualmente │
│ │
│ MERCADO: 15% de la población mundial tiene discapacidad │
│ • Segmento de clientes significativo │
│ • Población envejeciendo aumenta │
│ │
│ SEO: Los sitios accesibles posicionan mejor │
│ • HTML semántico ayuda a motores de búsqueda │
│ • Texto alternativo mejora búsqueda de imágenes │
│ │
│ CALIDAD: Accesible = mejor para todos │
│ • Diseño más claro │
│ • Mejor soporte de teclado │
│ • Rendimiento mejorado │
└─────────────────────────────────────────────────────────────┘
Directrices WCAG
RESUMEN DE WCAG 2.1:
┌─────────────────────────────────────────────────────────────┐
│ │
│ CUATRO PRINCIPIOS (POUR): │
│ │
│ PERCEPTIBLE: │
│ El contenido debe ser presentable a los usuarios │
│ • Alternativas de texto para imágenes │
│ • Subtítulos para video │
│ • Contraste de color suficiente │
│ • Redimensionable sin perder funcionalidad │
│ │
│ OPERABLE: │
│ La interfaz debe ser utilizable │
│ • Navegación completa por teclado │
│ • Tiempo suficiente para leer contenido │
│ • Sin contenido que cause convulsiones │
│ • Navegación clara y predecible │
│ │
│ COMPRENSIBLE: │
│ Información y operación deben ser claras │
│ • Texto legible y comprensible │
│ • Comportamiento predecible │
│ • Asistencia para evitar errores │
│ │
│ ROBUSTO: │
│ Contenido compatible con tecnologías actuales y futuras │
│ • HTML válido y semántico │
│ • Compatible con tecnologías asistivas │
│ • Funciona en diferentes navegadores │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ NIVELES DE CONFORMIDAD: │
│ │
│ NIVEL A: Mínimo básico (esencial) │
│ NIVEL AA: Estándar recomendado (objetivo típico) │
│ NIVEL AAA: Mayor accesibilidad (situaciones específicas) │
└─────────────────────────────────────────────────────────────┘
Integración en el Flujo de Trabajo
A11y en el Proceso de Desarrollo
ACCESIBILIDAD EN CADA FASE:
┌─────────────────────────────────────────────────────────────┐
│ │
│ PLANIFICACIÓN: │
│ ☐ Incluir requisitos de a11y en historias de usuario │
│ ☐ Definir criterios de aceptación accesibles │
│ ☐ Considerar usuarios con discapacidades en personas │
│ │
│ DISEÑO: │
│ ☐ Verificar contraste de colores (mínimo 4.5:1) │
│ ☐ Diseñar estados de foco visibles │
│ ☐ Planificar flujo de teclado lógico │
│ ☐ Incluir textos alternativos en mockups │
│ │
│ DESARROLLO: │
│ ☐ Usar HTML semántico (h1-h6, nav, main, etc.) │
│ ☐ Implementar ARIA cuando HTML no es suficiente │
│ ☐ Asegurar navegación por teclado funcional │
│ ☐ Agregar etiquetas a formularios │
│ │
│ PRUEBAS: │
│ ☐ Probar con lector de pantalla │
│ ☐ Verificar navegación solo con teclado │
│ ☐ Ejecutar herramientas automáticas (axe, WAVE) │
│ ☐ Probar con usuarios reales cuando sea posible │
│ │
│ REVISIÓN: │
│ ☐ A11y como parte del code review │
│ ☐ Verificar antes de merge │
│ ☐ Incluir en Definición de Terminado │
└─────────────────────────────────────────────────────────────┘
Checklist de Accesibilidad en GitScrum
CONFIGURACIÓN DE A11Y EN GITSCRUM:
┌─────────────────────────────────────────────────────────────┐
│ │
│ ETIQUETAS RECOMENDADAS: │
│ ────────────────────── │
│ [a11y] - Tareas relacionadas con accesibilidad │
│ [a11y-audit] - Auditorías de accesibilidad │
│ [a11y-fix] - Correcciones de accesibilidad │
│ [wcag-a] - Requisitos nivel A │
│ [wcag-aa] - Requisitos nivel AA │
│ │
│ DEFINICIÓN DE TERMINADO: │
│ ──────────────────────── │
│ ☐ Navegación por teclado funciona │
│ ☐ Contraste de color cumple WCAG AA │
│ ☐ Imágenes tienen texto alternativo │
│ ☐ Formularios tienen etiquetas asociadas │
│ ☐ axe DevTools no reporta errores críticos │
│ │
│ TEMPLATE DE TAREA A11Y: │
│ ──────────────────────── │
│ **Problema:** [Descripción del issue de accesibilidad] │
│ **Criterio WCAG:** [Ej: 1.1.1 Non-text Content] │
│ **Impacto:** [Quién se ve afectado y cómo] │
│ **Solución:** [Cambios requeridos] │
│ **Verificación:** [Cómo comprobar que está arreglado] │
└─────────────────────────────────────────────────────────────┘
Herramientas y Pruebas
Herramientas Automáticas
HERRAMIENTAS DE PRUEBA DE A11Y:
┌─────────────────────────────────────────────────────────────┐
│ │
│ EXTENSIONES DE NAVEGADOR: │
│ ────────────────────────── │
│ axe DevTools - Detección completa de errores │
│ WAVE - Visualización de problemas │
│ Lighthouse - Auditoría integrada en Chrome │
│ Color Contrast - Verificador de contraste │
│ │
│ INTEGRACIÓN EN CI/CD: │
│ ───────────────────── │
│ axe-core - Pruebas automatizadas │
│ Pa11y - CLI para auditorías │
│ jest-axe - Pruebas de accesibilidad en Jest │
│ cypress-axe - Pruebas de a11y en Cypress │
│ │
│ LECTORES DE PANTALLA: │
│ ───────────────────── │
│ NVDA (Windows) - Gratuito, muy popular │
│ VoiceOver (macOS) - Integrado en Mac │
│ JAWS (Windows) - Profesional, muy usado │
│ TalkBack (Android)- Integrado en Android │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ IMPORTANTE: Las herramientas automáticas detectan │
│ solo ~30% de problemas de accesibilidad. │
│ Las pruebas manuales siguen siendo esenciales. │
└─────────────────────────────────────────────────────────────┘
Pruebas Manuales Esenciales
CHECKLIST DE PRUEBAS MANUALES:
┌─────────────────────────────────────────────────────────────┐
│ │
│ NAVEGACIÓN POR TECLADO: │
│ ☐ Tab navega en orden lógico │
│ ☐ Enter/Space activan elementos interactivos │
│ ☐ Escape cierra modales y menús │
│ ☐ El foco es siempre visible │
│ ☐ No hay trampas de teclado │
│ │
│ LECTOR DE PANTALLA: │
│ ☐ El contenido se lee en orden correcto │
│ ☐ Las imágenes se describen apropiadamente │
│ ☐ Los botones tienen nombres accesibles │
│ ☐ Los formularios son comprensibles │
│ ☐ Los cambios dinámicos se anuncian │
│ │
│ VISUAL: │
│ ☐ Funciona con zoom 200% │
│ ☐ Legible con modo de alto contraste │
│ ☐ Información no depende solo del color │
│ ☐ Texto redimensionable sin pérdida de contenido │
│ │
│ COGNITIVO: │
│ ☐ Instrucciones claras y simples │
│ ☐ Mensajes de error específicos y útiles │
│ ☐ Navegación consistente │
│ ☐ Sin límites de tiempo estrictos (o extensibles) │
└─────────────────────────────────────────────────────────────┘
Errores Comunes y Soluciones
Problemas Frecuentes
ERRORES DE ACCESIBILIDAD COMUNES:
┌─────────────────────────────────────────────────────────────┐
│ │
│ IMÁGENES SIN ALT: │
│ ❌ <img src="logo.png"> │
│ ✅ <img src="logo.png" alt="Logo de GitScrum"> │
│ ✅ <img src="decoration.png" alt=""> (decorativas) │
│ │
│ FORMULARIOS SIN ETIQUETAS: │
│ ❌ <input type="email" placeholder="Email"> │
│ ✅ <label for="email">Email</label> │
│ <input type="email" id="email"> │
│ │
│ CONTRASTE INSUFICIENTE: │
│ ❌ Texto gris claro sobre fondo blanco │
│ ✅ Ratio mínimo 4.5:1 para texto normal │
│ ✅ Ratio mínimo 3:1 para texto grande │
│ │
│ SOLO EVENTOS DE RATÓN: │
│ ❌ onClick sin equivalente de teclado │
│ ✅ onClick + onKeyPress/onKeyDown │
│ ✅ Usar <button> en lugar de <div> clickeable │
│ │
│ FOCO INVISIBLE: │
│ ❌ outline: none; sin alternativa │
│ ✅ Estilos de foco visibles y claros │
│ ✅ :focus-visible para mejor UX │
│ │
│ ARIA MAL USADO: │
│ ❌ Usar ARIA cuando HTML semántico es suficiente │
│ ❌ role="button" en un <div> sin comportamiento │
│ ✅ Preferir HTML semántico primero │
│ ✅ ARIA solo cuando HTML no puede expresar semántica │
└─────────────────────────────────────────────────────────────┘
Métricas y Seguimiento
KPIs de Accesibilidad
MÉTRICAS DE A11Y PARA RASTREAR:
┌─────────────────────────────────────────────────────────────┐
│ │
│ TÉCNICAS: │
│ • Errores de axe por página │
│ • Puntuación de Lighthouse Accessibility │
│ • Cobertura de pruebas de a11y │
│ • Tiempo promedio para corregir issues de a11y │
│ │
│ PROCESO: │
│ • % de historias con criterios de a11y │
│ • % de PRs con revisión de accesibilidad │
│ • Tareas de a11y completadas vs pendientes │
│ • Auditorías de a11y realizadas por trimestre │
│ │
│ IMPACTO: │
│ • Tickets de soporte relacionados con accesibilidad │
│ • Feedback de usuarios con discapacidades │
│ • Conformidad con estándares (A, AA, AAA) │
└─────────────────────────────────────────────────────────────┘
Recursos Adicionales
Documentación y Guías
RECURSOS DE APRENDIZAJE:
┌─────────────────────────────────────────────────────────────┐
│ │
│ OFICIALES: │
│ • WCAG 2.1 Guidelines (w3.org/WAI/WCAG21) │
│ • WAI-ARIA Authoring Practices │
│ • MDN Accessibility Guide │
│ │
│ CURSOS: │
│ • Web Accessibility by Google (Udacity) │
│ • Deque University (dequeuniversity.com) │
│ • A11y Project Checklist │
│ │
│ COMUNIDAD: │
│ • WebAIM (webaim.org) │
│ • The A11y Project │
│ • Inclusive Design 24 conferencia │
└─────────────────────────────────────────────────────────────┘