DOCSEARCHbyAlgolia
Submit Docs

Momentum Design System

website·Indexed 33 days ago

https://momentum.design/en/

The design system used by Webex to design the future of work. It provides a comprehensive framework for product design and engineering, including design tokens for color, typography, elevation, and effects, as well as guidelines for accessibility, internationalization, responsive design, and interaction patterns.

Tokens
20.6K
Snippets
68
Records
140
Agent score
65%

What's inside Momentum Design System

  1. Overview of the Momentum Design System

    Momentum is the design system used by Webex to create a shared design language and a set of building blocks for all Webex products. It provides the tools necessary to build coherent products and experiences across digital and physical workplaces.

  2. Overview of Momentum Concierge agent skill

    Momentum Concierge is a tool-agnostic agent skill that answers design-system questions using canonical guidance from the Momentum Design knowledge base. It provides documented guidance on components, assets, tokens, accessibility, content, interaction patterns, internationalization, and responsive behavior. The skill is designed to retrieve existing guidance and will not create or infer new Momentum policy.

  3. Momentum Accessibility Conformance Target

    Momentum targets WCAG 2.2 Level AA as the minimum bar for shipping. While Momentum components are designed to remove whole classes of accessibility defects, the final product's accessibility depends on the composition, content, and context provided by the developer. A page built entirely from accessible components can still fail AA if it has poor focus order, missing labels, or insufficient contrast in custom surfaces.

  4. Understand Momentum Design Tokens

    Design Tokens in Momentum are variables used instead of hard-coded values to ensure flexibility and consistency across Webex products. They represent design decisions such as spacing, color, typography, font, elevation, and border radius (e.g., RGBA values for transparency or pixel widths for borders). These tokens are integrated directly into Momentum components, assets, and UI toolkits.

  5. Understand Momentum Design theme resolution

    Momentum Design uses a semantic token system where components reference stable token keys (e.g., color.theme.text.primary.normal) rather than hardcoded primitive values. At build time, these keys are compiled into CSS custom properties starting with --mds-color-theme-*.

    The value of the custom property changes based on the active theme, allowing a single component to render correctly across light, dark, and high-contrast modes without conditional code. For example, color.theme.text.primary.normal resolves to a black-alpha primitive in Stable Light mode and a white-alpha primitive in Stable Dark mode.

  6. Understand Momentum color token architecture

    Momentum uses a tiered token system to ensure consistency, accessibility, and theme support (light, dark, and high-contrast). Developers must never use raw hex codes or primitive swatches directly in components; instead, they must use semantic theme tokens.

    • Primitive Tier (color.core.*, color.decorative.*): The raw internal palette. These should not be consumed directly by components.
    • Semantic Tier (color.theme.*): Maps intent to primitives. These are the only tokens that change between themes and are the required tier for component development.

    At build time, semantic tokens are compiled into CSS custom properties. For example, color.theme.text.primary.normal becomes var(--mds-color-theme-text-primary-normal).

  7. Handle loading, empty, and error states

    Consistency in feedback states is critical for user experience:

    Loading States

    • Use mdc-skeleton for content about to appear.
    • Use mdc-spinner or mdc-progressspinner for indeterminate waits.
    • Use mdc-progressbar for known-duration or step-based progress.
    • Disable submit controls while actions are in flight to prevent duplicate submissions.

    Empty States

    • Explain what will appear in the space and provide a clear action to fill it.
    • Use a descriptive header and positive framing (avoid "No..." phrasing).

    Error States

    • Provide instructions in text; never rely on color alone.
    • Field-level errors: Place next to the field and associate programmatically.
    • Flow-level errors: Place where the user's attention is currently focused.
    • Async failures: Provide a retry path and preserve user input.

  8. Implement responsive layout with Momentum

    Momentum is unopinionated about page layout and does not provide a built-in grid or fixed breakpoint tokens. Developers are responsible for owning breakpoint detection (via CSS media queries, container queries, or device detection) and defining the page layout using standard CSS. To ensure accessibility and responsiveness, layouts must use flexible, relative units (rem, em, %, ch) to support reflow and zooming.

  9. Manage overlay behavior and dismissal

    All Momentum layered surfaces (popovers, dialogs, tooltips, etc.) must adhere to a consistent dismissal and focus model:

    Opening and Focus

    • Surfaces must open from an explicit trigger associated with the surface for assistive technology.
    • Modal Dialogs: Move focus into the surface.
    • Non-modal/Transient Surfaces (e.g., tooltips): Keep focus on the trigger.

    Dismissal

    • Escape key: Closes the topmost dismissible surface.
    • Click/Tap outside: Closes 'light-dismiss' surfaces like popovers and menus.
    • Focus Return: Upon closing, return focus to the element that originally opened the surface.

    Modality

    • Modal: Traps focus and makes the rest of the page inert. Use only for tasks that require resolution before continuing.
    • Non-modal: Allows the user to continue working and dismisses on outside interaction.
    • Hover/Focus Content: Must be dismissible, hoverable, and persistent (WCAG 1.4.13).

  10. Design error messages and alerts

    Error messages should be positive, direct, and understanding, avoiding exclamation points. The format must state what happened followed by what the user should do next.

    For alerts and in-meeting notifications, use a conversational, short, and direct tone that explains what is happening onscreen and how the product is helping.

    Example: You don’t have access to this page. Ask your admin for permission.

  11. Implement keyboard activation and navigation in Momentum

    To ensure predictability, all Momentum controls and custom components must follow these keyboard conventions:

    Activation

    • Enter and Space: Activate buttons and button-like controls.
    • Enter: Follows links.
    • Space: Toggles state for mdc-toggle, mdc-checkbox, and mdc-radio.
    • Arrow Keys: Move selection within a group of radio buttons.

    Composite Widget Navigation (Roving Focus) Composite widgets (menus, lists, tablists, comboboxes, sliders, steppers) must be a single tab stop. Use the roving-focus pattern where arrow keys move between items rather than tabbing through every child.

    • Arrow keys: Move between items along the widget's natural axis (including 4-way movement in grids).
    • Home / End: Jump to the first or last item.
    • Type-ahead: Select items by typing the first characters in listbox-style widgets.

    Note: If building a custom composite widget or grid, you must implement the roving-tabindex pattern manually. Do not use mdc-spatialnavigationprovider for per-widget arrow-key handling, as that is intended for app-level D-pad navigation (TV/Kiosk).

  12. Manage Semantics and Status Announcements

    Ensure custom controls expose their name, role, and value to assistive technology (WCAG 4.1.2). Use native elements that carry the correct role rather than styling div elements to look like controls.

    For non-focus-stealing status changes (WCAG 4.1.3), use a live region. Momentum provides mdc-screenreaderannouncer for polite and assertive announcements to avoid unnecessary focus shifts.

    // Use mdc-screenreaderannouncer for status updates