← Use cases

For design leads

One token, one component, thousands of instances. Accessibility decisions made in your design system either scale or replicate, and limena tells you which.

Design system audit42 components · 3 products
4 components at fault
4
components at fault
of 42
2,140
violations from 1 token
accent-500
11
components use it
across 3 products
1
token change clears them
no screens touched
ButtonFocus ring removed by CSS reset214 usagesFail
ChipNo focus indicator in any state86 usagesFail
IconButtonTarget area 18px, below 24px minimum148 usagesAttention
TabsActive state signalled by colour only32 usagesAttention
TextFieldLabel, error, and focus all present196 usagesPass

Your decisions replicate whether they are right or not.

A design system is leverage in both directions. One accent colour that fails contrast becomes a barrier on every screen that adopts it.

Leverage cuts both ways

The reason a system is valuable is the reason a mistake in it is expensive. One failing token becomes a barrier on every screen that adopts it.

Findings arrive as pages

A report tells you 2,140 pages fail contrast. It does not tell you they are all one token, so the work looks enormous and nobody starts.

States are undesigned

Focus-visible, error, and 200 percent zoom rarely make it into the file. They are also where most component-level barriers actually are.

01 · Fix it at the token

One value, thousands of screens.

limena traces contrast failures back to the token, not the page. You see the current value, a passing alternative, and exactly how far the change reaches before you make it.

Same for focus styles, target sizes, and spacing that breaks at 200 percent zoom.

FailAccent on paper is 3.1:11.4.3

Now

#9FD4B6 · 3.1:1 fails

Proposed

#2C7A52 · 5.4:1 passes

Blast radius

Token accent-500 is used by 11 components across 3 products. Changing it here clears2,140 reported violations without touching a screen.

Update tokenSee 11 components

02 · The states nobody designs

Focus, error, and zoom get checked too.

Default and hover are always in the file. Focus-visible, disabled, error, and how the component behaves at 200 percent zoom usually are not, and that is where most component-level barriers live.

limena tests each state and tells you which one is missing rather than reporting the component as broken.

Button · state coverage214 usages
  • defaultContrast 5.4:1 with proposed tokenPass
  • hoverContrast holdsPass
  • focus-visibleNo visible indicator, removed by resetFail
  • disabledContrast 2.1:1, acceptable for disabledPass
  • errorColour is the only signalAttention
  • zoom 200%Label truncates instead of wrappingAttention

03 · Upstream of everything

Catch it in the system, not in the product.

limena tests your component library directly, in Storybook or a live docs site. A new component with no focus indicator fails there, before three product teams adopt it and it becomes thirty tickets.

This is the cheapest place accessibility can possibly be fixed.

Storybook check · design system v4.11 new
  • Button · all statespass
  • TextField · all statespass
  • Tabs · colour only on activeknown
  • Chip · no focus indicatornew

The new Chip component ships without a focus indicator. Caught in the design system pipeline, before any product adopts it.

A design system that makes accessibility the default.

  • Contrast failures traced to the token, with the blast radius shown before you change it.
  • Focus, error, disabled, and 200 percent zoom tested as states rather than reported as a broken component.
  • The component library checked directly, so a barrier is caught before three product teams adopt it.
  • One change in the system clearing thousands of instances, instead of a ticket per screen.

Point it at your Storybook.

We will tell you which tokens and components are replicating a barrier, and how far each fix reaches.

Book a demoTest a page free