En mi trabajo diario en Gomigo he aprendido que diseñar componentes accesibles en Figma no es solo una buena práctica ética: es una forma efectiva de reducir tiempos de desarrollo y disminuir errores en producción. Cuando los componentes vienen con reglas claras, tokens y estados bien documentados, los desarrolladores tienen menos dudas, los test automatizados fallan menos y los usuarios con necesidades diversas disfrutan de una experiencia robusta.

Por qué invertir en accesibilidad desde el diseño

Cuando diseño, siempre pienso en dos objetivos: estética y utilidad. La accesibilidad entra en la parte de utilidad, pero también impacta la estética y la eficiencia del equipo. He visto proyectos donde una decisión temprana —por ejemplo, establecer contrastes de color y comportamientos de foco— evita retrabajos costosos durante el desarrollo y la QA. Además, abordar accesibilidad desde Figma mejora la comunicación entre diseño y desarrollo: hay menos malentendidos, menos tickets y despliegues más limpios.

Principios que aplico antes de crear componentes

  • Consistencia semántica: los componentes deben reflejar roles y significados (botón, enlace, input, checkbox) en sus nombres y estados.
  • Design tokens como fuente de verdad: colores, tipografías, tamaños y espacios deben venir de tokens exportables.
  • Documentación integrada: cada componente incluye especificaciones de comportamiento (teclado, foco, lector de pantalla) y ejemplos de uso.
  • Prueba temprana: validar contraste, tab order y estados de foco desde el diseño, usando plugins y prototipos interactivos.

Cómo estructuro los componentes en Figma

Mi flujo habitual en Figma es modular y pensado para el desarrollo:

  • Árbol de capas semántico: nombres claros (button/primary/default, input/search/disabled).
  • Variants para estados: uso variantes para agrupar los estados (default, hover, active, focus, disabled, error).
  • Auto Layout y constraints: para que los componentes se comporten de forma predecible con textos largos o layouts responsivos.
  • Tokens vinculados: colores y tipografías referenciados a través de librerías o plugins como Figma Tokens.

Ejemplo práctico: botón accesible

Al crear un botón que será usado en múltiples contextos, aplico estas reglas en Figma:

  • Dos tokens de color: color-primary y color-on-primary, con contraste >= 4.5:1 para texto normal.
  • Variants: default, hover, active, focus, disabled, loading.
  • Focus visible: incluir una variante con un anillo de foco (outline) que respete contraste y espaciado.
  • Detalle de teclado: documentar que el botón debe ser activable con Enter y Space; en el componente añado un prototipo que simula el foco para mostrar el comportamiento.
Estado Propiedad visual Notas para desarrollo
default background: color-primary; text: color-on-primary role="button", tabindex=0
focus outline: 3px color-contrast; box-shadow ligero Indicador visible y persistente
disabled opacity 40%, cursor: not-allowed no focus, aria-disabled="true"

Uso de design tokens y cómo los exporto

Los tokens son la columna vertebral de la coherencia. Uso el plugin Figma Tokens (o cualquier sistema que permita sincronizar con JSON) para mantener colores, espaciados y tipografías como valores exportables. Reglas prácticas:

  • Nombrado semántico (no "azul-1" sino "color-primary", "color-bg-muted").
  • Valores contrastados verificados (usar plugins de contraste automáticos o funciones dentro de Figma Tokens).
  • Versionado: cada cambio en tokens va acompañado de un changelog para que desarrollo pueda actualizar librerías (CSS variables, tokens en JS).

Documentación incorporada al archivo Figma

No hay excusa: la documentación va dentro del archivo. Creo una página "Documentation" con patrones y checklists. Elementos que incluyo:

  • Descripción semántica de cada componente (qué es y para qué sirve).
  • Comportamiento esperado con teclado y lector de pantalla (por ejemplo: "Input de búsqueda: role=searchbox, aria-label esperado").
  • Estados y ejemplos de uso (combinaciones comunes: formulario con error, validación en línea, inputs deshabilitados).
  • Snippets de código o variables que el equipo de frontend puede copiar rápidamente.

Plugins y herramientas que uso para comprobar accesibilidad

Figma tiene una comunidad rica de plugins que aceleran el trabajo accesible. Algunos que recomiendo y uso:

  • Able o Stark: checks de contraste y simulación de daltonismo.
  • Figmotion o prototipado nativo: para simular focus y animaciones sin salir de Figma.
  • Figma Tokens: gestión y exportación de tokens.
  • Focus Order (plugin): ayuda a visualizar el orden de tabulación en prototipos complejos.
  • Export to Storybook o integraciones con Zeplin/Zeroheight: para llevar componentes y documentación al equipo de desarrollo.

Cómo reducir errores en desarrollo

Más allá del diseño, la forma en que presentamos el componente hace la diferencia:

  • Ejemplos claros: incluye variantes con múltiples longitudes de texto y tamaños de contenedor para evitar bugs de truncado.
  • Tokens exportables: facilita que frontend tenga la misma fuente de verdad (variables CSS, tokens en JS).
  • Reglas de comportamiento: documenta interacciones complejas (por ejemplo, qué ocurre con focus al abrir un modal desde un botón).
  • Handoff con pruebas: adjunta pruebas visuales y criterios de aceptación (p. ej., "contraste mínimo 4.5", "Focus visible 3px").

Colaboración con desarrolladores

La colaboración es clave. En mis proyectos suelo hacer sesiones cortas de pairing con un desarrollador para revisar componentes críticos. En esas sesiones confirmamos:

  • Valores de tokens y cómo se exportan (nombres y formatos).
  • Comportamiento del DOM y roles ARIA esperados.
  • Posibles limitaciones técnicas y alternativas (por ejemplo, animaciones que afectan a usuarios con reduce motion activado).

Pruebas que recomiendo antes de lanzar

  • Comprobación de contraste en todas las variantes de componentes (en desktop y mobile).
  • Prueba de tab order y focus con prototipos interactivos.
  • Revisión con lector de pantalla (NVDA, VoiceOver) en ejemplos clave: formularios, menús, modal.
  • Testing con usuarios o pruebas de usabilidad centradas en accesibilidad si el proyecto lo permite.

Diseñar componentes accesibles en Figma es una inversión que paga en forma de menos errores, despliegues más rápidos y una experiencia inclusiva. Implementando tokens, variantes, documentación y validaciones tempranas, convierto mis bibliotecas en fuentes de verdad que facilitan mucho el trabajo del equipo de desarrollo. Si quieres, puedo compartir una plantilla base de componentes accesibles que uso y que te sirve como punto de partida en tu propio sistema de diseño.