Request Demo

Support

How can we help you?

Get answers to all your Stark-related questions with
step-by-step guides from our Support center.

Monitoring your design system

Using Stark's plugins and integrations to keep your design system accessible

Why Stark Belongs at the Center of Your Design System

Stark is an accessibility platform built to support teams across design, development, and QA. Rather than one off audits, Stark provides continuous, proactive accessibility feedback. Stark becomes the connective tissue that keeps your design system accessible as it scales.

Using Stark with your design system allows you to:

  • Catch accessibility issues while designing, not after release

  • Enforce consistency across colors, typography, components, and patterns

  • Validate real, coded output in browsers and CI

  • Monitor your design system documentation and Storybook over time

The key mindset shift: accessibility is a vital component of your system, not a checklist item. Stark is how you operationalize that. With a majority of accessibility issues originating in design, having an accessible design system can significantly reduce the chances (and cost) of issues that make their way to production.

The Importance of Monitoring Your Design System

Design systems aren’t static. They evolve alongside the product and often see an accelerated amount of iterations as time goes on. Stark monitoring ensures they don’t silently degrade.

With Stark monitoring, you can:

  • Track improvements or regressions over time along the entire workflow
  • Check common accessibility issues as components are being design
  • Detect new accessibility issues as code changes
  • Continuously scan design system URLs

This turns accessibility into an ongoing signal, not a one-time report.

Handle Proactive Monitoring (From Day One)

Like a wise philosopher once said: if you're ready, you don't have to get ready. Stark's power lies in being your sidekick while you work and then monitoring your assets for compliance. Here's a general outline of how to be proactive instead of waiting for audits:

  • Use Stark during creation, not cleanup

  • Treat accessibility checks like linting for design

  • Normalize small, frequent fixes

In practice what that can look like is:

  • Designers check contrast when adding new tokens

  • Component authors validate states as they’re created

  • Pattern owners run spot checks before publishing updates

This keeps your design system “clean by default.” Let's talk about how to set this up in every stage of your design system's workflow.

Design

Project Architecture of Your Design System

There are plenty of options when it comes to architecting your design system. Broad all the way to granular; we've seen just about all ways here at Stark!

Our recommended option is as follows:

  • Foundations (color, type, spacing, motion)

  • Components (buttons, inputs, nav, etc.)

  • Patterns (forms, modals, flows)

  • Templates / Examples

Each layer builds on the previous one. Stark works best when accessibility is validated at the lowest possible level (foundations first, patterns last). Breaking it down further: we've seen teams keep each of these categories as separate pages, but we've also seen teams break each part (colors, type, etc.) into their own page. It will largely depend on the size and make up of your design system, but know that Stark can handle either way.

Setting Up the Figma Connection

The Stark Figma plugin is likely to be the starting point of making your design system accessible. You'll be able to check every aspect of your design system as you're building and maintaining it. 

Best practices for your team:

  • Install Stark for every designer working in system files (foundations, components, patterns)

  • Ensure all design system files live in a shared Figma project so accessibility standards are applied consistently

  • Encourage designers to keep Stark open while working—not just during review

Once connected, Stark can be used to evaluate:

The great thing is that a lot of these issues can be found and fixed using our Auto Scan and Fix feature. Additionally, once you have foundation items like color and typography in place, Stark can use that for other designers that are consuming your design system doing their own accessibility checks.

Preparing Your Design System for Engineering Handoff

Design is just one part of the equation with design systems. Stark provides the tools necessary to help you annotate your designs to make things super simple for your engineers. In general you'll want to ensure you're doing the following before handing off:

Not every component, pattern, or template will need to have the above items annotated, so use your best judgment and communicate with your developer to understand what they need.

Monitoring Your Design Files

You've done the work to ensure your design system files are accessible, now you need to monitor them so you can ensure you stay on top of any issues that crop up. Plus, it's a great way to show off your accessibility work. Use this article to get setup with adding a Figma file to a project.

When it comes to structuring your design system projects within Stark, there are a couple of ways to go. Discuss with your team to find out which one would work best.

You could do a separate project for each design system category:

  • Foundations
  • Components
  • Patterns, etc.

Or you could get more granular and have a project for each part:

  • Colors
  • Type
  • Buttons, etc.

Development

Automate Code Checks

Stark offers code scanning integrations with all of the major frameworks including React, Vue, Angular, React-Native, and Flutter. Setting these up is quick and easy and gives you two great options for checking the accessibility of your code: linting (red squiggly lines!) and a CLI tool for broad project scanning. Both options allow you to leverage the AI tools you're already using as well by providing error context to the tools so you can be sure you're getting accurate fixes. 

And, of course, you can send these results up to Stark for monitoring; they'll live right alongside your Figma files and other assets.

CI/CD Integration: Deep Workflow Checks

If you're looking to build out the most robust design system, we highly recommend checking out CI/CD. Why? Because CI/CD allows you to simulate a browser and user inputs. Paired with Stark, you can put your components into different states and run accessibilty checks on those different states.

Not only that, CI/CD more easily allows you to:

  • Automatically scan changes before merge

  • Block releases that introduce critical issues

  • Enforce accessibility standards at scale

Stark offers integrations with all of the major setups (Puppeteer, Playwright, and Cypress). They're a great option for monitoring your design system as well. For design systems with many contributors, we feel this is essential guardrail infrastructure.

Checking Out Your Design System In-Browser

You've got the design system built in Figma and you've implemented it into code. Once the parts and pieces of your design system are built, Stark shifts from design validation to real-world verification. We recommend all roles have the browser extension (design, development, QA).

Using the Stark browser extension, you can:

The browser extension can be run on any page so use it on your documentation, your template sites, or any demo sites you may have set up for your design system. What's more, you can also send results of those WCAG Audits up to Stark for monitoring. 

Another Way to Verify: Storybook Addon

Storybook is a fantastic way to validate and document your design system. With it, you'll get:

  • Automated checks per component

  • Early detection of accessibility issues before adoption

  • A shared source of truth for designers and developers

This is especially powerful for teams treating Storybook as their system hub.

Live Scanning of Design System URLs

The final piece of your design system worklfow is likely going to be sites. These can include:

  • Design system documentation sites

  • Storybook instances

  • Public or internal component libraries (Stark supports scans behind authentication)

It's important these live sites are monitored as they ensure:

  • Documentation remains accessible

  • Demos reflect real accessibility quality

  • Issues are caught even outside active development

These sites can live alongside your other assets detailed above which gives you true end-to-end visibility of your design system's accessibility so you can more easily trace and track where issues arise. 

Summary

We've covered a lot of ground in ensuring your design system starts and stays accessible. To summarize our general approach:

  • Run Stark checks when adding or modifying anything

  • Fix issues immediately while context is fresh

  • Keep monitoring running at every stage

  • Track your issues over time to ensure compliance

These habits are what keeps a design system sustainable. When Stark is embedded:

  • In Figma during design

  • In code while developing

  • In the browser during implementation and QA'ing

  • In CI and monitoring after release

…your design system becomes accessibility-first by default, not by exception.

That’s how accessibility scales.

Go back to articles