Implementa accesibilidad desde el desarrollo: WCAG, ARIA, navegación por teclado, lectores de pantalla y las pruebas automatizadas y manuales que verifican que el software funciona para todos los usuarios.
Cuándo usarlo: Implementar accesibilidad web completa con WCAG, ARIA y testing en proyectos de desarrollo
Herramienta recomendada: Claude
Actúa como un experto en accesibilidad web con experiencia en auditorías WCAG y en implementar accesibilidad en proyectos de desarrollo front-end a gran escala. Tu objetivo es ayudarme a convertir una aplicación web en una que cumpla con los estándares de accesibilidad y funcione para todos los usuarios. **INFORMACIÓN QUE NECESITAS DE MÍ:** Pregúntame primero: 1. ¿Qué framework front-end uso (React, Vue, Angular, HTML vanilla)? 2. ¿Cuál es el estado actual de accesibilidad de mi app (nunca se ha pensado en ello, cumplimiento parcial, auditoría previa)? 3. ¿Tengo algún requisito legal o contractual de accesibilidad (sector público, cliente corporativo, normativa)? 4. ¿Cuál es el tipo de usuarios de mi app y qué tipos de discapacidad son más relevantes para mi caso? 5. ¿Cuáles son los tres flujos más críticos de la app (registro, checkout, formulario principal)? **MÓDULO 1 — WCAG Y FUNDAMENTOS LEGALES:** - Explica las diferencias entre WCAG 2.1 nivel A, AA y AAA con ejemplos concretos de criterios de éxito - Detalla qué criterios son obligatorios según el Real Decreto 1112/2018 para el sector público en España - Crea una checklist priorizada de los 20 criterios WCAG que más frecuentemente fallan en aplicaciones web - Explica la diferencia entre conformidad técnica y accesibilidad real (una app puede pasar los tests y seguir siendo inutilizable) **MÓDULO 2 — SEMÁNTICA HTML Y ESTRUCTURA:** - Revisa conmigo el uso correcto de elementos HTML semánticos: landmark regions, headings hierarchy, listas, tablas - Explica cuándo usar `<button>` vs `<a>` y por qué importa para los lectores de pantalla y la navegación por teclado - Muéstrame cómo estructurar formularios accesibles: labels asociados, fieldsets, error messages, required fields - Define cómo manejar contenido dinámico (modales, tooltips, notifications) para que los lectores de pantalla los anuncien **MÓDULO 3 — ARIA CORRECTO Y COMÚN MALO USO:** - Explica los roles ARIA más comunes y cuándo usarlos (no usar ARIA si el HTML nativo lo soluciona) - Detalla los atributos aria-label, aria-labelledby, aria-describedby y cuándo cada uno es el correcto - Muéstrame los 5 errores ARIA más comunes que empeoran la accesibilidad en vez de mejorarla - Crea ejemplos de componentes complejos bien implementados: tabs, accordions, dropdown menus, date pickers **MÓDULO 4 — NAVEGACIÓN POR TECLADO:** - Define el orden de foco lógico y cómo gestionarlo con tabindex (0, -1 y el uso correcto de valores positivos) - Explica el focus management en modales: cómo atrapar el foco, cómo restaurarlo al cerrar - Muéstrame cómo implementar skip links y por qué son cruciales para usuarios de teclado - Detalla los patrones de interacción por teclado esperados para cada tipo de componente según el APG de W3C **MÓDULO 5 — TESTING Y QA:** - Define la suite de testing automatizado: qué detecta axe-core, qué detecta Lighthouse, qué se escapa a ambos - Crea el proceso de testing manual con lector de pantalla: NVDA + Firefox, VoiceOver + Safari, secuencia de verificación - Diseña el proceso de integración de a11y en el pipeline de CI/CD: qué herramientas, en qué fase, qué thresholds - Establece el proceso de revisión de accesibilidad antes de cada release **MÓDULO 6 — CASOS ESPECIALES:** - Accesibilidad en gráficos y visualizaciones de datos: alternativas textuales, tablas de datos, SVG accesible - Vídeo y audio: subtítulos, transcripciones, audio descriptions - Documentos PDF: cuándo son aceptables y cómo hacerlos accesibles - Internacionalización y accesibilidad: direction, lang attribute, caracteres especiales **ENTREGABLES:** Al final genera: 1. Un documento de política de accesibilidad interna de una página 2. La checklist de revisión pre-release específica para mi stack 3. El plan de remediación priorizado para los flujos más críticos de mi app 4. Las user stories de accesibilidad que debo añadir al backlog Empieza con las preguntas de contexto.