Design Systems
Accessibility
Bringing accessibility into a design system, in Figma and in code
When new European rules made WCAG a priority, I led the design side of the accessibility upgrade and implemented the changes in the component library.
Role
Product Designer & UX Engineer
Timeline
Mar 2024 – Jan 2026
Team
2 designers, 2 developers
Tools
Figma
Angular
Jira
WCAG
Problem
Public sites had to meet WCAG
CEMEX’s design system, Figma components plus an Angular library, powers public sites like cemex.com and internal platforms. An accessibility gap in one component shows up everywhere it is used.
In June 2025, ahead of new European accessibility rules, meeting WCAG became a high-priority workstream, with a short time frame and one constraint: keep CEMEX’s visual identity.
An early contrast check on the existing palette.
The strategy
Fix it at the source, in Figma and in code
We fixed accessibility where it starts: in the color tokens, component variants and interaction states that pages inherit from the system.
I worked on both sides, so I could take each fix from Figma into the Angular library and ship it through code review.
Process
Audit, document, rebuild, implement
I led the design side with a support designer, working with 2 developers in Monterrey and Europe.
1. Audit
25+ web and Figma components, checked for contrast, spacing, keyboard navigation and screen readers.
2. Document
40+ findings, categorized and prioritized.
3. Rebuild
Tokens, variants, properties and interaction states, with dev and QA.
4. Implement
New tokens and keyboard navigation, in the library code.
Findings
40+ findings, sorted by impact
A sample of what the audit found. Most issues were color contrast and keyboard access.
Component
What the audit found
Proposed fix
Disabled link button
Text at 1.45:1 (#D6D6D6 on white).
gray50 (#666666): 5.74:1.
Warning badge
White text on #FBB03B: 1.85:1.
Dark text (#333333): 6.84:1.
Saved filter tags
Not reachable with Tab and not announced by screen readers.
Keyboard focus, plus accessible labels and roles.
Tooltip
Opened only with a mouse.
Opens and reads on keyboard focus.
Key decisions
Decision 1
Disabled text stays readable.
Why
A disabled button still has to say what it does. At 1.45:1, people couldn’t read it.
Principle
Information Scent
Evidence
Disabled text moved to gray50 (#666666): 5.74:1, above WCAG AA.
Decision 2
If you can click it, you can reach it with the keyboard.
Why
Saved filters, tags and tooltips worked only with a mouse, so keyboard and screen reader users were left out.
Principle
Interaction Cost
Evidence
I implemented keyboard navigation in the library code.
Iteration
Same brand, readable shades
We started with a contrast exercise over the existing palette. Where a color failed, we adjusted the shade or its background instead of replacing it, so the brand stayed recognizable. Then we applied the new palette and naming conventions to every component.
Before
Before: warning100 (#C47A04) on warning10, 3.14:1.
After
After: a darker warning100 (#6C4609) on white, 8.34:1.
Impact
Key components meet WCAG AA contrast
Measured
4.5:1+
contrast in key components, up from as low as 1.45:1
40+
accessibility findings, documented and prioritized
Qualitative
Presented the findings and progress to CEMEX’s Global UX Lead.
Designed to lower the risk of sanctions under the new European rules and to make components easier to scale. Not measured.
Results describe the audit and the system changes. Adoption and time saved were not measured.
What I learned
1
Most findings were color contrast and keyboard gaps, and both could be fixed in tokens and interaction states.
2
Accessibility review works best as a standard step in every component update, not a one-time audit.
