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 governing accessibility standard for products covered by the European Accessibility Act is EN 301 549 v3.3.1, which maps substantially to WCAG 2.1 Level AA. In practice, teams should be building to WCAG 2.2 now. The newer success criteria — Focus Appearance (SC 2.4.11, 2.4.12), Dragging Movements (SC 2.5.7), and Target Size Minimum (SC 2.5.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.