Skip to content
NayaOne Design System NayaOne Design System

Color usage

This section defines how colors must be used across NayaOne applications.

The color palette itself is documented separately.
See Color palette for the list of available colors and tokens.

These guidelines focus on correct usage, accessibility, and maintainability in a multi-tenant environment.

General rules

Section titled “General rules”
  • Colors must always be applied using design tokens or CSS variables
  • Hardcoded color values (HEX, RGB, HSL) are not allowed
  • Colors must be used consistently across all modules and applications
  • Visual meaning must remain consistent regardless of tenant or theme

Multi-tenant considerations

Section titled “Multi-tenant considerations”

NayaOne applications operate in a multi-tenant architecture, where branding, themes, and visual appearance may vary between tenants.

To support this:

  • All colors must be referenced via semantic tokens (e.g. --color-primary, --color-background)
  • UI components must not assume fixed brand colors
  • Tenant-specific theming must be handled through variable overrides, not component-level changes
  • Components must render correctly with different color configurations

Hardcoding colors breaks theming, increases maintenance cost, and makes tenant customization unreliable.

Use semantic color tokens

Section titled “Use semantic color tokens”

DOs

  1. Use semantic color tokens (e.g., `--color-background`, `--color-text-primary`)
  2. Respect tenant theming and overrides
  3. Validate contrast in all themes
  4. Use color consistently for the same meaning

DON'Ts

  1. Hardcode color values (`#0052CC`, `rgb(0, 82, 204)`)
  2. Use palette colors directly in components
  3. Introduce new color meanings ad hoc
  4. Rely on color alone to communicate information

Color and meaning

Section titled “Color and meaning”

Color must not be the only way to convey meaning.

  • Use color together with text, icons, or labels
  • Status colors (success, warning, error) must have consistent meaning across the product
  • Avoid introducing new color meanings without updating documentation

This is required for accessibility and usability.

References

Section titled “References”

Accessibility requirements

Section titled “Accessibility requirements”

All color usage must meet WCAG 2.1 Level AA contrast requirements.

  • 4.5:1 minimum contrast for normal text
  • 3:1 minimum contrast for large text and UI components
  • Focus indicators must meet contrast requirements
  • Disabled states must remain readable

References

Section titled “References”

Background and surface colors

Section titled “Background and surface colors”
  • Use background tokens for layout and containers
  • Do not mix background and surface roles
  • Avoid decorative backgrounds that reduce contrast or readability

Examples of appropriate usage:

  • Page background
  • Card background
  • Modal surface

Interactive states

Section titled “Interactive states”

Color usage for interactive elements must be consistent and predictable.

  • Hover, active, focus, and disabled states must be visually distinct
  • Do not rely solely on color changes for interaction feedback
  • Focus states must be visible and accessible

Interactive colors should always come from semantic action tokens.

Testing and validation

Section titled “Testing and validation”
  • Verify color contrast using automated tools
  • Test components across different tenants and themes
  • Review color usage during code review and QA