Scaling Accessible Design Systems

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.

Where accessibility issues get caught

Reactive audit and remediate after launch

Shift-left review and annotate at design

Earlier, cheaper to fix Later, costlier

• Plan & Design
• Wireframe
• Build
• QA
• Production

Comparison of where accessibility issues are caught. In a reactive process, most are caught late, at QA and in production. With a shift-left process, about 80 percent are caught early, in the plan, design, and wireframe stages, before code is written.

The opportunity

The project was a once-in-a-lifetime chance to bake accessibility into the creation of the design system itself. This combination does not happen. A platform finally mature enough to rebuild on, a formal design system being written from scratch rather than inherited, and an org-wide budget to learn the standard while it was being written. Most accessibility work is retrofitting somebody else’s finished decisions. In design and development, “later” is coded language. It means never. A thing deferred to a phase that has no date, no owner, and no budget line has not been scheduled, it has been declined politely. How do I know? I’ve been doing this for over 15 years. 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.

The cost of fixing a defect by stage

1× 1× $21.25 per issue · ~15 min Cheapest to fix 5× 5× $53.13 per issue · ~1 hour Cheap 15× 15× $318.75 per issue · 3–4 hours Expensive 30× 30× $637.50 per issue · 7–8 hours Most expensive Design & Wireframe Coding & Build Testing & QA Production

Cost of fixing a defect by the stage it is caught

Stage	Relative cost	Cost per issue	Time to resolve
Design & Wireframe	1×	$21.25	~15 min
Coding & Build	5×	$53.13	~1 hour
Testing & QA	15×	$318.75	3–4 hours
Production	30×	$637.50	7–8 hours

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?

The credential behind the training

Deque was our only accessibility vendor, and Hearst enrolled the entire product design and engineering organization in Deque University for a year. That is not a training subscription somebody expenses. It is a budget line and a bet on the whole org learning this together. They ran thorough training and education sessions, helped us wire up Axe Monitor, and held standing weekly-to-biweekly time to answer questions as they came up. The org-wide enrollment ran for that first year. Deque stayed on after it, at a different level of support.

That shaped how I think about this work. The training, the tooling we verified against, and a standing line to people who build both came from the same place, so questions got answered by the people maintaining axe-core and writing the WCAG spec, rather than by a generalist consultancy reading the spec secondhand.

Conformance, not compliance

That asterisk is doing real work. 95%+ is a conformance score: a measurement, taken with Axe Monitor, against criteria the team chose and controlled. It is not a compliance verdict, and the two words get used interchangeably by people selling you something. I am stating this plainly at the top because I want to be very clear: third-party embeds are a genuinely contested space, at the very least it’s not something we can immediately control. Kathryn and I came up with this and noted the delta and filed them in a separate bucket.

No tribunal exists that hears your case, weighs the site, and gives you a pass. There is no health inspector and no letter grade to hang in the restaurant window. No governing body certifies a site as WCAG compliant, nobody issues a certificate, and any badge claiming otherwise was written by whoever is wearing it.

Compliance is a legal question. A regulator or a court answers it, after the fact, about a specific complaint, under whichever law applies to you, in any jurisdiction worldwide, AFAIK. I am not a lawyer. This is not legal advice. Conformance is the part you can measure and show your work on. So the honest claim is the score plus the method that produced it, which is why both are on this page.

The ambiguity is not harmless and it does not stay put. It cascades, from a sales deck to a contract to a status report to a slide with a number on it, and it keeps going until it reaches somebody who knows the difference and calls it what it really is. This asterisk is that, one link earlier in the chain.

TLDR Outcomes (They’re good!)

• ∅zero → 95%+ WCAG 2.1 AA on automated Axe Monitor scans across the 85 core sites, worldwide.
• That timing put the program ahead of the European Accessibility Act’s June 2025 enforcement deadline (Directive (EU) 2019/882). Because the platform already spanned US, European, and Asian sites, hitting 95%+ before EAA enforcement meant EAA readiness came from the same work rather than a separate forced retrofit across the footprint. WCAG is probably the standard these laws keep pointing back to, wherever they are written, and we were learning it from the people who help write it.
• Another 35 properties audited for accessibility issues across the wider footprint: affiliated sites, shops, feature pages, and vignettes. 120 in all, counting the 85 core sites.
• Review moved to design and wireframe, so issues were caught before code rather than remediated after launch.
• 300+ attendees across 20+ workshops and office hours; practices held up with no per-brand rework as the portfolio scaled toward 60 brands across 85 core sites worldwide.
• Accessibility became everyone’s job, embedded throughout the lifecycle rather than siloed, and co-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”, “two-thirds of issues originate in design” and “up to 80% caught before code” figures referenced on this page are industry data (Deque / U.S. Bank), cited as the rationale for shifting left. None of them are measured results from this program. The 95%+ score is an Axe Monitor score against criteria the team controlled: a self-assessed conformance metric, not a certified “compliance” grade. No governing body issues a WCAG certificate.

