A design system earns its place in a regulated product environment by answering governance questions early — before the audit, before the release candidate, before someone files a complaint. That is a different job than being a component library, and teams that have not made the distinction tend to find out at the worst possible time.
The current harmonised ICT accessibility reference is EN 301 549 v3.2.1, which maps substantially to WCAG 2.1 Level AA for web content and applications. In practice, teams should be building to WCAG 2.2 now, because its Level AA additions — Focus Not Obscured (SC 2.4.11), Dragging Movements (SC 2.5.7), Target Size Minimum (SC 2.5.8), and Accessible Authentication Minimum (SC 3.3.8) — address real interaction patterns that WCAG 2.1 left unresolved.
GOVERNANCE_BEFORE_GALLERY
The pathology is familiar. The design system starts as a component library, grows into a gallery of variants, and eventually becomes a design asset repository with no real authority over what ships. Product squads fork primitives when existing ones don't quite fit. Accessibility criteria live in a spreadsheet somewhere, not attached to the components. The system stops being useful for compliance work because nobody consults it before decisions get made.
The fix is not more components. It is earlier decisions: what state does this represent, which primitive does it start from, what accessibility evidence does it require before it can be used in production. That turns the system from a reference document into a release checkpoint.
"A design system is a decision pipeline, not a UI kit."
TOKENS_AS_A_GOVERNING_LAYER
Tokens that describe intent rather than appearance hold up better across redesigns, codebases, and regulatory reviews. "Color feedback error" tells you what the token does and survives a rebrand. "Red 600" tells you nothing useful the moment a brand evolves or a dark mode is added. The naming discipline is not pedantic — it is what makes a token system auditable and semantically stable over time.
- Semantic token names that describe purpose, state, and contrast requirements — not visual outcomes.
- WCAG 2.2 acceptance criteria defined at the primitive level, before product-level composition begins.
- Contribution workflows that require written usage guidance before a new component enters the system.
- Monthly token audits to catch naming drift and semantic boundary creep before they compound.
THE_EVIDENCE_QUESTION
When an accessibility complaint arrives or a market surveillance authority requests documentation, the useful thing to have is evidence that accessibility requirements were built into the delivery process — not a recent audit report that is already out of date the moment the next sprint ships. Design systems that require accessibility acceptance criteria as a release gate create that evidence as a side effect of normal development. That is worth considerably more than a quarterly accessibility sprint that fights fires after the fact.
RUNNING_A_TOKEN_AUDIT
Token audits are where naming discipline reveals itself. The audit process is simple: export the full token list, categorize each token by its semantic purpose, and flag any token whose name could mean different things in different contexts or whose name does not survive a rebrand without losing meaning. "Blue primary" fails both tests. "Color interactive default" passes both.
The second part of the audit is contrast coverage: for every foreground-background token pairing used in production components, verify the contrast ratio at minimum and that the combination is annotated with its WCAG conformance level. This is the step that exposes assumptions baked in at the earliest design stage — often when a designer used a visually appealing combination without checking conformance, and that combination then propagated into every component built from that token.
The third part is usage scope: for each token, verify that the components using it are using it for the semantic purpose the token name describes. Tokens get misappropriated when a team cannot find an exact match for a new use case and reaches for the closest visual approximation instead. The resulting drift is invisible in visual review and only surfaces under semantic audit or compliance examination.
- Run token audits on a defined cadence — quarterly is reasonable for active design systems. More frequently after major redesigns or component library migrations.
- Track contrast ratios for all foreground-background pairings in a machine-readable format, not just in design tool annotations that do not survive component handoff.
- Flag and review tokens used outside their documented semantic scope before they are promoted to a stable release of the design system.
- Include token audit results in the design system changelog so downstream teams know what changed and why.
CONTRIBUTION_WORKFLOW_FOR_REGULATED_ENVIRONMENTS
Design systems in regulated product environments need contribution workflows that produce evidence, not just components. The evidence requirement is straightforward: for each component entering the system, there should be a record of what accessibility criteria were tested, what tools were used, who reviewed and approved the result, and when. That record does not need to be complex — a short written summary attached to the pull request that introduced the component is sufficient — but it needs to exist and be retrievable.
The part of the contribution workflow most teams skip is usage guidance. A component without documented usage constraints is a component that will be used incorrectly. The usage guidance does not need to be exhaustive, but it needs to answer the question a product team will have when they reach for the component: what state does this represent, in what context should it be used, and what states or contexts should it not be used in. That constraint documentation is what prevents a design system from expanding the scope of non-conformance as it scales.
The review step before a component enters the system is also the cheapest place to catch accessibility problems. Accessibility defects found at the component contribution stage cost a fraction of what they cost when found after a component has been deployed into fifty pages and an enforcement complaint triggers a full audit.