Accessible by Default
Client brand colors don’t always meet accessibility standards. We were shipping them anyway. I designed a color system that made the right choice the easy choice, and documented it so the team could use it without me.
- My role
- Lead UX/UI designer
- Type
- Design system, internal tooling
- Users
- Internal implementation team
- Deliverable
- Color System v1.2, Aug 2023
Outcomes
The problem
Colors were shipping without any checks
When a new client project started, their brand colors went straight into the system. Whatever hex codes came out of their brand guide. Nobody was checking contrast ratios. Nobody was validating against WCAG. We were trusting that whoever designed the client’s brand had done that work.
They hadn’t. Client brands are designed for print, for marketing sites, for billboards. Not for an enrollment platform where an employee is reading fine print about their health plan. The colors looked on-brand. They just weren’t readable.
The people using these sites aren’t casually browsing. They’re making real decisions about their health coverage and their family’s benefits. An inaccessible color scheme isn’t a minor issue. It’s a barrier to someone understanding their own plan.
The system
Four color roles, built for safe placement
Rather than just fixing colors on a case-by-case basis, I designed a structured color system with defined roles. Every component in the platform draws from one of four colors, each adjusted in tone and chroma to ensure accessible placement by default. The implementation team picks a role, the system handles the rest.
Out of the box, the four roles loaded with Optavise’s own brand colors as the defaults. Each client could then customize those roles inside their account settings, swapping in their own brand palette while the system kept the accessible relationships intact.
Each role maps to component styles (Bright, Card, Dull, Invert) that work across both light and dark mode. The team can mix and match within a style, but the system keeps the combinations safe. You can’t accidentally put light text on a light background if you stay within the defined options.
The guardrail
Override is allowed, but you can't do it blindly
The hardest design decision was what to do when the team wanted to use the client’s original colors exactly as provided. Blocking it completely would create friction and pushback. Allowing it silently would defeat the entire purpose.
The solution: a “Use original color” toggle that anyone can turn on. But the moment they do, the system surfaces a warning. Not a blocker. A warning.
“By using this option you understand that users with eye impairments will possibly be affected and that we have broken WCAG compliance.”
That language is deliberate. It puts the decision back on the person making it, makes the consequence explicit, and creates an accountability moment without removing control. The team can still proceed. They just can’t do it without knowing what they’re choosing.
The documentation
A system is only useful if people can use it
Building the color system was one thing. Making sure the internal team could actually use it, without needing to ask me, was the other half of the job. I wrote and designed a 13-page reference document covering every concept, setting, and edge case.
The v1.2 version number matters. This wasn’t a one-and-done doc. It went through a revision cycle based on real feedback from the team using it. That’s what makes it a living reference rather than a file that got created and forgotten.
Learnings