Diseño accesible tras la EU Accessibility Act

La European Accessibility Act (EAA) es la ley de la UE que obliga a productos y servicios digitales orientados al consumidor y comercializados en el mercado europeo a cumplir requisitos de accesibilidad alineados con EN 301 549 y WCAG 2.1 nivel AA. Entró en vigor el 28 de junio de 2025, con periodos transitorios limitados para contratos preexistentes y terminales de autoservicio.

Si vendéis un producto SaaS, un e-commerce, una app móvil, un e-reader, un servicio bancario o una plataforma de venta de entradas a consumidores en la UE, estáis dentro del alcance. Las microempresas (menos de 10 empleados y menos de 2 millones de euros de facturación) que prestan servicios están exentas, pero las microempresas que fabrican o distribuyen productos cubiertos por la EAA no lo están. Los servicios B2B puros y las herramientas internas corporativas quedan fuera del alcance.

Por qué esto duele a los equipos de producto ahora

El punto de partida es brutal. El informe WebAIM Million 2025 detectó que el 94,8% del primer millón de páginas de inicio de la web contiene errores WCAG 2 A/AA detectables automáticamente, con una media de más de 50 errores por página. Seis problemas recurrentes, encabezados por bajo contraste de texto y atributos alt ausentes, explican el 96% de todos los errores detectados. La web, en agregado, no se diseñó para ser accesible.

Las sanciones las fija cada estado miembro. España e Italia pueden multar a las grandes empresas hasta el 5% de la facturación anual por incumplimiento sistémico. Francia aplica una multa de quinta clase de 7.500 euros por violación a las personas jurídicas, con sanciones agregadas de hasta 250.000 euros por problemas sistémicos en una plataforma, más una sanción anual separada de 25.000 euros por no publicar la declaración de accesibilidad. Irlanda es hoy el único estado miembro donde las infracciones graves de la EAA pueden conllevar sanciones penales. El artículo 20 de la directiva permite a las autoridades retirar del mercado los productos no conformes.

El riesgo financiero es real, pero no es la partida más cara. La partida más cara es el coste de adaptar un producto diseñado sin accesibilidad. Los datos del sector indican que la accesibilidad construida desde el inicio cuesta aproximadamente un tercio del trabajo equivalente de retrofit. Las auditorías (2.500-10.000 euros) son baratas. La remediación (5.000-20.000 euros y a menudo bastante más) es donde el presupuesto se evapora, porque el trabajo toca cada componente, cada flujo y cada test.

Por qué auditar y parchear no basta

La mayoría de equipos recurren al mismo playbook. Encargan una auditoría externa. Reciben una hoja de cálculo con 200 filas de fallos WCAG. Se la pasan a ingeniería. Esperan que quepa en los próximos dos sprints. Esto genera tres problemas previsibles.

Primero, la auditoría captura síntomas. Los fallos más comunes (bajo contraste, alt ausentes, enlaces vacíos, etiquetas de formulario ausentes) viven en la capa de componentes. Arreglar el síntoma en doce sitios no arregla el design system que lo emitió doce veces. Tres meses después, los componentes nuevos cargan los mismos defectos.

Segundo, axe-core y herramientas automáticas similares detectan como mucho un 30-40% de los problemas WCAG. El resto (gestión del foco, anuncios de lector de pantalla, estructura semántica, patrones de interacción complejos) requiere prueba manual con tecnología asistiva. Los equipos que envían axe-verde y lo tratan como conformidad reciben la primera reclamación y lo aprenden por la vía dura.

Tercero, el retrofit envía regresiones. Cada arreglo de contraste toca la capa de tokens. Cada arreglo de focus toca la gestión del foco. Cada arreglo de label toca un input primitive compartido. Sin gobernanza, un retrofit es un producto recién roto de otra manera.

Qué cambia de verdad con accessibility-first

Accessibility-first no significa añadir la accesibilidad al backlog. Significa mover las restricciones de accesibilidad al mismo lugar donde viven las decisiones de tipografía, espaciado y color. Cuatro desplazamientos importan.

