Progress

Basic

<progress class="bo-progress" max="100" value="71" aria-label="71% of budget consumed"></progress>
<span class="bo-u-text-muted">71% consumed</span>

Born from a real dogfood finding: unstyled native <progress> renders platform-blue chrome that ignores the theme in both light and dark — this class is the token-true re-skin.

Tones — threshold states

<progress class="bo-progress" max="100" value="42"></progress>
<span class="bo-u-text-muted">42% consumed</span><br>
<progress class="bo-progress bo-progress--warning" max="100" value="83"></progress>
<span class="bo-u-text-muted">83% consumed — approaching budget</span><br>
<progress class="bo-progress bo-progress--danger" max="100" value="97"></progress>
<span class="bo-u-text-muted">97% consumed — review before approving</span>

--warning / --danger for approaching/exceeded thresholds. The tone is decoration on top of the text — the accompanying text must say it ("approaching budget"), never the color alone. Fill-on-track contrast for all three tones is gate-checked at 3:1 (WCAG 1.4.11) in both themes.

On a dashboard card

The dashboard pairing: a stat tile carries the number, the bar makes the trend scannable at a glance across a grid of cost centers.

Markup

<!-- A real <progress> element — value/max semantics and the progressbar
     role come from the platform; the class only re-skins it. ALWAYS pair
     with visible text: the fill and its tone are one channel each. -->
<progress class="bo-progress" max="100" value="71"></progress>
<span class="bo-u-text-muted">71% consumed</span>

Quick reference generated

API generated from CSS

• A native <progress> element, not a div — value/max and the progressbar role are platform semantics; the framework only styles it. Give it an accessible name (aria-label or a <label>) — adjacent prose text is NOT programmatically associated, and the name can carry the real value when you visually cap the bar ("112% of budget consumed" with value="100").
• Always pair with visible text ("71% consumed") — the fill is one channel, and tones are decoration on top of the text, never a substitute for it.
• Under forced-colors the element reverts to platform rendering (appearance: auto) — custom fills would otherwise vanish entirely.
• Always set value — indeterminate (value-less) progress is NOT supported by this styling (appearance: none suppresses the platform's indeterminate animation, so "unknown" would render as an empty bar). For unknown-duration work, use Skeleton instead. If a determinate flow LOSES its value mid-stream (an import stalls, the server stops reporting), keep the bar at its last value and let the paired text say so ("stalled at 93%") — don't swap components mid-flow.
• For discrete named steps (Submitted → Approved → Paid), use Stepper instead.

Maturity generated

Introduced

v0.1.0

CSS floor

Chrome/Edge 99 · Firefox 97 · Safari 15.4

Alignment scored

2026-08-23

Assistive-tech evidence

None recorded

Pin this component's first release with npm i @busy-office/ui@0.1.0. The floor is derived from this component's stylesheet alone — set by @layer — so it sits at or below the whole framework's Chrome/Edge 119 · Firefox 129 · Safari 17.5. No assistive-technology runtime result is recorded for any component: it needs a human listening to VoiceOver and NVDA on owner hardware; no gate in this repo can simulate announcement behaviour. What automation covers instead is test:axe across every page at 1440 and 390, and check:forced-colors — see accessibility.

Design-system alignment generated

100% (15/15) — how closely this component follows the design language. Each rule is scored 0-3 against a checkable citation; rules that don't apply leave the denominator. Scored 2026-08-23.