Why Lily

The case for Lily

Lily hands you the hard parts — semantics, accessibility, keyboard behaviour, internationalization — and leaves the look entirely, happily, to you.

Start from your design

Your team already knows how your product should look. Lily starts from exactly that place: it supplies the parts that are genuinely hard to get right and expensive to re-do — the correct semantic element, the ARIA states, the keyboard contract, focus management — and leaves every visual decision entirely, joyfully, yours. Your CSS is the design system's look, from day one.

Because every component carries a stable class hook and pure structure, your styling stays cleanly yours through every upgrade — and the accessibility underneath keeps working, version after version.

What Lily commits to

  • Accessible by default. WCAG 2.2 AAA is the target for every component. Patterns follow the WAI-ARIA Authoring Practices; every interactive component is keyboard-operable with a documented contract; the example apps hold a clean axe-core baseline.
  • Internationalizable by construction. Every user-facing string — each label, error, and announcement — is a prop with stable names across frameworks, so translation flows naturally. RTL and bidirectional text inherit from your dir. Locale-aware components take the locale as a prop, always explicitly.
  • One catalog, seven frameworks. The same 490 components with the same class hooks and prop conventions in HTML, Svelte, React, Vue, Angular, Blazor, and Nunjucks. Your CSS and your team's knowledge transfer across stacks.
  • CSS-strategy agnostic. One stable kebab-case class per component root. Semantic CSS, Tailwind utilities, CSS-in-JS, or one of the 45 ready-made themes — Lily welcomes them all and stays gracefully out of the way.
  • Free, forever, on your terms. Open source under your choice of BSD, MIT, Apache-2.0, GPL-2.0, or GPL-3.0. No pro tier, no seat licenses, no telemetry.

Depth where it matters

Beyond the usual buttons and dialogs, the catalog reaches further than most:

  • Public-sector patterns researched from the NHS UK, GOV.UK, USWDS, and ONS design systems — error summaries, warning callouts, summary lists, phase banners, skip links.
  • 80 national personal identifier components covering healthcare, national-ID, tax, and passport identifiers across 30+ countries, each documenting its format and validation algorithm.
  • Editorial and scrollytelling primitives adapted from Reuters Graphics — article layouts, scrollers, timelines, tile maps.
  • Preference helpers — small packages that own one user preference end to end: theme switching (with runtime stylesheet loading), language, and text size. Each is a native <select> with persistence and SSR safety built in.

Themes for the public sector, out of the box

Lily ships 45 standalone reference themes that target its class hooks directly: NHS England, NHS Scotland, and NHS Wales (each in patient-facing and practitioner-facing variants), GOV.UK, USWDS, Adobe Spectrum and Mozilla Protocol inspired palettes, and a set of general-purpose light and dark themes. Link one stylesheet and a government-grade look is on; the theme-select helper swaps them at runtime.

How Lily compares

We keep an honest, component-by-component comparison against 17 design systems — styled and headless, commercial and public-sector. Where another library is a better fit for you, the comparison will show it; Lily learns from all of them and cites its inspirations in the open.

Who's behind it

Lily is a young, independent open-source project that welcomes collaboration, guidance, and feedback — see About for the story and the inspirations. Everything — the specification, the tests, the roadmap, even the audit tooling — is in the open at github.com/LilyDesignSystem.

Help Lily grow

If Lily is useful to you, the most valuable things you can do:

  • Star and share. Star the main repo and show a colleague the catalog — awareness is the scarcest resource a young project has.
  • Build something and tell us. Real-world usage reports — what worked, what could be smoother — shape the roadmap more than anything else.
  • Audit accessibility. Screen-reader passes (VoiceOver, NVDA, JAWS) on the example apps are gold; file what you find.
  • Contribute a theme or a translation. Both are self-contained, well-scoped first contributions.
  • Share what you find, with a minimal reproduction, on the relevant repo, or email joel@joelparkerhenderson.com.