Component Extension
Component Extension

Carbon Toggle Button

Carbon Toggle Button

A state Carbon hasn't shipped, specced once for four frameworks and verified twice with AI.
A state Carbon hasn't shipped, specced once for four frameworks and verified twice with AI.
A state Carbon hasn't shipped, specced once for four frameworks and verified twice with AI.

Focus:

Focus:

Token Architecture, Dev Handoff

Role:

Role:

Senior Product Designer, Design Systems

Date:

Date:

August 2026

Live Demo:

Live Demo:

OVERVIEW

OVERVIEW

This case study tests an AI-assisted answer to a gap still open in Carbon's Button component today: no pressed or toggle variant, confirmed against Carbon's live Storybook. One token-and-spec source of truth, translated into React, Angular, Vue, and vanilla JS, then checked against the live design file twice: once by Claude, once by Claude Code, a day apart, rather than trusted on sight. Built solo as a proof-of-concept against a hypothetical organization grounded in Carbon's own public documentation, not a commissioned engagement.

PROBLEM

PROBLEM

The Cost of System Gaps

How manual workarounds fracture cross-framework parity
How manual workarounds fracture cross-framework parity

Carbon's Button component lacks a native pressed or toggle variant, a known gap accepted by their team but never shipped.

Enterprise organizations requiring this functionality are forced to hand-translate the extension into every supported framework independently. Without a centralized token pipeline, this manual duplication introduces an immediate risk of ecosystem drift, where critical ARIA attributes, tokens, and visual specs inevitably diverge across codebases.

Carbon's Button component lacks a native pressed or toggle variant, a known gap accepted by their team but never shipped.

Enterprise organizations requiring this functionality are forced to hand-translate the extension into every supported framework independently. Without a centralized token pipeline, this manual duplication introduces an immediate risk of ecosystem drift, where critical ARIA attributes, tokens, and visual specs inevitably diverge across codebases.

Carbon's own component list, no toggle or pressed variant exists.

APPROACH / PRINCIPLES

APPROACH / PRINCIPLES

Extend, Don’t Replace

Extend the System, Don’t Replace It

Leveraging carbon’s own variables over parallel palettes
Carbon’s Own Variables, Not a Parallel Palette

The token layer extends Carbon's own semantic variables for the new toggle state rather than inventing a parallel palette: the standard discipline of any token-based system is to extend the source, not duplicate it. AI was strictly scoped to where it added proven value: dev-handoff translation via Claude, independently re-verified by Claude Code against the live repo a day later. The judgment call was knowing where to extend the system rather than rebuild it, a design decision made before any tooling question came up.

The token layer extends Carbon's own semantic variables for the new toggle state rather than inventing a parallel palette: the standard discipline of any token-based system is to extend the source, not duplicate it. AI was strictly scoped to where it added proven value: dev-handoff translation via Claude, independently re-verified by Claude Code against the live repo a day later. The judgment call was knowing where to extend the system rather than rebuild it, a design decision made before any tooling question came up.

Same tokens, new component

Same tokens, new component

DECISION

DECISION

One Token Set, Extended With Behavior

One Token Set, Extended With Behavior

Why a toggle state needed a real spec, not just new colors
Why a toggle state needed a real spec, not just new colors

Every token (background, border, icon, focus, across both On and Off) comes from Carbon's own Theme collection, not a new palette built for this control. The real decision wasn't about color, it was about behavior: a toggle has to track whether it's on or off, and hold that distinction even when disabled, so it needed two full sets of states rather than a simple color variant. On mirrors Primary's filled treatment with a double-ring focus, Off reads as a lighter Tertiary outline with a single-ring focus. That token layer now has to mean the same thing in four frameworks, highlighting the actual test of scaling a design system. Built as a sibling to Carbon's Button family, not a modification of it, this was the safer choice for a state Carbon hasn't shipped yet.

Every token (background, border, icon, focus, across both On and Off) comes from Carbon's own Theme collection, not a new palette built for this control. The real decision wasn't about color, it was about behavior: a toggle has to track whether it's on or off, and hold that distinction even when disabled, so it needed two full sets of states rather than a simple color variant. On mirrors Primary's filled treatment with a double-ring focus, Off reads as a lighter Tertiary outline with a single-ring focus. That token layer now has to mean the same thing in four frameworks, highlighting the actual test of scaling a design system. Built as a sibling to Carbon's Button family, not a modification of it, this was the safer choice for a state Carbon hasn't shipped yet.

