Building an Accessibility Program — Quantive

Overview

When I joined Quantive, accessibility wasn’t part of the product’s DNA. There were no guidelines, no workflows, and most importantly no ownership. As a Senior Product Designer and later Design Lead, I made it my mission to change that.

Over the next year, I built a company-wide accessibility program from scratch—driving awareness, creating infrastructure, upskilling cross-functional teams, and integrating inclusive practices directly into the design and development lifecycle. We didn’t just aim to meet WCAG compliance; we created a culture shift.

Company

Quantive

The challenge

Quantive’s users include global enterprise teams, many of whom require accessible tools. But our product had critical gaps: poor screen reader support, weak keyboard navigation, and inconsistent design patterns. These issues caused friction, user complaints, and reputational risk especially from high-profile clients like Adobe and Nike.

But the real challenge? Accessibility wasn’t anyone’s responsibility, until I made it mine.

The Vision

My goal was ambitious: build an accessibility practice that would:

• Meet compliance standards (WCAG 2.1 and 2.2)

• Improve core user flows (“Create Objective,” “Create Key Result,” “Update Key Result”)

• Empower every designer, developer, and PM to make accessibility an organic part of their workflow

• Shift the mindset from “checklist” to “culture”

What I Did

🔍 Audited the current experience

Used automated tools + manual testing to assess accessibility gaps across our core flows. Collaborated with support teams and real users to surface the highest-impact issues.

📚 Created accessibility guidelines

Built a cross-referenced accessibility framework tailored to Quantive’s workflows, referencing WCAG, EN 301 549, and Section 508. Published it company-wide to serve as the foundation for design, dev, and QA.

🧠 Trained the teams

Led 12+ seminars and 7 deep-dive workshops in the first 3 months. Designed 1:1 coaching sessions to help designers and developers become accessibility champions.

🧩 Integrated into product development

Introduced annotated accessibility specs in Figma, created dev handoff templates, and built a component library that enforced contrast, focus states, keyboard behavior, and semantic HTML.

🧪 Partnered on testing and rollout

Ran continuous audits, facilitated assistive tech testing, and supported cross-team QA efforts. Co-led the migration of legacy Angular modules with accessibility built in from the ground up.

🤝 Built a culture of collaboration

Founded an internal accessibility guild, built shared rituals, and facilitated working sessions across teams. Created the company’s first Accessibility Statement and VPAT.

The Impact

✅ 64% increase in WCAG compliance in the first 8 months

✅ 31% improvement in screen reader & keyboard support

✅ 50% reduction in contrast-related issues

✅ Positive client feedback from enterprise accounts

✅ Cleaner codebases and fewer UI-related bugs

✅ Full accessibility coverage of main user flows within the first 6 months

✅ Reduced support tickets from accessibility complaints

✅ Ongoing feature development now starts with accessibility in mind

Lessons Learned

• Accessibility is a team sport. It only works when everyone’s bought in—and that starts with education.

• Legacy code is a real barrier. Accessibility isn’t just a design task—it needs dev partnerships and realistic planning.

• Checklists don’t create great experiences. Real inclusion requires empathy, iteration, and leadership.

Why It Matters

I built the program because everyone deserves access to great digital experiences. It’s not just about legal compliance. It’s about dignity, autonomy, and giving people the tools they need to thrive.