Constraints

The program had to work within real boundaries:

• Scale without rework. A portfolio growing from two dozen US properties toward 60 brands across 85 core sites 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.

Accessibility, owned at every stage

1. Product Definition of done in the plan Awareness needed. Owns it either way.
   • Budget the check into the estimate
   • Treat it as a requirement, not an ask
   • Count the SEO and reach upside
2. Design Definition of done at handoff Working knowledge needed. Owns it either way.
   • Annotate focus order and semantics
   • Mark up headings and landmarks
   • Check contrast and target sizes
   • Accessible design is inherently usable
   • Meet WCAG 2.1 AA
3. Development Definition of done in code Working knowledge needed. Owns it either way.
   • Build from accessible components
   • Honor keyboard and ARIA contracts
   • Meet WCAG 2.1 AA
4. QA Definition of done before launch Specialist tooling needed. Owns it either way.
   • Run axe and WAVE scans
   • Test with VoiceOver and NVDA
   • Verify keyboard-only flows
   • Meet WCAG 2.1 AA

Shifting left isn’t a single intervention, it’s a chain of small mechanical changes, each one moving a checkpoint one stage earlier than where the industry defaults to catching it:

• At requirements: accessibility criteria written into the product brief, not appended after design review.
• At wireframe: annotations and markup requirements (heading structure, focus order, landmark regions) added before a designer hands off to engineering, not discovered by engineering after the fact.
• At component build: accessibility built into the shared library once, in Storybook, so every team consuming a component inherits correct behavior rather than re-solving it.
• At CI: axe-core wired into the pipeline so a regression fails a build automatically instead of shipping and waiting for a manual audit to catch it.
• At production: scheduled Axe Monitor scans as the outer backstop, catching what earlier stages missed.

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.

SEO and accessibility were argued as one problem, not two. This is the part of the pitch I would keep if I could only keep one. Both disciplines are asking the same question of the same artifact: is this document structured so a machine that cannot see it can still understand it. Heading hierarchy, landmark regions, semantic elements over generic containers, meaningful link text, real alt attributes. A screen reader and a crawler want the identical thing for identical reasons.

Treating them as two workstreams meant two backlogs, two sets of requirements, and two teams occasionally undoing each other’s markup. Treating them as one meant the SEO budget and the accessibility budget were arguing for the same fix, which is a very different conversation to have with a product owner. In the original proposal it is written down as a goal in its own right: synchronize the SEO and accessibility approach to semantic HTML.

4. Checklists & Working Agreements for Every Role

• Design checklist: annotation and markup requirements for new templates during handoff: heading hierarchy, landmark regions, focus order, and color-contrast checks, verified before a file leaves design review.
• Developer checklist: coding standards for accessible components: semantic HTML first, ARIA only where semantic HTML can’t express the pattern, keyboard operability and visible focus states verified before merge.
• QA checklist: testing scripts and tools for automated accessibility checks, plus scheduled manual passes with a screen reader for the interaction patterns automated scanners can’t evaluate (reading order, meaningful alt text, focus management in dynamic UI).

Each checklist was scoped to what that role could actually verify at their stage. The point was distributed, ownable checkpoints, not one master list everyone was expected to interpret for their own discipline.

5. Analytics, Reporting, and Bug Fixes

• Reviewed and tweaked automated scans using Axe Monitor (Deque), scripting manual checks using WAVE, and Figma plugins to test conformance against WCAG.
• Gathered weekly automated scans on production and triaged findings.
• Reviewed and prioritized a Kanban backlog of reported issues.

6. Documentation and Workflow Improvements

• Documented accessibility initiatives within the design team for consistency across projects.
• Standardized Figma accessibility documentation templates, toolkits, and plugins.
• Built handoff workflows with detailed accessibility documentation for developers and QA.
• Integrated accessibility and functionality checks in anticipation of Storybook integration.

7. Ongoing Support and Advocacy

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

Sustaining conformance, not just achieving it once

A score is a snapshot. The harder problem was keeping the 85 core sites above the same bar as new templates, new components, and new hires kept arriving. Three mechanics did the sustaining work, each catching a different failure mode:

