Picture the handoff moment. The Figma file is polished, the components are named cleanly, the prototype flows without a hitch. It gets shipped to engineering with a tidy little note: "ready for build."
Then the build actually starts, and someone on the engineering side asks a question the file never answered. What does this button look like when it's focused with a keyboard? What order should a screen reader move through this card grid? Is there enough space between these two tap targets on mobile? Nobody knows, because nothing in the file was built to answer those questions. The design is beautiful. It is also, in places, a guess.
This is the moment most accessibility bugs are born, not in the code, but in the silence of a design file that never specified what "accessible" would even look like.
The Stat: WCAG 1.4.3 (Contrast Minimum) requires a 4.5:1 ratio for normal text, a number a designer can check inside Figma before a single line of code is written, not after. (Source: W3C WCAG 2.2)
Why "it looks fine" isn't the same as "it works"
A Figma file can look flawless and still be missing half the information a developer needs to build something accessible. Color, spacing, and type are all visible on the canvas. Focus order, semantic structure, and interaction states usually are not, unless someone deliberately puts them there.
That gap is exactly where accessibility bugs get born. Not from bad intentions, but from a handoff document that only shows the happy, static, mouse-driven version of the interface.
The good news: none of the fixes below require a new tool stack, a redesign, or weeks of extra time. They're checks you can run on a single file in an afternoon, before it ever reaches a sprint board.
If you're trying to build accessibility into your process at a bigger, systemic level, that's a different and more strategic conversation, one we cover in Building Accessibility Into Your Design System From Day One. This article is the narrower, tactical companion: what to fix in this file, right now, before you hit "ready for dev."
1. Check contrast with a plugin, not your eyes
Your eyes are not a reliable contrast meter, especially on a bright monitor at 100% brightness with no other tabs open for comparison. WCAG 1.4.3 sets a real, checkable number: 4.5:1 for normal text, 3:1 for large text. That's not a vibe, it's a ratio you can calculate.
Run a contrast-checking plugin over every text layer in the file, especially:
- Body copy on tinted or photographic backgrounds
- Placeholder text in form fields
- Secondary or "muted" labels, captions, and helper text
- Text inside buttons, especially disabled or secondary button states
Anything under 4.5:1 for normal-size text needs to move, either the text color gets darker (or lighter, depending on the background) or the background itself changes. This is worth doing before you finalize the palette in your design tokens, not after a developer flags it during QA. For the full technical definition and edge cases (like what counts as "large text"), the W3C's contrast minimum guidance is the primary source, and it's worth a skim even if you never plan to memorize the formula. If your product uses a dark theme or a toggleable dark mode, contrast checking gets trickier, not easier, which is exactly what we walk through in dark mode contrast accessibility.
2. Draw an explicit focus state for every interactive component
Here's a habit worth breaking: designing a button's default, hover, and pressed states, and quietly skipping the focus state because "it's basically the same as hover."
It isn't. Hover only happens with a mouse. Focus is what a keyboard user, a switch-device user, or anyone tabbing through your interface actually sees and relies on to know where they are. If a component has no visible focus indicator, keyboard users lose their place entirely.
For every interactive component in the file, create an explicit focus frame:
- Buttons, links, and icon buttons
- Form fields and custom form controls (toggles, checkboxes, dropdowns)
- Cards or rows that are clickable, not just decorative
- Anything inside a modal, since focus needs to be visible there too
Make the focus indicator visually distinct from hover, usually a clear outline or ring with enough contrast against the background to be genuinely visible, not a subtle 10% opacity change nobody will notice. Ship these frames in the same file as the default states, named consistently, so a developer isn't left guessing what "focused" is supposed to look like.
3. Set a deliberate reading order in the layer list
Screen readers generally traverse a page in DOM order, and DOM order tends to follow the structure and order of layers as they get built, which is heavily influenced by how layers are organized in the design file. If your layer list is a mess of stacked, misordered, or ungrouped elements, that disorganization can bleed straight into the experience of anyone navigating by screen reader.
Before handoff, walk through the layer panel and ask a simple question: if this were read top to bottom by someone who can't see the layout, would the order make sense? A card with an image, a headline, a description, and a button should have layers ordered to match that logical sequence, not the order they happened to get dropped onto the canvas.
Group and label sections clearly (header, main content, footer, sidebar) so the structure is legible to the next person, whether that's a fellow designer, a developer, or you in six months. This one step, cleaning up reading order in the file itself, saves an enormous amount of back-and-forth during development, because you've already made the structural decision instead of leaving it to whoever builds it first.
4. Check touch target spacing, not just target size
Most designers know the target size guidance, roughly 24x24px minimum, ideally 44x44px or larger for primary actions. Fewer designers check the spacing between targets, which matters just as much, especially for anyone with limited fine motor control or anyone using a touchscreen on a moving bus.
Two buttons can each individually meet the minimum size requirement and still sit close enough together that a mis-tap is likely. Before handoff:
- Measure the gap between adjacent tappable elements, not just their individual dimensions
- Pay close attention to icon-only buttons in toolbars, table row actions, and card grids, these are the most common offenders
- Check destructive actions (delete, remove, cancel) specifically, since a mis-tap there is the most costly kind
None of this requires new components. It usually just requires a little more breathing room in an auto-layout frame, which is a five-minute fix in Figma and a much harder one to retrofit once it's built.
Building the habit, not just the checklist
None of these four checks are hard. What makes them easy to skip is that a file can look completely finished without any of them, because contrast, focus states, reading order, and spacing are the kind of thing you only notice when they're missing, not when they're present.
Treat this checklist the way you'd treat a spell-check pass: a fast, final review before the file leaves your hands. Accessibility principles like these aren't an add-on discipline separate from good design, they're described directly in the W3C's accessibility principles as foundational to whether an interface actually works for the people using it.
If you want a broader, longer-term framework for baking these checks into your component library and design tokens instead of re-checking every file by hand, that's covered in Building Accessibility Into Your Design System From Day One. This piece is the file-by-file version, useful the moment you finish a design and before you hand it off.
Want a fast, free way to sanity-check contrast and other basics before your next handoff? Run your file through wcag.world/free-tools and catch what your eyes might miss.
If you'd rather talk it through with a person, reach our team directly at experts@wcag.world, or head to wcag.world/free-tools to get started right away.