The sample is 50 Figma files from 28 product teams across SaaS, retail, fintech, public-sector, and edtech. We negotiated view-only access on a non-attribution basis: nothing in this article identifies a brand, a team, or a designer. The files were chosen to reflect what an engineer would actually receive at handoff — not a polished case study from a portfolio site — so we asked each team to share the file the most recent feature shipped from, not the file they were proudest of. Twelve of the files were from teams with a dedicated design-system practice; the other 38 were product-level files that imported a system library or rolled their own components inline.

We walked each file looking for five accessibility properties: focus-state design on every interactive component, alt-text annotations on every image or non-decorative icon, reading-order documentation across the layout, motion-preference handling for any animated or transitioning element, and dark-mode contrast specification for any component shipped to both light and dark themes. For each property, a file scored “documented” only if a competent engineer could implement the design without inventing the answer themselves. “Mentioned in a sticky note” did not count. “Hex specified in a single hover state” did not count. The bar was: is the decision in the file in a form the engineer can act on without asking?

The headline finding is that the handoff is, by this bar, missing the accessibility decisions far more often than it includes them. Focus-state design appeared on approx. 40% of interactive components across the corpus. Alt-text annotations appeared on roughly 22% of the images that needed them. Reading order was explicitly documented in 16% of files. Motion preferences were addressed in 10%. Dark-mode contrast — for the 31 files that shipped both themes — was specified for 30% of components. The gap is not in any one property. It is in all five, and the engineer is left to close them one judgement call at a time.

Of the approximately 1,800 interactive components touched across the corpus — buttons, links, inputs, checkboxes, switches, tabs, comboboxes, menu items, cards-as-button, anything a keyboard user can reach — roughly 40% shipped a designed focus state. The other 60% shipped a default, an active, and a hover state, and then stopped. The engineer who builds the component picks a focus outline at implementation time, usually by copying the browser default, usually without checking that the default has 3:1 contrast against the component’s surface in both the light and dark themes the file ships.

What does “no focus-state design” look like in practice? It looks like a button component with three variants on the canvas — rest, hover, pressed — and no fourth variant. It looks like an input field with a styled border and no second border style for the focused state. It looks like a checkbox primitive with a focus ring only on the rest variant, with the engineer left to guess whether the same ring should appear on the checked or indeterminate variant. The pattern repeats across components, across teams, across sectors. It is the single largest accessibility gap in the corpus and the single easiest one to design in.

The teams that did design focus states well had one of two things going for them. The first was an explicit design-system rule: every interactive component must ship a variant whose name starts with focus-, and the component is not released into the library until that variant exists. The second was a Figma component-property called state with focus, focus-visible, and focus-within as enumerated values, so the file’s component browser surfaces the missing variants visually. Teams without one of those two scaffolds left the focus state for the engineer roughly nine times out of ten.

Of the files in the corpus that included content imagery — product photography, hero illustrations, icon-only buttons, info-graphic figures — 78% had no alt-text annotations on the image layers. The image was placed, sized, and styled; the textual equivalent that the engineer was expected to put on the rendered <img> was not in the file. Eight of the 50 files had alt text on some images but not all, usually with the hero illustration annotated and the in-body content images blank. Three files had alt text on every image. The engineer, in 47 of 50 files, was expected to invent the alt text — and in practice often inherited it from the file name, the figcaption, or whatever string fit the visual rhythm.

The gap is structural to Figma’s image primitive. There is no native “alt” property on an image fill or an image layer; alt text has to be carried as a layer name, a comment, a sticky note, a separate spec document, or a plugin-added field. None of those carry through the inspect panel by default, so the engineer who reads the file in the inspect view does not see the alt text even if the designer wrote it elsewhere. Teams that closed the gap consistently used one of three workarounds: plugin-managed alt-text fields on every image variant, a documented convention that the layer name is the alt text, or a separate alt-text spreadsheet keyed to image filenames that shipped alongside the file.

Icon-only buttons were a sub-failure inside this failure mode. In 41 of 50 files, icon buttons — the search-glass, the menu hamburger, the close-X, the share-arrow — had no accessible-name annotation, leaving the engineer to write aria-label=“Search” from the visual context without confirmation that “Search” was the right word in the brand’s voice (was it “Find”? was it “Lookup”? was it nothing because the button opens a panel labelled elsewhere?). Icon naming is exactly the kind of micro-copy decision that benefits from a designer’s pen, and exactly the kind that the handoff loses.