• Component defaults, not per-project vigilance. If the shared library’s button, form field, and modal patterns were accessible by construction, a team building a new page inherited that for free instead of re-deciding it every time. This is why the checklist called out “semantic HTML first” as a developer default rather than a one-time review item. It removes the decision entirely for the common cases.
• CI as the regression backstop. axe-core in the pipeline meant a new component or a refactor that broke an ARIA attribute or a focus trap failed the build immediately, not three sprints later during the next production scan.
• The recurring scan as ground truth. Weekly Axe Monitor scans across the 85 core sites existed precisely because component defaults and CI checks don’t catch everything. Content-level issues, third-party embeds, and drift that creeps in outside the component library still needed a wide net. That weekly cadence, not a one-time audit, is what let the score hold at 95%+ rather than decaying after the initial push.

None of these alone would have held the line. It took the combination: cheap defaults for the common case, an automated gate for regressions, and a recurring wide-net check for whatever slipped past both.

Key decisions

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

My specific contributions

As design lead on the program, 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.
• Co-founded the Accessible@Hearst ERG to promote inclusivity across teams.

Tools and standards

The program standardized on a small, repeatable toolkit:

• WCAG 2.1 AA: the conformance target org-wide, from product requirements through production, and across art and editorial as well as engineering.
• axe-core and WAVE: automated production and CI scanning.
• Axe Monitor: Deque’s premium monitoring service, the source of the 95%+ score across the 85 core sites, a separate product from axe-core, which handled CI-time 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, written by and referencing WCAG. The source is the spec itself, from the people who contribute to it, rather than a secondhand reading of it.

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.
5. Design conformance to be sustained, not achieved once. Component defaults, CI gates, and recurring scans each catch a different failure mode; none of them alone holds the line.

The line the whole thing rested on

Accessibility is everyone’s job.*

* We will all be experts.

The asterisk is not a hedge. “Everyone’s job” on its own is the sentence that gets accessibility ignored, because a responsibility with no owner is a responsibility nobody has. The footnote is what makes it work: not everyone does the same task, everyone becomes competent at their own part of it. Product writes the criteria into the requirement, planning budgets the work instead of discovering it, the designer annotates the reading order and writes semantic markup, the developer double-checks and writes the semantic markup into code, QA runs the screen reader pass, the editor writes the alt text. Distributed expertise, not distributed blame.

Everything else in the program was machinery for producing that. The training, the checklists, the bootcamps, the office hours, the shared channel: all of it exists so the sentence stops being a slogan.

Scope of ownership

Design lead on the accessibility program that design leadership initiated; led Deque University training and custom onboarding; built the accessible design-to-dev handoff (annotations, markup, peer review); authored role-specific checklists; set up automated scanning and triage; and co-founded the Accessible@Hearst ERG.

Credit

Team

• Cybele Grandjean (VP Product Design for Content Experience)
• Kathryn Thomas (Senior Director, Program Lead for Product Testing and Accessibility)
• Tracey O’Connor (Staff Product Designer)
• Ryan Ilano (Staff Product Designer, Design Lead for the Accessibility Program)

It was shared in more ways than a credit line holds, and I cannot state it cleanly. Editorial were trusted to make their own decisions, and to make the changes to process we asked for. Kathryn and I watched those changes actually get made. That is a different thing from compliance with a mandate, and it is the part that does not fit in a list of names.

Cybele started this

The program starts earlier than this page opens. Cybele set up much of the accessibility initiative and the push toward shifting left in 2021, as VP Product Design for Content Experience. As I understand it, it covered much of the resources I needed and the tooling available. This page opens in 2022 because 2022 is when the platform was ready to build on. The argument for doing it at all was made a year earlier.

The upper levels of design prioritized accessibility and set up the foundation, which is what let all of it happen. She set it up for me to make it happen, and handed me a starting point good enough to build the whole thing on. The scope of ownership above exists because that groundwork was already there.

Kathryn’s diligence

Kathryn Thomas, Senior Director and Program Lead for Product Testing and Accessibility, is the other half of why it held. Shifting left only works if the stage you shift toward is already rigorous, and QA and accessibility sitting under one director is what made design-stage review land as process rather than as a request.

I could not own that, and I am not going to claim it. What I did was help her decide what to scan, why a given result was wrong, and how to fix it. Axe Monitor reporting the same third-party embed on every scan is not a finding, it is noise sitting on top of the findings. I helped her separate the two so the scan output was worth reading.

The harder half was hers. She chased ownership across locales, countries, and Hearst buckets, which is the work of finding out who actually controls a thing before anyone can fix it.