Area: Engagement (audit p9) · Surface: /projects, /projects/following, /projects/{slug} · Dimension: contrast · Severity: major
Every project status pill paints white text on a hardcoded pastel/amber/green background. White on the in_progress amber (#f0ad4e) is 1.95:1 and the complete green (#5cb85c) is 2.48:1 — effectively unreadable, and it violates Law 3 (use semantic tokens, never hardcoded colors). Because the colors are literal hex and not tokens, they also do not adapt to the light, amber, green, p3 or matrix themes — the pill looks identical (and equally unreadable) in all of them. These exact values are duplicated across three templates.
Evidence
platform/templates/projects/index.php:91 `$statusColors = ['concept' => '#888', 'in_progress' => '#f0ad4e', 'complete' => '#5cb85c', 'abandoned' => '#d9534f'];` then index.php:94 renders `<span class="badge" style="background: <?= $statusColors[...] ?? '#888' ?>; color: #fff; ...">`. Same in projects/following.php:37/40 and projects/show.php:23/26. Measured white-on-bg contrast: #f0ad4e=1.95:1, #5cb85c=2.48:1, #888=3.54:1, #d9534f=3.96:1 — all below the 4.5:1 AA threshold for normal text.
Suggested fix. Map each status to a semantic token pair instead of hardcoded hex, e.g. use a CSS class (.badge--status-complete { background: var(--color-success); color: var(--color-on-success); }) or pair the existing tokens with black text (color: #000 / var(--color-text-on-accent)), which the codebase already does for var(--color-success)/var(--color-warning) badges in projects/releases/show.php:20-23 (black on success measures 6.37:1 in light theme). Define the status->token map once and include it.
Filed by the automated tenant-app audit and adversarially evidence-verified. Status: verified. Open — not yet actioned.
Patrick Bass
@mobieus