Scaling Accessible Design Systems

The challenges

Accessibility is often treated as an afterthought in the product development cycle, leading to costly fixes and frustrating user experiences. Given this rare opportunity of a relatively clean slate, what’s the best way to bake accessibility into a brand-new design system?

Challenges:

• Accessibility fixes were being addressed late in the process, increasing cost and delay.
• Teams lacked a unified understanding of accessibility standards and their roles in achieving them.
• Most accessibility issues could have been caught during wireframing but were overlooked due to insufficient planning.
• There was no standardized workflow for integrating accessibility into the product lifecycle.

The question became: how do we make accessibility everyone’s responsibility?

Constraints

The program had to work within real boundaries:

• Scale without rework. A portfolio growing from two dozen US properties toward 90+ brands worldwide meant every practice had to scale, not be hand-tuned per brand.
• No editorial friction. Accessibility couldn’t slow daily publishing or add steps to existing design-to-dev handoffs.
• Cross-team buy-in. A11y had to be owned across design, engineering, QA, and editorial; it couldn’t live in a silo.
• A moving foundation. The work had to layer onto MediaOS while the new platform itself was still being built.

The Opportunity

The project was a chance to bake accessibility into the creation of the design system itself. When accessibility is a normal part of product requirements, wireframing, design handoffs, and development, the foundational building blocks are well engineered and documented from the start.

By standardizing accessible practices for components and modules, from product requirements through launch, we made future development easier while shifting the focus from reactive remediation to proactive, inherently accessible design.

Shifting accessibility left

I ran a multi-faceted program spanning training, process, tooling, and advocacy, beginning with the design team and expanding to product, engineering, QA, and editorial. The throughline was shifting accessibility left: catching issues during wireframing and design review rather than after launch, and standardizing accessible components so the building blocks were inclusive by default.

1. Training and Education

• Enrolled the organization in Deque University for org-wide training on assistive technologies and accessibility best practices.
• Ran custom onboarding presentations every four to six months for new hires across design, development, and editorial.
• Worked to make accessibility an easier idea to grasp by meeting people where they were.

2. Auditing Legacy Components

• Inventoried existing components and patterns to find where accessibility was breaking down.
• Used those audits to prioritize what to fix first as we rebuilt on the new system.

3. Building Buy-In Across Teams

• Advocated at every level by highlighting both risk (legal compliance) and benefit (better experiences).
• Took a “carrot” approach: accessible components are easier to work with and maintain, score better with SEO, and make a better product.
• Introduced assistive technologies like screen readers in workshops to build empathy and understanding of user needs.

4. Checklists & Working Agreements for Every Role

• Design checklist: annotation and markup requirements for new templates during handoff.
• Developer checklist: coding standards for accessible components.
• QA checklist: testing scripts and tools for automated accessibility checks.

5. Analytics, Reporting, and Bug Fixes

• Set up automated scans using axe (Deque), WAVE, and Figma plugins to test compliance against WCAG.
• Gathered weekly automated scans on production and triaged findings.
• Created and prioritized a Kanban backlog of reported issues.

6. Documentation and Workflow Improvements

• Documented accessibility initiatives within the design team for consistency across projects.
• Built handoff workflows with detailed accessibility documentation for developers and QA.
• Integrated accessibility and functionality checks into Storybook.

7. Ongoing Support and Advocacy

• Held weekly office hours for help with accessibility challenges.
• Founded Accessible@Hearst, an employee resource group fostering a culture of inclusivity.
• Regularly reviewed Hearst-affiliated sites to identify areas for improvement.

Key Decisions

Three choices shaped the program, each as much about what we chose not to do.

Shift accessibility left into wireframing and design review. Roughly two-thirds of accessibility issues that reach production originate in the design and wireframe stage. Introducing annotations, markup requirements, and peer review at handoff let us catch up to 80% of issues before a line of code was written, where fixes are cheapest. Instead of auditing and remediating after launch (the costly status quo) or relying solely on automated CI scans, which catch only a fraction of real issues.

Make accessibility everyone’s responsibility with role-specific checklists. Tailored checklists for design, development, and QA gave each role a concrete, ownable definition of done, so a11y was never bottlenecked on a single specialist and stayed sustainable as the team grew. Instead of centralizing accessibility with one person (a bottleneck that doesn’t scale) or leaving standards informal and untrainable.

Build accessible components into the design system as the default. Engineering accessibility into the shared component library and documenting it in Storybook meant every product inherited accessible building blocks for free. Instead of documenting standards but leaving implementation to each team, which invites drift and duplication.

My Specific Contributions

As the accessibility advocate on this project, I:

• Led training via Deque University and created custom onboarding presentations every few months.
• Integrated accessibility into the design handoff process by requiring standardized annotations, markup, and peer reviews for all new templates.
• Documented new initiatives within the design team to align with WCAG standards.
• Built workflows with detailed documentation for developers and QA.
• Demonstrated automated tools like axe-core and guided teams through assistive technologies such as screen readers.
• Hosted weekly office hours for ongoing accessibility support.
• Founded the Accessible@Hearst ERG to promote inclusivity across teams.

Tools & Standards

The program standardized on a small, repeatable toolkit:

• WCAG 2.1 AA: the conformance target across components.
• axe (Deque) / axe-core and WAVE: automated production and CI scanning.
• Figma accessibility plugins: catching contrast and structure issues in design.
• Storybook: documenting accessible component behavior and states.
• Screen readers (VoiceOver, NVDA): manual testing and empathy-building in workshops.
• Deque University: org-wide training and onboarding.

Outcomes

• 0% → 95%+ WCAG 2.1 AA on automated axe-monitor scans across 120 sites, achieved in under 2.5 years.
• 120+ brands and properties audited for accessibility issues.
• Up to 80% of issues caught early (design/wireframe), before any code.
• 300+ attendees across 20+ workshops and office hours; practices held up with no per-brand rework as the portfolio scaled toward 90+ brands worldwide.
• Accessibility became everyone’s job — embedded throughout the lifecycle rather than siloed — and founding Accessible@Hearst reinforced a company-wide commitment to inclusivity.

By prioritizing accessibility from planning through production, we didn’t just improve Hearst’s platform; we demonstrated how inclusive design benefits everyone: users, teams, and the business alike.

Note: the “30× cost-of-defect” and “two-thirds of issues originate in design” figures referenced above are industry data (Deque / U.S. Bank) — context for the shift-left rationale, not personal results.

Key Takeaways

1. Shift accessibility left. Embedding it early in the lifecycle reduces cost and improves outcomes for every user.
2. Advocate across teams. Buy-in comes from education, demonstrating ROI, and building empathy, not mandates.
3. Standardize practices. Checklists, documentation, and workflows keep accessible practices consistent across roles.
4. Foster a culture of inclusivity. Initiatives like an ERG sustain momentum beyond any single project.

Please reach out for more details on this project. I’m happy to share more about the design process, challenges, and outcomes in a conversation.