CDC.gov
Design
System
CDC.gov had grown to hundreds of page templates maintained by separate teams with no shared component library and inconsistent accessibility compliance. This is an illustrative account of how a token-first design system was introduced without breaking what was already live.
- Templates
- 200+
- Compliance
- WCAG 2.1 AA / 508
- CMS
- Drupal
- Scope
- Public-facing
The Problem
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 didn't. Some used semantic
heading structure. Others were a single <div> soup.
Updating a shared UI element, like a site alert or an announcement banner, meant touching dozens of
templates manually.
The result was a site that looked roughly consistent but wasn't, and that passed compliance audits in some sections while failing in others. A design system is the obvious answer. The difficulty is introducing one without requiring every team to rewrite their existing pages before they can ship anything new.
Constraints
Can't break live pages
CDC.gov serves millions of visits per day on public health topics. A migration strategy that required pages to be taken offline or rewritten entirely before the design system could be adopted wasn't realistic. The system had to be introduced incrementally, with existing pages remaining fully functional throughout.
Drupal and CMS constraints
The CMS was already in place and wasn't changing. The design system had to integrate with Drupal's template and theming layer rather than replace it. New components had to work within the existing content model.
Mixed team technical backgrounds
The teams responsible for individual sections of CDC.gov ranged from highly technical to primarily content-focused. Documentation had to work for both. Components that required deep CSS knowledge to use correctly would see low adoption.
Federal compliance floor
Section 508 compliance wasn't a goal state. It was the minimum. Any component that didn't meet WCAG 2.1 AA from day one wouldn't ship.
Key Decisions
Tokens before components
The first deliverable wasn't a component library. It was a token set covering color, typography, spacing, and motion. Any team could adopt the token layer before they were ready to migrate to new components, and those tokens provided immediate visual consistency even when the underlying HTML varied.
Documentation as the real product
A component library without documentation gets adopted by the teams that built it and ignored by everyone else. 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
Design systems fail when teams start forking components to meet their immediate needs. A contribution and change process was defined before the library reached more than a handful of teams. Getting governance right with a small number of early adopters was easier than retrofitting it after widespread adoption.
508 as the default, not a checklist
Rather than auditing for compliance after components were built, accessibility requirements were part of the component specification. Color contrast, keyboard navigation, focus management, and ARIA patterns were all specified before implementation started.
Outcome
- ▶200+ page templates standardized under a single design language without requiring teams to rewrite existing pages before adoption.
- ▶Section 508 compliance established across public-facing health infrastructure that had previously passed in some sections and failed in others.
- ▶Teams across CDC adopting the same design language for new content, reducing time-to-publish for compliant pages.
- ▶The token-first approach was later referenced in CDC's published web standards (cdc.gov/wcms/4.0).
What This Reinforced
Systems fail at adoption, not implementation
Well-built components that teams don't use are not a design system. Adoption is a product problem. Solving it requires treating documentation and onboarding as primary deliverables, not afterthoughts.
Retrofit is ten times harder
Making an inaccessible component accessible after it's been deployed and adopted is dramatically harder than building it accessibly to begin with. The cost of getting it right at the specification stage is close to zero relative to the retrofit cost.
Governance is the real system
Tokens and components can be forked. What can't be easily forked is a shared decision-making process. Investing in governance early is what makes a design system durable rather than just comprehensive at launch.
Building or inheriting a design system?
Design system consulting, 508 audits, Drupal integration, USWDS implementation. If any of this maps to where you are, the contact form is the right next step.