Web · Implementation study
A design system that holds a site together as it grows
Tokens, component states, and contrast rules that keep the tenth page looking like the first, and keep accessibility from being a retrofit.
What the demo shows
The token palette, type scale, component states, and contrast readouts shown here are an illustration of how such a system is presented. Contrast figures are for the sample values on this page.
Proposed system flow
- 01Design tokens
- 02Component states
- 03Contrast checks
- 04Consistent pages
01
Name the decisions once and reference them everywhere
A design system starts as a small set of named decisions about colour, type scale, spacing rhythm, radius, and elevation, defined in one place and referenced by every component. The discipline that matters is the naming: tokens that describe a role, such as surface, muted text, or accent, survive a rebrand, while tokens named after the colour they currently hold do not. Once roles are stable, a theme change becomes a change to token values rather than a search across a codebase, and the difference between a light and dark presentation stops being a second design to maintain.
02
Design every state, not just the resting one
Most inconsistency enters through the states nobody drew. A component specification is incomplete until it covers hover, focus, active, disabled, loading, error, and empty, because those are the states an implementer will otherwise invent independently each time. Focus deserves particular attention: a visible focus indicator is what makes a site operable by keyboard, and removing the default outline without replacing it is the single most common way a professional-looking site becomes unusable for part of its audience. The ARIA authoring practices give tested interaction patterns for the composite components, such as menus, tabs, and comboboxes, where hand-rolled behaviour tends to break.
03
Put contrast in the system rather than in a review checklist
Contrast is a property of a token pair, so it can be checked once where the pairs are defined instead of being rediscovered page by page. WCAG sets a floor of 4.5 to 1 for normal text and 3 to 1 for large text and meaningful interface boundaries, and treating those as build-time assertions over the palette turns an accessibility audit finding into a failing check before anything ships. The pairs most often missed are not body text but the quiet ones: placeholder text, disabled states, borders that carry meaning, and text over photographs or gradients.
04
Keep the system honest about performance
A component library that grows without pruning becomes the reason a site loads slowly, and the cost is rarely visible in development. Shipping only the styles a page uses, keeping web fonts to the weights actually referenced with sensible fallbacks so text is readable while they load, and reserving space for images and embeds so the layout does not jump are all system-level decisions rather than per-page fixes. Holding the system to the same field measurements used for the site keeps it from quietly becoming the bottleneck.
Validation plan
- Assert every token pairing meets its contrast target as an automated check, and fail the build on a regression rather than catching it in review.
- Navigate every interactive component by keyboard alone and confirm a visible focus indicator and the interaction pattern the authoring practices specify.
- Render each component in all documented states in one place so drift is visible, and review it when components change.
- Track field performance measurements after adopting the system to confirm it is not adding weight faster than it removes duplication.
More in web
Have a similar problem to solve?
Discuss your project