Open your Figma file right now and click into your primary button component. There's a good chance you'll find a beautiful default state and a polished hover state — and nothing else. No focus state. Nobody designed one, so nobody built one, so keyboard users get whatever the browser feels like giving them.
That's not a rare oversight. It's the default outcome of how most design-to-development handoffs work.
The Accessible Design That Never Shipped
Picture a mid-size SaaS company redesigning its dashboard. The designer does everything right: text meets contrast requirements, headings follow a logical hierarchy, focus states are sketched into the component library. The design review goes smoothly. Everyone signs off.
Three months later, an audit finds the shipped product has almost none of it. Contrast is fine because the color tokens carried through. But there's no visible focus indicator anywhere in the app. Headings jump from H1 to H4 in the middle of the page. Half the images have no alt text at all.
Nobody disagreed with the original design. Nobody even discussed it. The accessible decisions the designer made simply never made it into a ticket, a spec, or anything an engineer would see while writing code. They existed only as pixels — and pixels don't tell an engineer that a heading is supposed to be an <h2>, or that a card's focus order needs to follow reading order instead of DOM order.
Why Figma Doesn't Save You
This is the part teams consistently underestimate: a visual design tool was never built to carry accessibility metadata. Figma shows you what something looks like. It does not tell an engineer:
- Whether a piece of text is an H1, H2, or H3 — visually, a large bold heading and a smaller bold heading just look like two text layers with different font sizes
- What the reading order should be for a non-linear layout, like a card grid or a multi-column form
- What alt text an image should carry, or whether it's decorative and should have none at all
- What ARIA role a custom-built component — a tab panel, an accordion, a combobox — is supposed to expose to assistive technology
None of that is visible in a static mockup. It exists only in the designer's head, and it stays there unless someone deliberately writes it down. Engineers aren't skipping accessibility out of indifference — they're building from a spec that never included it in the first place.
Focus States: The Single Biggest Silent Loss
If there's one thing worth fixing first, it's this: most Figma component libraries show a default state and a hover state, and stop there.
No documented focus state means the browser's default outline decides what keyboard users get. Sometimes that's a serviceable blue ring. More often, it's whatever's left after someone on the engineering team runs a CSS reset, or a later contributor writes outline: none to "clean up" a component and has no design reference telling them a focus indicator was ever intentional.
That's a direct, specific violation waiting to happen: 2.4.7 Focus Visible (Level AA) requires that any keyboard-operable interface have a visible indicator of focus. If your design file never specifies one, you haven't just left a decision open — you've left a Level AA success criterion undefined and hoping for the best.
The fix costs almost nothing at the design stage: draw the focus state next to the default and hover states, every time, for every interactive component. Annotate it. Treat "no documented focus state" the same way you'd treat "no documented error state" — an incomplete spec, not a minor detail.
The Stat: WebAIM's annual WebAIM Million evaluation of the top 1,000,000 home pages has repeatedly found that the vast majority — in recent years around 95–96% — have detectable WCAG 2 failures, with low-contrast text and missing alt text consistently among the most common. Most of these are exactly the kind of gaps that get lost between a design file and a shipped page. (WebAIM: The WebAIM Million)
Annotate What Figma Can't Show
You don't need a new tool or a big process overhaul to close this gap. You need a habit of writing down the things that only exist in the designer's head, in a place engineers will actually see them.
Label heading levels directly in the layer names or annotations. If a text layer is meant to be an H2, say so in the file — don't make an engineer infer document structure from font size.
Write draft alt text as part of the design spec, not as an afterthought engineering fills in later. Even a rough draft ("photo of two people reviewing a wireframe together") is infinitely more useful than a blank the engineer has to guess at under deadline pressure — and it's far better decided by the person who chose the image than by whoever happens to build the component.
Call out reading and tab order explicitly for anything non-obvious. A card grid, a multi-column form, a layout where visual order and DOM order might diverge — all of these need a number or an arrow showing the intended sequence, because "obviously left to right, top to bottom" is often not what the underlying markup will do by default.
Design your components once, accessibly, in the shared library. This is the same design-system discipline we cover in our piece on building accessibility into a design system from day one — an accessible base button or input, with focus states and ARIA notes built in, gets reused correctly by every designer who reaches for it. An accessible one-off, reinvented from scratch in every file, gets reused inconsistently at best.
Build the Checkpoint Into Design Review, Not QA
Here's the part that actually changes outcomes: add an accessibility checklist to the design review step itself, before anything is marked "ready for development."
Do This / Not This: Where the Checklist Belongs
| Stage | Not This (checklist skipped) | Do This (checklist enforced) |
|---|---|---|
| Design review | Contrast, focus states, and headings are assumed "probably fine" | Contrast checked, focus states drawn, headings annotated, alt text drafted — before sign-off |
| Handoff to engineering | Engineer infers structure and states from visuals alone | Spec explicitly states heading levels, ARIA roles, and interactive states |
| QA / testing | Gaps caught after the feature ships to production | Gaps caught in design review, before a single line of code is written |
| Cost of a missed focus state | A bug ticket, a fix, a re-test, a re-deploy | A comment in the design file review |
| Component reuse | Each designer redesigns states inconsistently | One accessible base component, reused correctly everywhere |
A four-item checklist — contrast checked, focus states designed, heading levels annotated, alt text drafted for key images — takes minutes to run at design review. Skipping it doesn't save that time. It just moves the cost downstream, where it shows up as a bug ticket, a scramble to patch a shipped component, and a re-test cycle nobody budgeted for.
This isn't a hypothetical cost. Retail and ecommerce sites are consistently reported among the most-sued industries for web accessibility in UsableNet's annual reports, and UsableNet's tracking has shown several thousand federal ADA website lawsuits filed per year in the U.S. in recent years, with plaintiffs' firms increasingly sending pre-suit demand letters as a first move (UsableNet). A missing focus state or an unlabeled heading is a small thing in a design file review. It's a much bigger thing in a demand letter.
The Real Fix Isn't More Talent — It's a Better Handoff
None of this requires hiring an accessibility specialist for every design review, and it doesn't require engineers to become WCAG experts overnight. It requires the accessible decisions your designers are already making to survive the trip from Figma to production — written down, annotated, and checked before "ready for development" gets stamped on anything.
Over 1 billion people worldwide — roughly 16% of the global population — live with some form of disability (World Health Organization), and in the U.S. that's roughly 1 in 4 adults (CDC). That's not an edge case your handoff process should be dropping by accident.
Get Your Handoff Process Reviewed
If you suspect your team's design files look more accessible than what actually ships — you're probably right, and you're not alone. The gap almost never comes from bad intentions. It comes from a handoff process with no checkpoint built in.
We'll walk through your design-to-development pipeline, show you exactly where accessibility decisions are getting lost between Figma and production, and give you a concrete annotation and review checklist your team can start using immediately. Get your design-to-dev process reviewed for where accessibility is quietly dropping →