NDA Notice:
This case study uses abstracted or representative examples to illustrate design approach and decision-making rather than proprietary systems or internal documentation. Public-facing work is shown for illustrative purposes only.
Role
Lead UX Designer
Product
Global Design System
Timeframe
6-month engagement
Team: Product manager, business analyst, engineers, QA, content, marketing partners, UX leads, and external accessibility partners
Tools: Adobe XD, Jira, Confluence, Slack, VoiceOver, TalkBack, internal QA and testing environments, third-party accessibility validation services
When One Market Goes Dark
An international franchise site went offline. Not because of a server failure or a bad deployment, but because it couldn’t meet its government’s digital accessibility requirements.
On the surface, it looked like a regional problem. However, as the picture became clearer, the realization settled in that the core design system components powering that site were the same ones running across every other market. The same carousel that trapped screen readers in an infinite loop. The same modules with missing ARIA labels and failing color contrast. The same structural gaps, just quietly waiting to surface somewhere else.
This wasn’t a regional compliance issue anymore. It was a system-wide risk that had gone unexamined. The franchise had lost web presence and revenue. Users with disabilities couldn’t navigate key content. And the product team had to stop everything else to respond.
When leadership saw the full picture, the response was immediate. Everything else was deprioritized, and I was asked to lead the remediation, and to define what a compliant, scalable design system would look like going forward. Not just for the market that surfaced the problem, but for the entire system.
The Goal:
Evolve the global design system into an accessible, inclusive foundation — meeting WCAG 2.1 AA standards, supporting international compliance requirements, and giving regional teams components they could deploy with confidence.
How I Approached It
My instinct was to get straight into design work, because there was a lot of pressure to move fast. But we didn’t have a clear picture of what was actually broken yet, so I pushed to start with the audit.
Accessibility experts were brought in to provide guidance with auditing the most commonly used modules. The audit surfaced two kinds of problems: things we could fix in one sprint (quick wins – contrast corrections, missing alt text, incomplete ARIA labels), and things that needed to be rebuilt (structural issues – broken keyboard navigation, focus management that confused screen readers, and semantic hierarchies that needed to be rebuilt entirely).
I collaborated with my product manager, business analyst and engineering lead to establish a prioritization framework weighted by severity, frequency of use across global markets, user impact, and implementation complexity — and used it to build the remediation roadmap that sequenced work across the engagement. High-risk, high-traffic modules moved first; everything else was scoped into a longer-term plan. Before any design work began, I defined and documented accessibility and functional requirements for each component, grounded in WCAG 2.1 AA, expert recommendations, and engineering constraints. This helped prevent rework, kept the cross-functional team aligned across sprints, and ensured that compliance wasn’t interpreted differently by design, engineering, and QA.
Doing the Work
Design was iterative and collaborative. I worked alongside engineering daily — sharing prototypes early, resolving implementation questions in real time, and surfacing blockers immediately so they could be addressed in the moment and not just waiting for reviews.
Most modules followed common patterns, defined content boundaries to prevent screen reader traps, improved semantic structure, logical keyboard navigation, and clearer labeling throughout. None of these changes made the experience harder for sighted users. Most made things better for everyone.
The card carousel was one of the hardest to update. Years of feature upgrades had made it one of the most powerful modules in the system, and one of the most complex to work with under the hood. When I brought the audit findings to engineering, the reaction was honest: the codebase was already stretched, and the required changes were extensive — removing infinite scrolling, adding ARIA labels, focus states, progress indicators, proper list structure, landmark regions, touch target sizing, arrow key navigation, and a maximum card count.
Rather than treat the list as an undifferentiated problem, I worked with the engineering lead and our accessibility vendor to sequence the work into three phases: basic accessibility first, full AA compliance second, best-practice enhancements third. Each phase was scoped to two sprints, and I kept myself available throughout — daily standups, direct messaging, office hours — so questions were resolved the same day they surfaced.
After development, every module went through functional QA, CMS integration testing, keyboard-only navigation reviews, automated scans, and manual screen reader testing with NVDA, VoiceOver and TalkBack. Nothing shipped until it passed. Six sprints later, nine new features had been added to the carousel and the module achieved full WCAG AA compliance on schedule.
Beyond the Fix: Building for the Long Term
Remediation was only half the job. The other half was making sure the same problems couldn’t quietly accumulate again.
Once each module was approved, it went back into the design system with updated documentation — usage guidelines, anatomy and behavior descriptions, accessibility requirements, dos and don’ts, and updated design assets. And beyond the documentation, I helped establish an accessibility governance model: regular reviews of core components, validation requirements for new contributions, engineering checkpoints, and a centralized process for reporting issues.
The goal was to make accessibility proactive rather than reactive. Not something you bolt on when a market goes dark, but something built into how the system works.
What It Unlocked
Of the system’s 15–20 modules, I led the remediation of 9 high-priority components — clearing the milestone a month ahead of schedule, which created time for a final compliance review before the international site relaunched. That relaunch restored the franchise’s web presence in that market. The remaining modules were addressed in a subsequent phase, and by the end of the following year, every component in the system had been brought to WCAG 2.1 AA compliance, reducing systemic risk across all global markets served by the design system.
By the end of the engagement, the broader system had a set of remediated core components, updated documentation, an internal accessibility checklist distributed across product teams, and external validation confirming WCAG 2.1 AA-level compliance.
More than the deliverables, though, what shifted was how the team thought about accessibility. It went from being a compliance checkbox (something someone else handles), to a shared responsibility embedded in how everyone worked. By the end, team members were catching accessibility issues themselves before they reached QA. That hadn’t been true at the start.
What I Took From It
Before this project, my accessibility expertise was real but surface-level. But by the end of six months, I was leading reviews, mentoring peers, and advocating for accessibility to be a shared expectation across disciplines, not a specialty siloed to one person.
The clearest lesson this project taught me is that often, making something accessible makes it better in ways that had nothing to do with accessibility. Better semantic structure, clearer content, more logical navigation. Nearly every change we made for compliance made the system measurably better for everyone using it.