TOKENSA Design Tokens Workflow - Part 18: How Colour Works with the DTCG Color Module
Part 18 of this ongoing series dives into the DTCG Color Module and why structured colour tokens outperform raw hex strings. The spec wraps each colour in a typed object carrying colorSpace (sRGB, OKLCH, HSL, Display P3, and more), normalized 0-to-1 components, an optional alpha, and a legacy hex fallback. The author makes a strong case for OKLCH as the authoring space for 2026 — citing Material Design 3, Carbon, and Parity as adopters — because equal lightness steps feel perceptually equal, making automated ramp generation reliable. Practical Style Dictionary transform examples show how to auto-generate colour ramps, derive WCAG AA/AAA-compliant text colours at build time, and output one token to multiple platform formats. Migration from an existing hex system is incremental: new tokens author in OKLCH while old tools consume the hex fallback.
Read Articlearrow_forward Article · GOVERNANCEREAD TIME: 10m
Building Your Design System Workflow: Rituals and Templates
This practical guide moves beyond theory to describe the specific rituals, templates, and governance structures that make a design system team function. It covers RFC templates for contribution proposals, a Design System Council of 4-6 people meeting on a fixed cadence, structured Slack channels (#design-system-announcements, #design-system-proposals, #design-system-support), and Architecture Decision Records that serve as institutional memory. Documentation is treated as a hard definition of done — a component does not ship until it is documented. The author walks through a phased implementation: audit, design, pilot one component end-to-end, refine, launch, and iterate quarterly. Semantic versioning with 2-3 release deprecation notice cycles and migration guides (including codemods) round out the change-management section.
READ_FULL_LOGarrow_forwardArticle · AI AGENTSREAD TIME: 8m
Open Design System Format: Hand Your Design System to an Agent
Sascha Becker introduces the Open Design System Format (ODSF), a strict profile of Google's Open Knowledge Format (OKF) that packages a design system as a self-contained bundle of markdown, HTML, and CSS readable by coding agents. The core insight is that agents writing UI consistently produce plausible-but-wrong results — slightly off brand colours, incorrect spacing — because no machine-readable form of the design system is available at generation time. ODSF solves this by writing each token once in frontmatter and projecting it mechanically to CSS custom properties, keeping description and runnable values in sync. The format ships typed concept categories (Color, Typography, Component, Pattern, Behavior, Guideline), do/don't companion HTML example assets, and a zero-dependency validator. An odsf skill for Claude Code, Cursor, Codex, and Windsurf automates authoring and ripple-checks every token edit across the full bundle.
READ_FULL_LOGarrow_forwardArticle · ACCESSIBILITYREAD TIME: 3m
ARIA, Anti-Patterns, and You
David Bushell fires a sharp warning at the growing trend of pointing LLMs at the ARIA Authoring Practices Guide (APG) to generate accessible UI code. The APG was designed to demonstrate that the ARIA specification works across browser and assistive technology implementations — not to serve as a best-practice reference for production sites. The guide's own markup includes div role="button" examples that should never appear in real code. Quoting the WebAIM Million study, Bushell notes that increased ARIA usage correlates with higher detected accessibility errors. The W3C's first rule of ARIA use states plainly: if a native HTML element with the required semantics exists, use it instead. Misuse of ARIA — especially when LLM-generated — makes the web measurably less accessible.
READ_FULL_LOGarrow_forwardArticle · MONOREPOREAD TIME: 11m
How to Build a Scalable Design System in a Monorepo
Vineeth Pawar walks through building a multi-package design system using Turborepo, structuring packages as a layered ladder: tokens at the base, then primitives, layouts, screens, and navigators. The tokens package exports typed TypeScript constants for colors, spacing, and typography; the primitives package consumes them to build React components like Button with variant and size props; and turbo.json wires the build pipeline so tokens always compile before primitives. The approach is validated by pointing to Microsoft Fluent UI, IBM Carbon, Shopify Polaris, Atlassian Atlaskit, and MUI as production examples. The article is candid about when monorepos are not the right fit: single-product teams, vastly different release cadences, or heterogeneous language stacks. Changesets and Lerna are mentioned for independent package versioning within the shared repo.
READ_FULL_LOGarrow_forwardArticle · ACCESSIBILITYREAD TIME: 5m
Designing for People with Reading Disabilities
TetraLogical's Grace Snow presents a practical design guide for content and UI that serves people with dyslexia, hyperlexia, alexia, and other reading disabilities. The article covers six concrete areas: plain language over academic phrasing (replace "implementation will commence" with "starts"), formatting for flow with left-aligned text and 70-80 character line lengths, typography choices that prioritize distinct letterforms and larger x-heights over branded fonts, targeting a reading age of 9-11 and using tools like Hemingway to test grade level, expanding acronyms on first use, and pairing text with icons and descriptive link labels for users with low digital literacy. The guide emphasises that inclusive reading design benefits everyone — second-language readers, users in a hurry — and is a shared responsibility across editors, copywriters, and designers.
READ_FULL_LOGarrow_forwardArticle · COMPONENTSREAD TIME: 3m
Announcing spartan/ui 1.0
After nearly three years in deliberate alpha, spartan/ui reaches a stable 1.0 with over 55 production-ready Angular components built on signals, zoneless-ready, and SSR-compatible out of the box. The library's defining architecture remains a two-layer split: spartan/ui/brain handles ARIA, keyboard navigation, and focus management as a maintained dependency, while spartan/ui/helm copies the styling layer directly into the consumer project for full ownership and customization without fighting the library. The 1.0 release nearly doubles the original 30-component alpha by adding a Data Table with sorting, filtering, and selection, a Sidebar, Calendar, Date Picker, Carousel, Autocomplete, Pagination, and Breadcrumb. New Blocks — pre-assembled responsive layouts for auth pages, sidebar layouts, and multi-step steppers — reduce scaffolding time significantly. The library is MIT-licensed and infrastructure is sponsored by Zerops.
READ_FULL_LOGarrow_forwardsummarizeDigest_Summary
Design systems this week focused on color token standards, governance, and the emerging challenge of making systems readable by AI agents. The DTCG Color Module series (Part 18) made a strong case for OKLCH as the 2026 authoring color space — citing Material Design 3, IBM Carbon, and Parity as adopters — because its perceptually uniform lightness steps make automated ramp generation reliable. Practical Style Dictionary transform examples showed how to auto-generate color ramps, derive WCAG AA/AAA-compliant text colors at build time, and output one token to multiple platform formats. Migration from hex is incremental: new tokens use OKLCH while legacy tools consume the hex fallback.
Sascha Becker introduced the Open Design System Format (ODSF), a strict profile of Google's Open Knowledge Format that packages a design system as markdown, HTML, and CSS readable by AI coding agents like Claude Code, Cursor, Codex, and Windsurf. The insight driving it: agents consistently produce plausible-but-wrong UI because no machine-readable design system is present at generation time. An odsf skill automates authoring and ripple-checks token edits across the full bundle. spartan/ui reached 1.0 after three years in alpha, shipping 55+ Angular components built on signals, zoneless-ready, and SSR-compatible, with a two-layer brain/helm architecture that separates ARIA logic from styling.
Two governance pieces rounded out the week. A practical guide to design system rituals covered RFC templates, a 4–6 person Design System Council, structured Slack channels, and Architecture Decision Records, treating documentation as a hard gate before any component ships. A Turborepo monorepo walkthrough showed how to layer tokens, primitives, layouts, screens, and navigators with Microsoft Fluent UI, Shopify Polaris, and IBM Carbon as production references.
Key Takeaways- The DTCG Color Module's OKLCH-first typed token objects, now adopted by Material Design 3 and IBM Carbon, enable build-time WCAG AA/AAA text-color derivation and reliable automated ramp generation that hex strings cannot provide.
- Open Design System Format (ODSF) addresses the core AI-agent UI problem: agents produce wrong colors and spacing because no machine-readable design system exists at generation time — ODSF bundles tokens as frontmatter projected mechanically to CSS custom properties.
- spartan/ui 1.0's brain/helm split — ARIA and keyboard logic as a maintained dependency, styling copied into the consumer project — is a practical architectural pattern for escaping library lock-in while keeping accessibility guarantees.