1. Los tokens cargan accesibilidad, no solo estilo

Un sistema de design tokens que envía pares de color (foreground más background) en vez de colores sueltos convierte el contraste en propiedad del token, no del consumidor. La ratio de contraste se calcula una sola vez, en la capa de tokens, y el consumidor no puede enviar una combinación no conforme. La misma lógica aplica a focus rings, tamaños mínimos de hit-area (44 por 44 píxeles CSS según WCAG 2.5.5, usado como valor por defecto del sistema) y preferencias de motion.

2. Los componentes son accesibles por construcción

Cada primitive (button, input, dialog, menu, tabs, tooltip) llega con el modelo de teclado, el patrón ARIA y la gestión del foco integrados en el componente, no en el código del consumidor. Los equipos que construyen sus primitives sobre Radix Primitives o React Aria obtienen esto casi gratis. Los equipos que construyen los suyos pagan el coste una vez y nunca más, siempre que la gobernanza aguante. El movimiento equivocado es una librería de componentes de terceros que hace mal el modelo de teclado: heredáis el bug y no podéis parchearlo. Lo cubrimos en 10 design system mistakes that wreck consistency at scale.

3. Lint y CI vigilan accesibilidad, no solo tipos

El cambio es operativo. axe-core en CI captura el 30-40% de problemas que la automatización puede detectar, antes de que se mergee la PR. eslint-plugin-jsx-a11y captura problemas de markup en el IDE. El addon a11y de Storybook los captura por componente. Ninguno reemplaza el testing humano, pero juntos evitan que el suelo se hunda entre auditorías.

4. Pruebas manuales con tecnología asistiva real, en cada release

Elegid un conjunto pequeño de flujos que expliquen el grueso de los ingresos o las acciones críticas. Probad esos flujos con VoiceOver en macOS y iOS, NVDA en Windows, TalkBack en Android y navegación solo con teclado. En cada release, no una vez al año. El plan de pruebas es una checklist; el valor está en cazar lo que la automatización no ve.

Cómo se ve en la práctica

Un equipo SaaS con el que colaboramos publica un dashboard de analytics consumer para clientes UE. Empezó en marzo de 2025 con una auditoría externa que arrojó 187 problemas distintos en 14 componentes. En lugar de arreglar los problemas en el sitio, el equipo hizo tres cosas en paralelo: reescribió las cuatro primitives más reutilizadas (button, input, modal, table) sobre cimientos accesibles; introdujo tokens en pares de color que convirtieron el contraste en propiedad del sistema; añadió axe-core y jsx-a11y en CI, con la build configurada para fallar ante nuevas violaciones.

A finales de junio de 2025, el dashboard pasaba todos los chequeos automáticos WCAG 2.1 AA y tres pasadas manuales en VoiceOver, NVDA y navegación por teclado. El coste total de ingeniería fue de 22 personas-día. El equipo legal publicó y registró la declaración de accesibilidad. Seis meses después, el equipo no ha regresado, porque es el sistema, no los ingenieros, el que vigila el suelo.

La lección no es que 22 personas-día sea el número correcto para cada producto. La lección es que el trabajo capitaliza cuando vive en el sistema y se quema cuando vive en tickets.

Por dónde empezar si vais con retraso

Tres pasos, en este orden. Ejecutad una auditoría en vuestros tres flujos principales (alta, tarea principal, pago) para entender la forma del hueco. Arreglad el design system, no las páginas, reescribiendo las cuatro a seis primitives que explican el 80% de los hallazgos. Después añadid lint y gates de CI que impidan la regresión. Saltaos estos pasos en este orden y el trabajo capitaliza; invertid el orden y volveréis a enviar los mismos arreglos el año que viene.

Accessibility-first no es una posición moral, es una posición operativa. Los productos que tratan la accesibilidad como una propiedad del sistema sirven a más usuarios, envían más rápido tras la inversión inicial y dejan de cargar riesgo de cumplimiento en cada release. La EAA cerró la puerta a la alternativa para cualquier equipo que venda en la UE.