Skip to content
← back
§ CASE STUDY / FLAGSHIP

A design system, engineered

A unified, whitelabel-themeable, accessibility-first design system for five behavioral-health products. Shipped as real, tested, published packages, hardened over four audit rounds, with accessibility enforced in CI.

80 + 87
REACT + WEB COMPONENTS
2,051
AUTOMATED TESTS
4
AUDIT PASSES
ROLE
Token architecture + a11y eng
SHIPS AS
5 npm packages
STACK
Lit · React 19 · MUI · DTCG
SERVES
5 products, EHR + portal
§ 01

The problem

Five products acquired over time meant five design languages and five front-end stacks (React, legacy MUI, .NET/Razor, patient portals). That fragmentation shows up as inconsistent UX and, most seriously, inconsistent accessibility, a legal exposure in healthcare. The mandate I set: one system any stack can adopt without rewriting its tooling, that themes to each customer’s brand, and is accessible by construction.

§ 02

A token engine, not a token list — try the real thing

The system takes one brand hex and generates a full 12-step scale in light and dark, with a WCAG-safe contrast walk built in. Whitelabel onboarding becomes a single input, and light and dark are algorithmically independent, not a naive inversion. Below is the library itself — its own docs app, built from source and embedded live:

qf-design-library · docs app · live embedopen full screen ↗
loading the library…
This is the library’s own demo app, built from source and embedded — every control is the real shipped component. Try Demos → Patient Portal and Foundation → Theming & Dark Mode (pick a brand color; the whole system re-themes, contrast held).

The same engine powers this site’s theme generator, and the open-source token-scale library.

§ 03

Accessibility as architecture

Accessibility isn’t a pass at the end; it’s enforced by the pipeline and hardened over repeated audits. Four full accessibility passes plus a semantic token audit, capped by flipping axe to a blocking CI gate:

5
AUDIT PASSES
32+
REMEDIATION PRS
2.2 AA
WCAG CONFORMANCE
Round 1 — Foundational hardening2026 · 9 PRs

Green main, a browser test harness, and the first accessibility sweep across overlays, forms, and tokens.

Browser test harnessOverlay + dropdown layeringForm-surface a11yTokens + typographyStandalone browser bundles
Round 2 — Final-mile remediation2026-07-04 · 12 PRs

A 12-PR series closing every R/P/B finding, capped by flipping axe to a blocking CI gate. Logged in a decision doc.

Focus trap + return-focus (native <dialog>)Anchor-position popper sweepRem typography + 1.4.12 text-spacingLabel + error-summary announcementsForced-colors + reduced-motionDensity system (32/44 target-size floor)Print stylesSession-timeout primitive (WCAG 2.2.1)MUI v4 adapter verifyaxe → blocking (final gate)
Round 3 — Baseline + docs2026 · 4 PRs

Regenerated the visual baseline, isolated browser tests, and closed a documentation-completeness punch list.

Baseline regenerationBrowser test isolationDocs completenessPunch list
Round 4 — Figma parity2026 · 6 PRs

Component-by-component parity pass against Figma: accordion, action footer, avatar identity, chip focus, button states.

Accordion parityAction-footer Figma parityAvatar-identity parityChip focus / tabindexWeb-component button pressed-fg
Semantic token audit2026-06 · 1 PR

A fallback-drift correction sweep that surfaced token-design mismatches (e.g. divider + button-hover) to triage with design.

Fallback-drift correction (PR #171)Divider token reviewIndicator-surface token proposalButton-hover value reconciliation

All 9 net-new WCAG 2.2 criteria + all 50 WCAG 2.1 A/AA, at the component layer. jsdom unit tests + a real-Chromium browser suite (focus / Escape / composed-tree). Consumers inherit ~90% of a WCAG 2.2 AA audit by adopting the primitives.

AI LEVERAGE

The system carries its own agents (ds-new-component, ds-migrate,ds-copy-review) so contributions follow the rules automatically. I built the workflow that keeps the system conformant, not just the components.

§ 04

Built for stacks that can’t all be React

Token + primitive foundation
form-associated custom elements · DTCG tokens
React 19Web Components (Lit)MUI v4 / v5.NET / RazorAngularVuePlain HTML

Adopt without rewriting tooling. Two shared primitives mirrored across React + Web Components so semantics never drift.

87 Web Components in Lit, every form control a form-associated custom element, every overlay a native <dialog>, drop into .NET/Razor, Angular, Vue, or plain HTML. An MUI bridge (v4 + v5) lets legacy surfaces adopt incrementally.

§ 05

Shipped like a real library

And here it is running on this page — a realistic patient-intake slice built entirely from the shipped components. The mode and brand controls are isolated to this window: flip it to dark, hand it a customer’s brand color, and watch every component re-theme with contrast held.

Every component family — actions, form inputs, selectors, navigation, feedback, data display, overlays — ships in the packages above. Open the full library docs app ↗

2,051 tests across 186 files (tokens, MUI bridge, Web Components jsdom + Playwright, React + axe). Standalone family bundles with tracked gzip budgets; a browser support floor enforced by a lint script; a print layer; full i18n. Documented non-goals (IE11 unsupported, and exactly why): the mark of a maintained system, not a demo.

§ 06

What it demonstrates

Token architecture and contrast math; accessibility as a build-time system hardened over four audits; cross-framework engineering; test and release discipline; and workflow tooling that scales a system across an org. The purest expression of the hybrid profile: a designer whose deliverable is shipped, tested code.