from the test kitchen —
Improving an inaccessible CMS and building a shared React + Next.js component library for one of the most recognized cooking brands in the US.
America's Test Kitchen operates across multiple editorial brands, each with its own visual identity, its own product team, and its own publishing cadence. The challenge isn't unique to ATK: when a single component library needs to serve multiple products that look different but share behavior, the architecture has to be built for that from the start. Libraries designed for one brand and retrofitted for others quickly accumulate the wrong kind of complexity. At ATK, I built a shared component library in React and Next.js that could serve multiple brand surfaces without requiring separate implementations for each one.
Step one
A component library that serves multiple brands has two failure modes. The first is rigidity: the library is built for one brand, and every other brand works around it, producing inconsistency and parallel implementations. The second is fragmentation: the library tries to accommodate every brand's specifics directly, and the component API becomes so configurable that it stops enforcing anything.
The solution to both is a clean separation between behavior and appearance. Components own their behavior: keyboard navigation, focus management, ARIA attributes, interaction patterns. Visual styling is supplied through the token system, which each brand can configure independently. A modal behaves the same way across every brand. It looks different because the tokens it references resolve to different values depending on which brand context it's rendered in.
This isn't a novel approach. It's the approach that lets systems scale without fragmenting. The work is in executing it consistently across every component in the library.
Built for one brand. Every other team works around it. Parallel implementations sprout in the margins.
Every brand's specifics baked into the API. The component stops enforcing anything and becomes a config soup.
Step two
Building the library for this architecture meant making specific decisions at every layer.
Props controlled behavior and content — not visual style. No
brand
prop forking the render tree. Visual differences flowed through the token system instead.
Every brand difference had to be expressible as a token value rather than a one-off override. Gaps always surface as CSS escape hatches, and that's how brand divergence accumulates.
Usage examples, variant coverage, and a11y notes were part of a component's definition of done — not something added afterward. An undocumented component gets used incorrectly or rebuilt by a team who couldn't find it.
A modal behaves the same way across every brand. It looks different because the tokens resolve differently depending on which brand context it's rendered in.
Step three
A multi-brand component library has a compounding relationship with accessibility. A keyboard navigation gap in a shared component isn't one violation — it's the same violation across every product that consumes the library. That made the case for treating accessibility as an architectural concern, not something addressed per-brand or per-feature.
Keyboard operability, ARIA implementation, focus management in overlay components, and contrast against the token system's color values were requirements for every component, not optional enhancements. A developer using the library to build a feature got accessible behavior without having to implement it. That's the structural benefit of treating accessibility as a component-level concern.
Step four
The compounding return on a well-built shared component library shows up over time. New brand surfaces launch faster because the behavioral foundation already exists. The component API enforces the right patterns, so features ship consistently across brands. And because the documentation is accurate and the system is coherent, new engineers ramp up by reading it.
A shared library built on a weak architectural foundation multiplies its problems at the same rate it multiplies its value. Every brand surface that consumes it inherits the same structural gaps.
Behavioral foundation is already there — new surfaces mostly wire up tokens.
The component API quietly enforces the right patterns for every team that uses it.
New engineers learn the system by reading it — because the docs are part of done.
tasted & approved —
Josh built the component library that finally let our brands stop fighting in code. Cook's Country, Cook's Illustrated, and ATK all share the same primitives now — the visual difference comes from tokens, not parallel implementations. He raised the floor on accessibility for every team that touches the system.
Fran Middleton
Chief Digital Officer · America's Test Kitchen
Start with a free scorecard, or grab 30 minutes on my calendar to talk through where your system is leaking.