The remaining three properties had distinct shapes of failure. Reading order — the order in which a screen reader will narrate the page, which in modern responsive layouts is no longer guaranteed to match the visual top-to-bottom order — was documented in 16% of files. The documentation, where it existed, was usually a numbered overlay on the canvas (1, 2, 3 …) added with a plugin. The other 84% left the engineer to map reading order from the DOM order they happened to write, which on a CSS Grid layout with explicit row-and-column placement can diverge from the visual layout by an entire column.

Motion preferences fared worst. Ten percent of files mentioned prefers-reduced-motion at all. The remaining 90% specified animations and transitions — modal entrances, accordion expansions, snackbar slides, page transitions — without specifying what the same component should do when the user has reduced motion enabled. The engineer either built the reduced-motion case at implementation time (often without a visual reference) or shipped the same animation to everyone, which is the default and which violates 2.3.3 Animation from Interactions for users who set the preference.

Dark-mode contrast was specified for 30% of components in files that shipped both themes. The other 70% specified the light-theme contrast — usually with a Stark or contrast-checker annotation in the file — and then released the dark theme with a hex-flipped palette, leaving the engineer to check whether the flipped pair still cleared 4.5:1 on body text and 3:1 on UI components. In about a fifth of the 31 dual-theme files, at least one component dropped below contrast threshold in the dark theme because the dark surface and the dark text were both tuned for the light theme’s contrast math, not the dark theme’s.

The two plugins that show up most often in the corpus are Stark and Able. Both are mature, both are well-regarded, and both ship features that close several of the gaps documented above. Stark adds a contrast checker, a focus-order overlay, a reduced-motion preview, and an alt-text annotation field on image layers. Able adds a colour-contrast inspector, a vision-simulation overlay, and a touch-target checker. Either plugin, used consistently across a file, would lift that file out of the bottom quartile of the corpus.

Used consistently is the operative phrase. Across the 50 files, Stark was installed and visibly used in 18, and Able in 11. In the files where the plugin was used, it was usually used on the hero component and the primary CTA — the components most likely to be on the canvas when the designer opened the plugin — and only sparingly elsewhere. Six files used Stark on a global pass; one used Able on a global pass. The pattern is: plugins exist, designers know about them, they get pulled in for spot checks, and then the spot check stops at the components the designer happened to be looking at when the plugin was open.

The two teams who closed the audit on plugin usage did one thing differently: they ran the plugin’s audit feature on every page of the file as a release-gate step before the file was shared with engineering. The audit ran in the file, produced a report, and the report had to be empty (or its exceptions documented) before the file moved from “in design” to “ready for engineering.” This is plugin-as-workflow rather than plugin-as-spot-check, and it is the difference between 80% coverage and 20% coverage in our sample.

The audit produces a checklist and a contract. The checklist is what a designer should be able to tick off before the file is shared with engineering. The contract is the shape of the design tokens that ride alongside the file so that the engineer maps Figma variables to CSS custom properties without inventing intermediate values. Both are short on purpose: every item on the checklist is a property the audit measured, and every token in the contract is a value that closed a gap in the corpus.

The 50-file audit closes on a simple finding. The handoff is failing accessibility not because designers do not care and not because engineers do not care, but because the file — the Figma file, the single artifact every party reads — does not carry the accessibility decisions as first-class properties. Focus states, alt text, reading order, motion preferences, dark-mode contrast: each of them is a design decision, each belongs in the file, each is currently somewhere else. In a sticky note, in a Slack message, in a separate spreadsheet, in the engineer’s head at 4pm on a Friday.

The fix is not a heroic designer or a heroic engineer. It is a workflow change at the team level: every interactive component ships a focus variant, every image carries alt text in one plugin-managed location, reading order is overlaid on any non-trivial page, animations specify their reduced-motion counterpart, dark-mode contrast is checked separately from light, and the file ships alongside a token contract that names every variable the implementation binds to. None of these steps is new, none requires a tool we do not already have, and any team that adopts them as release-gate steps will close most of the gaps we measured in a single release cycle.

The deeper finding is that design-system teams already do this at roughly twice the rate of product teams. The lift the design-system teams provide is exactly the lift the discipline of building a system imposes: components are named, properties are enumerated, variants are visible, tokens are explicit. Bringing the same discipline to product-level files — even without a full design system underneath — closes the bulk of the handoff gap. It is not a tooling problem any more. It is a workflow choice.