Creación de un Design System accesible

El producto había crecido a base de pantallas sueltas y decisiones puntuales, cada equipo resolvía a su manera. Teníamos tipografías que no escalaban bien, botones diferentes dependiendo de la plataforma, paletas con contrastes por debajo del mínimo legible, estados de foco invisibles, formularios sin estructura semántica clara… Una interfaz que cambia sus reglas en cada flujo obliga al usuario a reaprender constantemente y, al no tener la accesibilidad en cuenta, se dejan fuera quienes navegan con lector de pantalla, con teclado o con baja visión. El veredicto estaba claro: necesitábamos un Sistema de diseño.

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

• Tokens: Color, tipografía, espaciado y radios definidos como variables. Las rampas de color se construyeron con el modelo OKLCH, que trabaja con luminosidad perceptual real (dos colores con el mismo valor de L brillan igual ante el ojo humano). Eso convierte la accesibilidad en una constante matemática y predecible: si el paso 600 cumple WCAG AA sobre blanco, lo cumple en toda la rampa. Deja de comprobarse color por color y pasa a estar garantizada por la propia estructura.

Un caso concreto: 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. La opción fácil habría sido cambiarlo de forma drástica, pero no era viable ya que forma parte de la identidad de marca. Lo que sí hicimos fue ajustar el tono muy sutilmente para mejorar la legibilidad, sin que se notara el cambio. El verdadero peso del trabajo fue de documentación: definir con precisión cuándo y cómo podía usarse. Y para que el sistema viviera fuera de Figma, hicimos la documentación en Supernova.

• 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.

Otro caso concreto, el orden de foco: Un componente puede pasar todos los tests de contraste y romperse en cuanto alguien lo navega sin ratón. El foco saltando de un sitio a otro sin lógica, un botón «anterior» anunciado después de las imágenes, un carrusel que no avisa de cuántos elementos quedan… son los detalles que no se ven hasta que dejan a alguien fuera.

Por eso documenté cada componente interactivo en tres capas:

• Táctil: qué es tocable y cómo se interactúa con un dedo.
• Teclado: qué elementos reciben foco al pulsar Tab y en qué orden lo hacen.
• VoiceOver / TalkBack: qué anuncia el lector de pantalla y con qué jerarquía.

Escribirlo así obliga a resolver decisiones que normalmente quedan implícitas: ¿ la flecha «siguiente» mueve el foco al primer elemento o se queda en el botón? ¿ Las imágenes decorativas se anuncian o se omiten? ¿ El carrusel hace loop al llegar al final? Cada respuesta cambia la experiencia de quien navega sin ver la pantalla, y dejarlo escrito en el sistema evita que cada equipo lo resuelva a su manera.

• La parte cuantitativa: reducción de los tiempos de maquetación de nuevas pantallas y caída significativa de errores, incongruencias e incidencias de accesibilidad reportadas en QA.
• La parte cualitativa, y la que más valoro: las conversaciones cambiaron. Las discusiones sobre tamaños o colores dieron 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í.