Priority Styling

WIP

Priority Styling System — Cross-Component Semantics

The Priority system (Primary, Secondary, Tertiary) represents relative emphasis and intent, not a specific component type. It is a shared semantic layer applied across interactive and informational components such as:

  • Buttons

  • Chips

  • Tags

  • Navigation items

  • Toolbar actions

Priority determines visual weight, contrast strategy, and interaction emphasis, while each component defines its own structural behavior.


Priority Levels (Component-Agnostic Meaning)

Primary — Highest Emphasis

Meaning Primary indicates the most important action or status in a given context.

Across components:

  • Buttons → Main call-to-action

  • Chips → Active filter / selected state

  • Tags → Highlighted status (e.g., “Critical”, “Active”)

Design Intent

  • High contrast

  • Strong surface or fill

  • Immediate visual attention


Secondary — Moderate Emphasis

Meaning Secondary indicates supporting actions or informational states that are relevant but not dominant.

Across components:

  • Buttons → Alternative actions

  • Chips → Optional filters

  • Tags → Neutral informational labels

Design Intent

  • Balanced contrast

  • Outlined or softer fill

  • Maintains hierarchy without competing with Primary


Tertiary — Low Emphasis / Utility Layer

Meaning Tertiary represents low-priority, contextual, or utility interactions that should remain accessible without adding visual noise.

Across components:

  • Buttons → Ghost / utility actions

  • Chips → Inline removable filters

  • Tags → Passive metadata

  • Nav items → Default navigation links

Design Intent

  • Minimal default styling

  • Relies on layout context and pattern recognition

  • Strong interaction states required


Interaction Context Rule (Applies Across Components)

Tertiary priority styles may reduce default visual emphasis only when placed inside clearly interactive patterns (e.g., navigation bars, toolbars, chip groups, filter rows, or icon clusters).

This avoids misuse such as placing ghost elements in isolated layouts where discoverability is critical.


Accessibility Mapping Across Components

Priority affects visual weight, not accessibility responsibility.

Regardless of component type:

Interaction States Must Provide:

  • Visible hover feedback

  • Clear keyboard focus indicator

  • Distinct active/selected state

  • Disabled affordance

Mapped to:

  • WCAG 1.4.11 — Non-Text Contrast

  • WCAG 2.4.7 / 2.4.11 — Focus Visibility

  • WCAG 1.4.1 — No Color-Only Indicators

This applies equally to:

  • Button hover states

  • Chip selection rings

  • Tag focus outlines

  • Nav active indicators


System Principle (Important)

Priority ≠ Importance of Data Priority = UI Emphasis Layer

Example:

A “Critical” tag may use Primary visual priority A “Delete” button may still be Secondary if destructive actions are intentionally de-emphasized.

This separation lets you:

  • Avoid overusing red/strong fills

  • Preserve visual hierarchy

  • Keep semantics flexible across components

Last updated

Was this helpful?