Construye aplicaciones que funcionan para todos: niveles de conformidad WCAG, técnicas de implementación y el proceso de testing de accesibilidad que el equipo puede integrar en el flujo de desarrollo.
Cuándo usarlo: Implementar accesibilidad web WCAG de forma sistemática en el flujo de desarrollo
Herramienta recomendada: Claude
Actúa como un senior developer especializado en accesibilidad web con experiencia implementando los estándares WCAG en aplicaciones web de distintas tecnologías y complejidades. Voy a explorar contigo cómo construir aplicaciones accesibles de forma sistemática. Mi contexto: [describe tu stack tecnológico: framework frontend (React, Vue, Angular u otro), tipo de aplicación (SPA, SSR, web app compleja) y el nivel actual de accesibilidad de tu producto] Trabaja conmigo en profundidad en los siguientes bloques: **1. Los estándares WCAG: qué son y qué exigen** Las Web Content Accessibility Guidelines son la referencia internacional de accesibilidad web. Explícame los fundamentos que todo developer debe conocer: los cuatro principios WCAG (Perceptible, Operable, Comprensible, Robusto), los tres niveles de conformidad (A, AA y AAA) y qué implica cada uno en la práctica, cuál es el nivel que la mayoría de las aplicaciones debe alcanzar y por qué (AA como estándar mínimo en contextos legales en la UE), y la diferencia entre conformidad técnica (cumplir los criterios de éxito) y accesibilidad real (que la aplicación funcione bien para personas con distintas capacidades). **2. Los criterios de éxito que más fallan en la práctica** Algunos criterios WCAG son mucho más frecuentemente incumplidos que otros. Explícame los criterios de éxito que el equipo de desarrollo debe tener siempre presentes: el contraste de color suficiente (1.4.3 y 1.4.11), la navegación completa con teclado (2.1.1), el orden de foco lógico (2.4.3), las etiquetas accesibles para elementos de formulario (1.3.1 y 4.1.2), el texto alternativo para imágenes (1.1.1), la accesibilidad de los componentes custom (árbol de accesibilidad correcto), y el comportamiento de los lectores de pantalla en flujos críticos. Para cada criterio, dame la implementación correcta con código de ejemplo. **3. El HTML semántico como fundamento de la accesibilidad** La mayoría de los problemas de accesibilidad tienen la misma raíz: usar elementos HTML genéricos (`div`, `span`) donde existen elementos semánticos apropiados. Explícame por qué el HTML semántico es el fundamento de la accesibilidad: la estructura de encabezados que permite la navegación por secciones, el uso de `button` vs. `div` clickable (y por qué la diferencia importa), los elementos nativos de formulario que vienen con accesibilidad integrada, las landmarks de HTML5 (`main`, `nav`, `header`, `footer`, `aside`) que estructuran la página para los lectores de pantalla, y el árbol de accesibilidad que el navegador construye desde el DOM y cómo inspeccionarlo. **4. ARIA: cuándo usarlo y cuándo no** ARIA (Accessible Rich Internet Applications) extiende la accesibilidad de los componentes interactivos custom, pero se usa mal con mucha frecuencia. Explícame las reglas de ARIA que el developer debe conocer: la primera regla de ARIA (no usar ARIA si existe un elemento HTML nativo que hace lo mismo), los roles ARIA más comunes y cuándo aplicarlos, los atributos `aria-label`, `aria-labelledby` y `aria-describedby` y sus diferencias, el manejo del foco en componentes custom (modales, dropdowns, tabs) con `aria-expanded`, `aria-haspopup` y `tabindex`, y los errores de ARIA que crean problemas de accesibilidad en lugar de resolverlos. **5. Testing de accesibilidad: automatizado y manual** La accesibilidad no se puede verificar únicamente con herramientas automáticas, pero las herramientas automáticas son el primer paso. Explícame el proceso de testing de accesibilidad que el equipo puede integrar en el flujo de desarrollo: las herramientas de análisis automático que se integran en el CI/CD (axe-core, Lighthouse), las extensiones de navegador para testing rápido durante el desarrollo (axe DevTools, WAVE), el testing manual con teclado (el flujo completo de la aplicación navegando solo con Tab, Shift+Tab, Enter y las teclas de flecha), el testing con lectores de pantalla (NVDA + Chrome en Windows, VoiceOver en macOS, TalkBack en Android) y el testing con usuarios reales con distintas capacidades. **6. Integrar la accesibilidad en el proceso de desarrollo** La accesibilidad que se añade al final del proceso es cara y difícil. Explícame cómo integrarla desde el principio: el rol del developer en la revisión de diseños desde la perspectiva de accesibilidad (detectar problemas antes de que estén en código), los criterios de aceptación de accesibilidad que deben incluirse en las historias de usuario, el proceso de code review que incluye verificación de accesibilidad, el linting de accesibilidad en el IDE (eslint-plugin-jsx-a11y para React), y cómo construir la cultura de accesibilidad en un equipo que todavía no la tiene en el radar. Quiero ejemplos de código reales para los errores más comunes y sus correcciones. Y la lista de cosas que el developer puede hacer hoy, sin esperar a un proyecto de accesibilidad formal.