Hay un patrón que se repite en casi todos los auditorías de producto que hacemos en Room 714. El equipo tiene un sistema de diseño. Tiene tokens. Tiene componentes con nombres elegantes. Y tiene, enterrada en algún Jira o Notion, una columna llamada "accesibilidad" con tickets que llevan meses sin asignarse.
No es desidia. Es una consecuencia directa de cómo se ha vendido la accesibilidad durante años: como una capa que se añade al final, como un checklist de conformidad, como algo que "ya arreglaremos antes del lanzamiento". El problema es que esa capa nunca llega. Y cuando llega, llega como parche.
La tensión real no es técnica. Es de modelo mental. Mientras los equipos sigan tratando la accesibilidad como una feature opcional y no como parte del contrato estructural del producto, cada componente nuevo que construyan estará generando deuda silenciosa — del mismo tipo que la deuda técnica, pero con consecuencias que no aparecen en los logs de error.
Los iconos SVG sin etiqueta, los estados
.activeque no comunican nada a lectores de pantalla y los contrastes que "casi" pasan el ratio WCAG son síntomas del mismo problema de fondo.Un sistema de diseño sin accesibilidad integrada en su núcleo no es un sistema: es una biblioteca de componentes con fecha de caducidad.
La solución no es un sprint de accesibilidad. Es repensar en qué capa de la arquitectura de diseño se toman estas decisiones.
El Síntoma: Capas que No se Hablan
Cuando diseccionamos un sistema de diseño que tiene "problemas de accesibilidad", rara vez encontramos negligencia deliberada. Encontramos capas desconectadas. El equipo de diseño define el color en Figma con su ojo entrenado. El equipo de desarrollo lo implementa en el token. El equipo de QA lo comprueba visualmente. Nadie, en ninguno de esos pasos, ha corrido un lector de pantalla real sobre el componente.
El resultado es predecible: un botón que visualmente parece accesible tiene un ratio de contraste de 3.8:1 en lugar del 4.5:1 requerido para texto normal. Un icono de cierre en un modal tiene un <svg> sin aria-label ni title. Un estado de error en un formulario usa solo color rojo como señal, invisible para el 8% de hombres con daltonismo. Nada de esto aparece en el ticket de "componente listo para producción".
Esto tiene un nombre preciso: deuda de accesibilidad acumulada. Funciona igual que la deuda técnica — crece con intereses, se vuelve más cara de saldar cuanto más tiempo pasa, y en algún punto colapsa en forma de rediseño urgente o, peor, en forma de reclamación legal en mercados con legislación vigente (la Directiva Europea de Accesibilidad 2025 ya ha empezado a tener consecuencias reales para productos digitales).
Existe además un problema cognitivo difícil de resolver desde dentro: el equipo que construye el producto sabe demasiado. Sabe que ese icono es un "cerrar" porque lo ha diseñado. Un usuario con lector de pantalla llega a ese mismo punto sin ese contexto. Esto conecta directamente con lo que Nielsen Norman Group lleva años documentando sobre dogfooding: usar tu propio producto internamente te ayuda a detectar bugs, pero nunca puede sustituir a alguien que llega sin el mapa.
El Origen: Dónde Falla el Sistema de Diseño
Los sistemas de diseño modernos han conseguido cosas notables: consistencia visual a escala, velocidad de prototipado, un lenguaje común entre diseño y desarrollo. Pero la mayoría han optimizado para lo que se puede ver en una pantalla y en un Storybook. La accesibilidad — que en gran parte opera en lo que no se ve — ha quedado como un afterthought.
El fallo tiene tres puntos de origen habituales:
1. Los tokens de color no incluyen la capa semántica de accesibilidad
Un token llamado color-primary-500 describe un valor hexadecimal. No dice nada sobre si ese valor cumple el ratio de contraste WCAG 2.1 AA sobre fondos claros, oscuros o en estado deshabilitado. Para que el token sea útil desde una perspectiva de accesibilidad, necesita acompañarse de metadatos semánticos: ¿contra qué fondos puede usarse? ¿cumple AA? ¿cumple AAA? ¿en qué tamaño de texto?
Sistemas como el de IBM Carbon o el de Adobe Spectrum han integrado esta lógica desde hace tiempo. La mayoría de sistemas de diseño de empresas medianas no lo han hecho, y no lo hacen porque nadie lo ha puesto en el contrato de definición de "token completo".
2. Los componentes se testean visualmente, no funcionalmente
El flujo estándar de QA para un componente de UI es visual: "¿se ve bien en mobile, tablet y desktop?". A veces incluye una prueba de responsividad. Raramente incluye navegar el componente solo con teclado, activar VoiceOver o NVDA, o validar que el árbol de accesibilidad del DOM refleja el estado semántico correcto.
No se trata de hacer cuatro pruebas más por componente. Se trata de que esas pruebas estén definidas como criterios de aceptación antes de que el ticket pase a "done". Si el criterio no existe, el componente nunca falla — aunque esté roto para un porcentaje relevante de usuarios.
3. La accesibilidad se delega al final de la cadena
En muchos equipos, "accesibilidad" es la última revisión antes del lanzamiento, realizada por alguien que no ha participado en las decisiones de diseño. Este rol, por muy bien intencionado que sea, está condenado al parche: llega cuando el componente ya está construido, integrado y a veces ya en staging. Cambiar la semántica de un componente en ese punto tiene un coste real en tiempo de desarrollo.
La analogía con seguridad es perfecta aquí. Ningún equipo de producto razonable deja la seguridad para el sprint de QA final. Se piensa desde la arquitectura. La accesibilidad merece el mismo tratamiento — y está empezando a recibirlo en los equipos más maduros, aunque sigue siendo excepción.
Un sistema de diseño que no tiene accesibilidad en su núcleo no es una infraestructura de diseño. Es una biblioteca de componentes con deuda diferida.
La Estrategia: Cuatro Capas para Integrar, No Parchar
La buena noticia es que el problema tiene solución estructural. No requiere un equipo de accesibilidad dedicado (aunque ayuda). Requiere insertar las decisiones correctas en la capa correcta del proceso. Aquí está el modelo que aplicamos en Room 714 cuando auditamos o rediseñamos sistemas de diseño con este problema.
Como ya argumentamos cuando hablamos de accesibilidad como infraestructura y no como feature, el cambio de mentalidad tiene que preceder al cambio de proceso. Sin ese primer paso, cualquier estrategia técnica se convierte en cosmética.
Capa 1: Decisiones en el token
El token es el nivel más bajo y más poderoso del sistema. Si la accesibilidad no entra aquí, todo lo que construyes encima nace con una deuda. Los tokens de color deben validarse contra ratios WCAG en el momento de su definición. Los tokens de tipografía deben incluir tamaños mínimos para texto legible. Los tokens de spacing deben garantizar áreas de toque mínimas (44x44px según las guías de Apple y Google) para componentes interactivos.
Esto no es trabajo extra. Es añadir una columna más a la tabla de tokens que ya existe.
Capa 2: Criterios de aceptación en el componente
Cada componente del sistema necesita, junto a sus variantes visuales, una sección explícita de "criterios de accesibilidad": navegación por teclado documentada, roles ARIA requeridos, estados semánticos (focus, error, disabled) con su implementación esperada, y casos de prueba con lector de pantalla. Esto se puede integrar en el Storybook como addon de accesibilidad (axe-core está disponible de forma nativa) o como parte de la documentación de la librería.
Capa 3: Testing automatizado en CI/CD
Axe, Lighthouse o Pa11y pueden correr en el pipeline de integración continua y bloquear un merge si detectan violaciones críticas de accesibilidad. Esto no cubre el 100% de los problemas — las pruebas automatizadas detectan entre el 30-40% de los problemas reales de accesibilidad, según estimaciones del sector —, pero sí cubre los casos más frecuentes y evitables: atributos alt vacíos, contrastes insuficientes, formularios sin etiquetas asociadas.
Capa 4: Testing manual con usuarios reales
Esta es la capa que más incomoda porque tiene coste real y no se puede automatizar. Pero es también la única que detecta lo que ninguna herramienta puede: si la experiencia completa de un flujo (no un componente aislado, sino el flujo de registro, de compra, de onboarding) es navegable y comprensible con un lector de pantalla o solo con teclado. Conectar con organizaciones de personas con discapacidad para participar en sesiones de testing no es utopía; es algo que equipos como el de Microsoft o BBC han normalizado hace años.
La pregunta no es si tu equipo puede permitírselo. Es cuánto te va a costar no haberlo hecho cuando la Directiva Europea de Accesibilidad empiece a aplicarse de forma efectiva en tu sector.
El Negocio: Por Qué la Accesibilidad es un Argumento Económico, No Solo Ético
El argumento moral para la accesibilidad es suficiente. Pero en decisiones de producto en empresas medianas, el argumento económico es el que mueve presupuesto.
Primero, el mercado ignorado. Las personas con algún tipo de discapacidad representan entre el 15 y el 20% de la población mundial según la OMS. En Europa, hablamos de más de 100 millones de personas. Un producto que no es accesible está excluyendo activamente a ese segmento, no por decisión estratégica, sino por omisión.
Segundo, el efecto paraguas. La accesibilidad bien implementada mejora la experiencia de todos los usuarios, no solo de los que tienen una discapacidad permanente. Los subtítulos creados para personas sordas los usa todo el mundo en entornos con ruido. Los contrastes altos funcionan mejor bajo luz solar directa. Las áreas de toque generosas reducen errores en formularios móviles para cualquier dedo. Esto es lo que en diseño se llama el "curb cut effect": la rampa pensada para sillas de ruedas la aprovechan también ciclistas, personas con carritos y repartidores.
Tercero, el coste legal que se viene. La Directiva Europea de Accesibilidad (EAA) entró en vigor el 28 de junio de 2025 para la mayoría de productos y servicios digitales en la UE. No es una recomendación. Es una obligación legal con capacidad sancionadora. El coste de adaptarse ahora, desde el sistema de diseño, es una fracción del coste de hacerlo bajo presión regulatoria o tras una denuncia.
Si tu empresa opera en el mercado europeo y tu producto digital no está en el nivel AA de WCAG 2.1, ya tienes un problema de cumplimiento. La buena noticia es que resolverlo desde el sistema de diseño, antes de que escale, es todavía manejable.
La accesibilidad no es la capa de pintura que se aplica al final. Es el material del que está hecho el muro.
En Room 714 hemos visto equipos paralizar el lanzamiento de un producto por detectar tarde estas carencias. Y hemos visto otros que, con una auditoría de dos semanas sobre su sistema de diseño, han cerrado el 80% de las vulnerabilidades más críticas antes de llegar a ese punto. La diferencia no es el tamaño del equipo ni el presupuesto: es cuándo se toma la decisión.
Si quieres entender en qué capa está tu mayor deuda de accesibilidad — y qué cambiaría en tu sistema de diseño para resolverla estructuralmente —, es el tipo de conversación que nos gusta tener. El diagnóstico suele ser más rápido de lo que se espera. El ahorro, también.
