Stark: accesibilidad dentro de Figma para revisar contraste y daltonismo
Stark es un plugin de Figma que revisa contraste, simula daltonismo y comprueba foco y áreas táctiles. Qué hace, cuánto cuesta en 2026 y qué no reemplaza.
¿Qué es Stark?
Es un plugin de Figma pensado para detectar problemas de accesibilidad mientras se diseña. En lugar de esperar a que exista código, lo aplicas sobre marcos, componentes y estilos del archivo.
La página oficial del plugin lista como funciones el comprobador de contraste con sugerencias de color, el orden de foco, los puntos de referencia (landmarks), el simulador de visión con protanopia, tritanopia, acromatopsia y otras, los tamaños de área táctil, la revisión de tipografía, las anotaciones de texto alternativo y una vista previa en el navegador (Stark, “Figma plugin”). La página afirma que ayuda a crear software que cumple “los estándares de accesibilidad más recientes”.
¿Cuánto cuesta hoy?
Este dato cambia con frecuencia, así que confírmalo en la fuente. A noviembre de 2026, la página oficial de precios indica estos planes: Premium Pack, desde 198 dólares por usuario al año con un mínimo de tres asientos; Launch, desde 2.500 dólares al año; Grow, desde 8.000 dólares al año, y Scale, desde 21.000 dólares al año. También ofrece empezar con una cuenta de equipo gratuita, sin detallar sus límites.
Los planes no se diferencian solo por el precio. Según la tabla comparativa, el Premium Pack cubre 10 páginas, con escaneos manuales y reportes guardados 14 días. Launch sube a 100 páginas con escaneos semanales y admite además repositorios de código y URL públicas. Grow y Scale suman CI/CD, apps iOS y Android, integración con tickets, un borrador automático de VPAT y inicio de sesión único (SSO).
Varios comparadores publican precios mensuales más bajos que no coinciden con la página oficial, así que no los uses para presupuestar.
Antes de pagar, pregúntate qué necesitas de verdad. Si solo quieres revisar el contraste de un par de pantallas, uno de los muchos plugins gratuitos de contraste puede bastar. Stark tiene más sentido cuando el equipo debe revisar muchos componentes, compartir decisiones de accesibilidad y dejar un registro de lo que se comprobó.
¿Por qué le importa a un diseñador?
Porque el contraste y el daltonismo son problemas que se resuelven mejor antes de programar. Si el gris del texto secundario falla el contraste, corregirlo en Figma cuesta minutos. Corregirlo después en veinte componentes cuesta días.
BrowserStack, que revisa varios plugins de accesibilidad, destaca de Stark la comprobación de contraste, la simulación de deficiencias visuales y la retroalimentación en tiempo real sobre cumplimiento WCAG, y recomienda crear esquemas de color inclusivos a partir de sus sugerencias (BrowserStack, “Best Figma plugins to design for accessibility”).
Para entender qué mide un contraste y por qué un valor pasa o falla, la matemática del contraste de color te da el fondo que necesitas para interpretar los resultados.
¿Cómo se usa en un flujo real?
Un flujo sencillo:
- Revisa la paleta antes de componer pantallas. Comprueba los pares de texto y fondo más usados, incluyendo estados de error y de foco.
- Simula visiones. Mira la pantalla principal con protanopia y tritanopia. Si un estado depende solo del color, lo verás enseguida.
- Revisa el orden de foco y los puntos de referencia (landmarks). Son los puntos que más se pierden entre diseño y código.
- Anota los textos alternativos en las imágenes que aportan significado.
- Documenta lo que decidiste. Si se acepta un contraste justo por una razón, deja nota en el archivo.
Un detalle que se olvida: si tu producto tiene modo oscuro, corre las mismas comprobaciones sobre ese tema. Un par de colores que cumple en claro puede fallar en oscuro, y el resultado de uno no sirve para el otro.
Ejemplo
Ejemplo ilustrativo: un equipo diseña un panel de métricas en el que los estados “en riesgo” y “en objetivo” se diferencian solo por rojo y verde. Al simular protanopia en Stark, los dos estados se confunden. El diseñador añade un icono y una etiqueta de texto, vuelve a comprobar el contraste del texto nuevo y documenta el cambio en el componente. Ninguno de esos pasos requirió programar.
¿Qué NO hace Stark?
- No audita el código. Un botón puede verse bien en Figma y estar mal implementado. Para eso están las herramientas de navegador, como axe DevTools.
- No reemplaza a personas usuarias. Una simulación de visión es una aproximación. Las pruebas con lectores de pantalla y con personas que usan tecnologías de apoyo siguen siendo necesarias (pruebas con lectores de pantalla).
- No corrige el diseño por ti. Sugiere colores, pero la decisión de marca y de jerarquía sigue siendo tuya.
- No cubre contenido dinámico. Estados que aparecen con interacción o animación exigen revisión en el producto real.
Errores comunes
- Confiar en que un “pasa” en Figma garantiza accesibilidad.
- Revisar solo la pantalla principal y no los estados de error, vacío y foco.
- Corregir el contraste oscureciendo todo y perdiendo la identidad visual.
- Usar la simulación de daltonismo como única prueba de color.
- Presupuestar con precios de comparadores en lugar de la página oficial.
Cómo empezar mañana
Abre el archivo de tu producto y ejecuta el comprobador de contraste sobre la pantalla más visitada. Anota los fallos en una lista, empezando por los textos pequeños. Después, simula protanopia y revisa si algún estado depende solo del color. Con esa lista, abre un ticket en tu gestor de tareas y otro para la revisión de accesibilidad del proceso. Si el problema ya está en producción, lleva el caso a una revisión de código con axe.