On/Focus — double-ring: Focus/focus (outer) + Focus/focus-inset (inner).

On/Focus — double-ring: Focus/focus (outer) + Focus/focus-inset (inner).

Off/Focus — single-ring, 2px Focus/focus only. No inset layer.

Off/Focus — single-ring, 2px Focus/focus only. No inset layer.

BUILD + DOCUMENTATION

BUILD + DOCUMENTATION

A Spec Built to Survive Four Translations

A Spec Built to Survive Four Translations

State behavior, not just token values
State behavior, not just token values

The dev-handoff artifact pairs a full token map with an accessibility layer all four frameworks implement identically: state announced to screen readers, detectable even when disabled, labeled by action rather than status. That layer, mirrored into a structured token export alongside the CSS, is real usage documentation, the same do's/don'ts a governance doc carries, scoped to one component. Claude caught a mismatch against Carbon's own source: Off/Disabled was specced with border-disabled, but Carbon's Tertiary/Disabled button binds to button-disabled, corrected to follow Carbon's actual precedent.

The dev-handoff artifact pairs a full token map with an accessibility layer all four frameworks implement identically: state announced to screen readers, detectable even when disabled, labeled by action rather than status. That layer, mirrored into a structured token export alongside the CSS, is real usage documentation, the same do's/don'ts a governance doc carries, scoped to one component. Claude caught a mismatch against Carbon's own source: Off/Disabled was specced with border-disabled, but Carbon's Tertiary/Disabled button binds to button-disabled, corrected to follow Carbon's actual precedent.

The token file documents its own known issues — three raw, unaliased values inherited from Carbon's source, flagged inline rather than hidden.

Carbon’s own component list — no toggle or pressed variant exists.

Carbon’s own component list — no toggle or pressed variant exists.

One token source, four framework consumers — tokens/ next to react/, angular/, vue/, vanilla/.

Carbon’s own component list — no toggle or pressed variant exists.

Carbon’s own component list — no toggle or pressed variant exists.

VALIDATION

VALIDATION

Two Passes, Two Different Jobs

Two Passes, Two Different Jobs

Translated once, verified independently
Translated once, verified independently

Claude translated the token JSON and spec across all four frameworks, sharing one stylesheet and one accessibility contract. Checked against the live Figma component, two errors surfaced: the designer caught a square corner radius that should've been a full circle, Claude caught a skeleton state missing its full-bleed clipped gradient. A day later, a second independent tool ran the same check from a different angle: Claude Code, connected to Figma via MCP, re-verified the deployed repo directly, checking every token, focus state, and accessibility attribute, across all four frameworks. Every check passed, two documentation issues were corrected. Both passes are live: repo Leon-Os-Design/carbon-toggle-button-handoff, deployed on GitHub Pages.

Claude translated the token JSON and spec across all four frameworks, sharing one stylesheet and one accessibility contract. Checked against the live Figma component, two errors surfaced: the designer caught a square corner radius that should've been a full circle, Claude caught a skeleton state missing its full-bleed clipped gradient. A day later, a second independent tool ran the same check from a different angle: Claude Code, connected to Figma via MCP, re-verified the deployed repo directly, checking every token, focus state, and accessibility attribute, across all four frameworks. Every check passed, two documentation issues were corrected. Both passes are live: repo Leon-Os-Design/carbon-toggle-button-handoff, deployed on GitHub Pages.

Two independent tools, two different days, one verified result.

Two independent tools, two different days, one verified result.

The Human Element
Why automated pipelines still require sharp human judgment and rigorous governance


While this proof-of-concept proves that automated cross-framework translation holds on a complex behavioral component, scaling the pipeline requires distinct organizational governance.


Directing an AI translation pipeline successfully demands a precise specification and sharp design judgment. The designer caught a critical visual mismatch (square buttons against circular source components) by eye, proving that while tools like Claude Code can run deep repository integrations (git, build tooling, CI), a designer's eye is still required to detect error. The automated mechanism translates reliably, but it still requires human oversight to govern usage and negotiate scale across an organization.

Design systems, UX, and the judgment that connects them. Let's talk.

© 2026 Leon Os Design

Design systems, UX, and the judgment that connects them. Let's talk.

© 2026 Leon Os Design

Design systems, UX, and the judgment that connects them. Let's talk.

© 2026 Leon Os Design