Creación de un Design System accesible

El producto había crecido a base de pantallas sueltas y decisiones puntuales, no contábamos con un sistema de diseño. Cada equipo resolvía a su manera: tipografías que no escalaban bien, paletas con contrastes por debajo del mínimo legible, estados de foco invisibles, formularios sin estructura semántica clara. La inconsistencia visual era el síntoma más evidente, pero el problema real era de accesibilidad. Una interfaz que cambia sus reglas en cada flujo obliga al usuario a reaprender constantemente, y deja fuera a quienes navegan con lector de pantalla, con teclado o con baja visión.

Empecé por una auditoría de los componentes existentes contrastada con WCAG 2.2 AA. A partir de ahí, construí el sistema en tres capas:

• Tokens: Color, tipografía, espaciado y radios definidos como variables. Los pares de color se diseñaron para garantizar contraste suficiente en cualquier combinación válida del sistema, no solo en la pareja «ideal».
• Componentes: Cada elemento se documentó con sus estados (default, hover, focus, active, disabled, error), su comportamiento con teclado y su equivalencia semántica en código. El foco visible y la jerarquía tipográfica dejaron de ser decisiones cosméticas para convertirse en parte estructural del componente.
• Patrones: Formularios, navegación, mensajes de error, tablas y estados vacíos siguen una misma lógica de retroalimentación, etiquetado y orden de lectura.

Para que el sistema viviera fuera de Figma, se sincronizó con Storybook y se acordó un proceso de gobernanza compartido con desarrollo: una pieza solo entra en el sistema cuando cumple los criterios definidos.

Un caso concreto: el verde de marca. El color principal de qdq es un verde eléctrico muy reconocible, casi fluorescente. Visualmente potente, pero con un contraste por debajo del mínimo legible sobre blanco para texto a tamaño normal. Eliminarlo no era una opción dado que forma parte de la identidad de marca, así que el trabajo no consistió en sustituirlo, sino en definir con precisión cuándo y cómo se podía usar.

El sistema lo documentó así: válido en superficies grandes, fondos, ilustración, gráficos y elementos decorativos; no válido como color de texto sobre blanco ni como único indicador de estado (un error nunca se comunica solo con color). Cada token se acompañó de una matriz de combinaciones permitidas y prohibidas, con ejemplos visuales y el ratio de contraste de cada par.

• La parte cuantitativa: aumento del contraste medio del producto, reducción de los tiempos de maquetación de nuevas pantallas y caída significativa de las incidencias de accesibilidad reportadas en QA.
• La parte cualitativa, más interesante: las conversaciones cambiaron. Las discusiones sobre tamaños o colores dejaron paso a decisiones de producto. El sistema absorbió el ruido y dejó espacio para pensar.

La accesibilidad no se añade al final, o forma parte del sistema, o se vuelve una capa frágil que se cae con el primer deadline ajustado. Un design system funciona cuando se entiende como una herramienta de gobierno: define qué decisiones están abiertas y cuáles ya están resueltas. El equilibrio entre negocio, usabilidad y accesibilidad no se negocia en cada proyecto; se diseña una vez y se hereda a partir de ahí.