Design Systems at Meta
Accessibility as a property of the system
Turning accessibility from a product afterthought into a built-in property of how Facebook's design system ships, across five years, 400+ components, and a global user base of billions.
When I joined the accessibility team, Facebook's design system, the foundation thousands of designers and engineers build on, had a weak accessibility foundation. This left product teams to solve most of the accessibility work (WCAG AA) on their own, producing uneven experiences for people who rely on assistive technology at the scale of billions. I led the multi-year effort to close that gap by fixing accessibility once, in the components and primitives everyone already used, rather than endlessly product by product.
Impact at a glance
Raised accessibility compliance from a small minority of the library to the overwhelming majority of components, across every framework.
Made accessibility a launch requirement in the system's definition of done, and leveraged component adoption goals to scale that impact across the app.
Shipped accessibility changes to the production app that also increased core engagement metrics.
Trained the design system's own designers to own accessibility, moving myself out of the critical path.
The arc
Four phases took this from an idea to an owned practice: identify the gap, operationalize it, drive the numbers, then institutionalize it. I started by creating an accessibility source of truth for the component library, built the process and leadership mandate that made it routine, drove compliance and proved the business case, and finally made it durable enough to run without me.
Five years, on a timeline
Select a year to see what shipped and which phase of the arc it belonged to.
2020 · Found the gap
Discovered that the core component library had no accessibility spec, and initiated the first source of truth for how components should behave when used with a screen reader.
2021 · Built the model
Established the accessibility partnership model with the design-system teams, and shipped the first accessible components alongside reusable design guides.
2022 · Made it a requirement
Carried the model into the next-generation design system and earned leadership backing to make accessibility a launch requirement, not an afterthought. Expanded accessibility focus to cover all WCAG AA requirements.
2023 · Moved the numbers
Compliance climbed from a small minority toward the majority of components, and the first app-wide accessibility solutions shipped, several of which also increased engagement.
2024 · Scaled the ownership
Pushed compliance to the overwhelming majority across frameworks and began transferring day-to-day ownership to the system's own designers.
2025 · Made it permanent
Reached readiness ahead of the European Accessibility Act, authored the continuous-compliance plan, co-built a company-wide maturity framework, and reframed accessibility as a growth lever.
01Earning leadership buy-in
For years, accessibility lived at the end of the process, a best-effort pass after the real decisions were made, and the first thing cut when timelines tightened. The opportunity was to move it from optional to mandatory. I worked to secure leadership backing to make accessibility a requirement for component launch, writing it into the definition of done so it couldn't be skipped. Later I made the case in leadership's own language of product performance, showing that accessibility improvements also benefited the broader product, which shifted the conversation from "accessibility as compliance" to "accessibility as a growth lever."
ImpactAccessibility became a required, leadership-backed step in shipping any component, and the organization's narrative around it shifted from cost to investment.
How I actually built that case, the specific data, the rooms, the objections I handled, is walked through live in an interview.
02Building a process teams could own
Fixing a set of components is finite work; keeping a living, constantly-growing system accessible is not. The opportunity was to make accessibility a routine the teams could run themselves, rather than a gate I personally manned. I built a repeatable loop (spec, review, annotate, hand off, dogfood) and embedded it into the design-system and product teams' existing workflows instead of bolting on a separate review. I documented the standard so a designer facing an accessibility decision had an answer without having to find me.
ImpactAccessibility moved from one-off quality fixes to a standing step in how components are designed, reviewed, and shipped, now repeatable across teams and no longer dependent on me. Cross-functional partners on the design system started to become accessibility advocates for the system and across Facebook.
03Accessibility as a growth lever
Accessibility's biggest enemy wasn't disagreement. It was the quiet assumption that it's a cost center: worth doing, but not the highest priority. The opportunity was to disprove that with product data. Several accessibility changes shipped to the production app increased core metrics rather than trading against them: content protection on video, more legible interactive text, and higher-contrast components. I packaged these into recurring "impact of accessibility" reports that showed, example by example, that designing for people with disabilities made the product measurably better for everyone.
ImpactAccessibility was reframed company-wide from a compliance program into a measurable growth lever, with senior leadership amplifying the case.
The specific metrics live in my interview deck.
04Scaling myself out
The opportunity here was also the risk: on a system far too large for one person, I could easily have become the single point of failure for accessibility. The senior move was to make myself unnecessary. I trained the design system's own designers to own accessibility, mentored designers across the company, and deliberately transitioned issue ownership from my team to the product and system teams, moving from owning the work to supporting it. To scale past a single system, I co-built an accessibility maturity framework in partnership with central teams that let cross-company design systems assess and improve on their own.
ImpactThe system's own designers could deliver accessible components confidently without me in the loop, and the practice extended to design systems across the company.
Reflection
Five years on one problem, at this scale, seems like a lot. And it was. It changed how I think about building products.
Three lessons stuck. At this scale, quality is won or lost in the system, not the screen, so the only fixes that hold are the ones you push upstream, into the components and the definition of done. A quality investment only survives when it's framed in the language the business already uses: don't ask the company to value what you value; show how it advances what they already measure. And the most senior thing I did was make myself unnecessary, handing the work to the people and frameworks that could carry it without me.
If I had to compress it to one principle for building at this size: invest in what produces the outcomes, not the outcomes themselves. The component quality and the metrics were the visible results. The real work was leaving behind a design system, and a team to carry it, that treat accessibility as their own. And the part I'm proudest of is what our investment produced: an app used by billions, and the design system beneath it, that is meaningfully more accessible for the people of all abilities.