CDC.gov Design System
CDC.gov had grown to hundreds of page templates maintained by separate teams across WordPress with no shared component library and inconsistent accessibility compliance. This is an illustrative account of how the Template Package, a token-first design system, was introduced without breaking what was already live.
01 Problem
The work behind the ask
Large federal sites grow without a plan. CDC.gov had over two hundred distinct page templates developed across different teams, different time periods, and different interpretations of CDC brand guidelines. Some templates had accessible navigation. Others did not. Some used semantic heading structure. Many older pages were built with table layouts for visual design.
The result was a site that looked roughly consistent but was not. It passed compliance audits in some sections while failing in others. A design system was the obvious answer. The difficult part was introducing one without requiring every team to rewrite existing pages before they could ship anything new.
02 Constraints
What shaped the solution
Live pages had to keep working
CDC.gov serves high-stakes public health content. A migration strategy that required pages to be taken offline or rewritten entirely before the system could be adopted was not realistic.
WordPress was staying
The design system had to integrate with WordPress templates and theming rather than replace the platform or the content model around it.
Teams had mixed technical backgrounds
Many developers had inherited older code patterns and needed training to move away from table layouts and toward modern semantic HTML. Documentation had to work for front-end developers, content teams, and product owners. Components that required deep CSS knowledge would see low adoption.
Compliance was the floor
Section 508 compliance was not a goal state. It was the minimum standard for anything that shipped.
03 Decisions
The choices that mattered
Tokens before components
The first deliverable was not a component library. It was a token set covering color, typography, spacing, and motion. Teams could adopt the token layer before they were ready to migrate components.
Documentation as the real product
Each component shipped with usage guidelines, accessibility rationale, and Drupal-specific implementation notes. The documentation was written for the least technical audience who would ever use it.
Governance before scale
A contribution and change process was defined before the library reached more than a handful of teams. That made it easier to prevent one-off forks from becoming the default.
Accessibility baked into examples
Examples were not decorative demos. They were the reference implementation for keyboard behavior, focus state, ARIA naming, and reduced-motion expectations.
“A token-first system gives teams consistency before migration. Visual coherence can improve even where the HTML underneath still varies.”
04 Outcome
What changed
- Standardized the visual language across a large public health site without forcing a full rebuild first.
- Created a clearer accessibility path by pairing each component with implementation guidance and testable behavior.
- Reduced repeated decisions for teams that needed to ship content and interface updates quickly.
05 Lessons
What this reinforced
Adoption is a product problem
The best component API does not matter if teams cannot understand when and how to use it.
Tokens make migration possible
They create immediate value for teams that are not ready for full component adoption.
Compliance needs examples
Written rules help, but accessible reference markup removes ambiguity.
Need the implementation side?
I work best where design systems, accessibility, and front-end architecture need to meet in production code.