Back to blog
EngineeringJun 24, 2026· min read

We Fixed Every WCAG Contrast Failure on strugcity.com

A TDD audit caught contrast ratio violations across our marketing site. Here's what we found, what we fixed, and how automated testing keeps accessibility from regressing.

We run accessibility audits on every pull request. On June 24, 2026, our WCAG contrast checker flagged multiple violations across strugcity.com—text that looked fine to sighted reviewers but failed the 4.5:1 minimum contrast ratio required by WCAG AA standards.

This wasn't a design oversight. It was technical drift. As we shipped features, some components pulled colors from our Aurora design system correctly, while others used hardcoded values or insufficient color pairings. The result: inconsistent contrast across pages.

What We Fixed

The audit identified contrast failures in eight locations:

• Blog page: Body text and metadata labels had insufficient contrast against dark backgrounds

• Products page: Section headers and card descriptions fell below 4.5:1

• Stream page: Timestamp labels and entry metadata were too faint

• ArchitectureRow, ClosingCTASection, EmphasisSection, HighlightSection, HowItWorksSection: Five shared components used color pairings that passed visual review but failed programmatic checks

We also updated globals.css to enforce accessible defaults for base typography.

How the Audit Works

The fix was enforced by __tests__/blog-page.audit.test.tsx, a Jest test that parses rendered output and calculates contrast ratios for all text/background pairs. If any pairing falls below WCAG AA thresholds, the test fails and blocks the pull request.

This isn't a linter. It's a runtime check. We render the component tree, extract computed styles, and verify contrast programmatically. That means regressions can't slip through—if a future commit introduces a color change that breaks accessibility, CI catches it before merge.

Why This Matters

WCAG AA compliance isn't just a legal requirement. It's a product quality bar. Users with low vision, color blindness, or screen glare shouldn't have to squint at our marketing copy. Accessible design is inclusive design, and inclusive design expands our addressable audience.

More pragmatically: automated enforcement means accessibility doesn't depend on manual review. Engineers don't need to memorize contrast ratios or run browser extensions. The test suite handles it.

What's Next

This audit covered contrast. We're expanding coverage to other WCAG criteria:

• Keyboard navigation: Ensuring all interactive elements are reachable without a mouse

• Screen reader compatibility: Testing ARIA labels and semantic HTML structure

• Focus indicators: Verifying visible focus states on all form inputs and buttons

We're also migrating more components to Aurora design tokens. Hardcoded colors are the root cause of most accessibility drift. Semantic tokens—where colors are defined by purpose (text-primary, surface-elevated) rather than value (#1a1a1a)—make it easier to maintain accessible pairings system-wide.

Every page on strugcity.com now passes WCAG AA contrast requirements. The tests that caught these failures are running on every commit. Accessibility is no longer a post-launch audit—it's a build-time requirement.