Carbon Design System: Accessibility, Content, Color, Motion, and Spacing Guidelines (IBM)
IBM’s open-source design system. The guideline pages (distinct from the component-library code) are generated from the carbon-design-system/carbon-website GitHub repository.
License: Apache License 2.0 — confirmed by the carbon-design-system/carbon-website GitHub repository’s own LICENSE file, which explicitly covers “documentation source,” not only software, so the prose guidance itself is safely licensed, not just the component code.
Key points
-
Accessibility Overview organizes guidance by disability type rather than by design topic: blind users (screen reader/Braille-only, no pointer), low-vision users (~4% of the population; screen magnifiers, high-contrast modes), color-blind users (8% of men, 0.4% of women), deaf/hard-of-hearing users (captioning and visual substitutes for audio), users with physical/motor disabilities (keyboard/trackball/voice-recognition reliance), and users with cognitive disabilities (memory, attention, reading-comprehension difficulties) — each with what that group needs and how the accommodation benefits everyone else too (the curb-cut effect).
-
Content: Writing style covers sentence-case vs. Title Case vs. ALL CAPS capitalization (with the readability and consistency rationale for each), second-person as the default pronoun with a first-person exception for user-owned-data labels (“My account”), the can/may/might distinction for ability and possibility, and reserving terms of politeness (“please,” “thank you”) for moments that actually inconvenience the reader rather than using them by default.
-
Content: Action labels is a glossary of ~50 standardized action-verb button labels distinguishing near-synonyms by their actual consequence — e.g. Add vs. Create vs. Insert, Cancel vs. Close vs. Done, Delete vs. Remove vs. Clear, Save vs. Apply vs. Save as, Undo vs. Reset vs. Restore — intended to keep the same word used for the same action across an entire product.
-
Color: Overview covers role-based color tokens (e.g.
$text-primary,$border-subtle,$background-hover) whose role and name stay constant across four built-in themes (White, Gray 10 — light; Gray 90, Gray 100 — dark) while only the underlying hex value swaps; each theme has its own layering model (light themes alternate White/Gray 10 per stacked layer, dark themes get one step lighter per layer). Five interaction states carry their own numeric color-shift rules on the same twelve-grade IBM palette: hover (half a step lighter/darker), active (two full steps), selected (one full step), focus (a single dedicated$focustoken, required to hit 3:1 contrast), and disabled (explicitly exempt from WCAG contrast compliance, intentionally faded). A concrete accessibility table gives the minimum number of palette steps needed between two colors to hit a 4.5:1 or 3:1 contrast ratio, for any starting color. -
Motion: Overview and Choreography cover the productive-vs-expressive motion-style distinction, three named easing curves (standard, entrance, exit) with productive/expressive cubic-bezier values for each, duration scaling by animation size, a motion-design-strategy checklist, and multi-element choreography (grid-aligned paths, semantic vs. spatial consistency, staggered entrances, and continuity elements across screens). See Motion Design.
-
Accessibility: Color gives the same WCAG contrast thresholds already documented in Accessibility, plus one addition: verify contrast holds everywhere text overlaps a gradient or image background, not just against a flat color — especially important for parallax or animated layouts where text and background move independently.
-
Accessibility: Keyboard and Accessibility: For Developers both describe a conventional logical tab order for a page’s interactive elements: header, then main navigation, then in-page/content navigation (left to right, top to bottom), then footer, consistent with the DOM-order-vs-visual-order guidance in Accessibility. The developers page also recommends accompanying a data visualization with a data-table alternative for screen reader users (see Data Tables), and choosing colors with color-blind users in mind.
-
Content: Overview is mostly IBM-internal brand/process pointers (IBM Style Guide, Brand Center, Slack channel) specific to IBM’s own organization, but its voice-vs-tone distinction is a generalizable content-design principle: keep one consistent underlying voice while letting tone — word choice, sentence length, formality — adapt to context (terse and direct for an error message, fuller and warmer for onboarding).
-
Carbon for AI covers marking AI-generated/AI-recommended content with one consistent visual signal scoped to how pervasive the AI actually is, never as decoration; using that marker as the entry point to a layered explainability popover (a short in-context summary first, more detail on request); a revert-to-AI affordance for components a user has manually overridden; and accessibility constraints on the marker itself (color contrast, limited/subtle glow effects, light/dark theme parity). See AI Content Marking.
-
Elements: Spacing gives a 13-step spacing token scale (
$spacing-01through$spacing-13, multiples of 2/4/8) used both inside components and between them for layout, plus two design-with-space rules: elements placed close together read as related and as sharing equal weight (with more spacing between groups substituting for a divider line), while elements given more surrounding space read as more important — the same mechanism a page’s own heading hierarchy uses. Explicitly names white space’s role in information processing: dense sections are fine, but a whole page left crowded overwhelms a user, and white space is what lets the eye rest. See White Space.