A designer finds an accessibility issue. They write a ticket. It goes to the backlog. And it gets buried. This quarter, next quarter, same story. One case Figma recently shared flipped that familiar ending — a designer went straight into the code, created a branch, fixed it, and submitted a PR. In a day, no less.
Why Is That Fix Still in the Backlog?
Accessibility issues usually look trivial. A low-contrast date picker, a button screen readers can't read, vague nav labels. But here's the thing: it's not that "it's too small to fix" — it's that "no one has time to touch it." WebAIM's February 2026 survey found 95.9% of major homepages failed WCAG standards, with an average of 56.1 errors per page — up 10.1% from last year. The first time in six years the numbers got worse.
Why do these tiny fixes get stuck forever? It's the structural ceiling of ticket-based workflows. When a designer says "can we improve contrast on this screen," an engineer sees just that one screen. But in reality, that date picker is often a shared component used on the checkout page, the event page, and the settings page. Fix one place, leave the other two broken — and only someone who's actually read the code knows that's the case.
Accessibility debt doesn't just sit there — it accrues interest. As unreachable components spread across more screens, context gets lost when people rotate out, slowing repairs and raising risk. More users hit the same barrier. One analysis shows that fixing a bug left in backlog costs $2,480 more than catching it during development. Turns out leaving it alone is more expensive.
How Figma Experimented — The MOSF Case
The case Figma highlighted is a fictional museum site, 'Museum of Speculative Futures (MOSF).' Figma's agent tested the site as a first-time visitor, a member, and a screen reader user — synthetic personas — and surfaced problems: vague nav labels, low-contrast date picker, a hard-to-spot CTA button.
Standard QA report so far. Then came the twist. The designer connected the GitHub repo to Figma Make, created a new branch from the live site code. Then they spotted it at the code level — that date picker was a shared component used across three pages. Instead of patching one screen, they fixed the component itself, once and for all.
| Traditional Ticket Workflow | Figma Make PR Workflow | |
|---|---|---|
| Scope discovery | Only screen-by-screen visibility | Finds shared components at code level |
| Time to deploy | Quarters stuck in backlog | Live within a day |
| Accessibility specs | Explained in ticket text, often incomplete | aria-label & focus order documented directly in PR |
| Change record | Tickets and code split, context lost | One PR holds intent, review, and decision |
What stands out is the comments attached during team review. As the designer handed off their work, they set aria-labels, made screen reader text match visual text, fixed focus order so the CTA was reachable, and added screen reader guidance for empty states. All of it lived in code comments.
Then came the PR. The designer pushed straight to GitHub from Make, and the engineer approved and merged. To borrow Figma's words: "a PR becomes a record not just of what changed, but how." What would normally have burned a quarter of backlog time shipped in a day.
Why This Works Now
This workflow didn't appear from nowhere. Figma formalized the direction at Config 2026 in June by unveiling 'Code Layers' — "code as a design material like any other." You can flip a design layer into an interactive code layer with a click or prompt, pull an existing GitHub repo into Figma Design, and sync design and Git code both ways. Figma Make itself, released late May, lets designers visually edit real production code, create branches, and open PRs — all without leaving the canvas.
But this isn't "designers become engineers now." Figma itself frames it as designers accessing code without becoming engineers, and engineers staying engineers. Big architecture rewrites stay the engineer's job; designers own refinement within existing components. Not auto-merging PRs — requiring engineer sign-off — reflects the same principle.
If We Tried This on Our Team
- Scan the backlog first
Find accessibility tickets stuck for multiple quarters that "look screen-sized but might be shared components." Those are ideal first experiments. - Sort out repository access first
Before designers can create GitHub branches, lock in access permissions, branch protection rules, and approval lines with your team. The tool won't work without permissions in place. - Draw the line between designer and engineer work upfront
Architecture changes beyond component reuse are engineering; refinement like styles, labels, focus order is design — document this boundary before launching the workflow. - Make accessibility comments a PR checklist standard
aria-label, screen reader text alignment, focus order, empty state guidance — put these four in your PR template and reviews speed up. - Validate with a small case first
Before full rollout, run one accessibility fix all the way through to production like MOSF did, measure time and review load, then scale up.
Go Deeper
Workflow Lab: Deploying Designs Directly with Figma Make The original case behind this post, straight from Figma's blog. You'll see the full MOSF process. figma.com
Accessibility Debt: How to Measure It and Pay It Down A deep dive on why accessibility debt compounds and how to cost it. testparty.ai
Web Accessibility Statistics 2026 Annual report with WCAG fail rates, error types per page, and U.S. lawsuit stats. digitalapplied.com
Figma Launches Code Layers & Motion at Config 2026 How Code Layers — the foundation for Make — was announced. cmswire.com
figma/actions-create-pull-request The GitHub Action repo Figma's team actually uses to auto-generate PRs. Dive here if you're curious about the mechanics. github.com
Building a Usable Real Design System Hwahae's domestic case study on cleaning up legacy component debt into a design system. blog.hwahae.co.kr
