样本来自SaaS、零售、金融科技、公共部门和教育科技五个行业的28个产品团队的50个Figma文件。我们以非署名方式协商获得只读访问权限：本文中不识别任何品牌、团队或设计师。这些文件的选取旨在反映工程师在交接时实际收到的内容——而非来自作品集网站的精心打磨的案例研究——因此我们要求每个团队分享最近一个功能从中交付的文件，而非他们最引以为傲的文件。五十个文件中有十二个来自拥有专属设计系统实践的团队；其余三十八个来自产品级文件，这些文件引入了系统库或直接在文件内实现了自己的组件。

我们审阅每个文件时寻找五个无障碍属性：每个交互组件上的焦点状态设计、每张图像或非装饰性图标上的替代文本注释、跨布局的阅读顺序文档、任何带有动画或过渡效果元素的动效偏好处理，以及同时发布到亮色和暗色主题的任何组件的暗色模式对比度规格。对于每个属性，文件只有在工程师无需自行发明答案即可根据设计实现的情况下才得分”已记录”。“写在便利贴上的提及”不算。“在单一悬停状态中指定的十六进制颜色”不算。标准是：该决策是否以工程师可以直接执行的形式存在于文件中，无需询问？

核心发现是，按此标准，交接文件遗漏无障碍决策的频率远高于包含它们的频率。焦点状态设计出现在整个语料库约40%的交互组件中。替代文本注释出现在约22%需要它们的图像中。阅读顺序在16%的文件中得到明确记录。动效偏好在10%的文件中得到处理。对于同时发布两种主题的31个文件，暗色模式对比度在30%的组件中得到指定。差距不在某一个属性中，而在全部五个属性中，工程师被留下来逐一判断。

在整个语料库中涉及的约1,800个交互组件中——按钮、链接、输入框、复选框、开关、标签页、组合框、菜单项、作为按钮的卡片，任何键盘用户可以到达的元素——约40%交付了设计好的焦点状态。另外60%交付了默认状态、激活状态和悬停状态，然后停止了。实现组件的工程师在实现时自行选择一个焦点轮廓，通常是复制浏览器默认值，通常不检查该默认值在文件发布的亮色和暗色主题中是否都与组件表面保持3:1对比度。

“没有焦点状态设计”在实践中是什么样子？它看起来像画布上有三个变体的按钮组件——静止、悬停、按下——却没有第四个变体。它看起来像带有样式化边框的输入字段，却没有焦点状态的第二种边框样式。它看起来像只有在静止变体上有焦点环的复选框原语，工程师被留下来猜测同样的环是否应该出现在勾选或不确定变体上。这种模式在组件中、跨团队、跨行业重复出现。它是语料库中最大的单一无障碍差距，也是最容易设计进去的。

那些确实把焦点状态设计好的团队，有两者之一作为支撑。第一个是明确的设计系统规则：每个交互组件必须交付一个名称以focus-开头的变体，在该变体存在之前组件不会发布到库中。第二个是Figma组件属性，名为state，将focus、focus-visible和focus-within作为枚举值，使文件的组件浏览器在视觉上呈现缺失的变体。没有这两种脚手架之一的团队，在约十次中有九次将焦点状态留给了工程师。

在语料库中包含内容图像的文件——产品摄影、英雄插图、仅含图标的按钮、信息图表——78%在图像图层上没有替代文本注释。图像被放置、调整大小并设置样式；工程师应该放在渲染后的<img>上的文本等价物不在文件中。五十个文件中有八个在部分图像上有替代文本但不是全部，通常是英雄插图有注释而正文内容图像为空白。三个文件对每张图像都有替代文本。工程师在50个文件中的47个中，被期望自行编写替代文本——在实践中往往从文件名、图注或适合视觉节奏的任何字符串中继承。

这一差距在结构上源于Figma图像原语。图像填充或图像图层上没有原生”alt”属性；替代文本必须以图层名称、评论、便利贴、单独的规格文档或插件添加字段的形式承载。这些都不会通过检查面板默认传递，所以在检查视图中阅读文件的工程师即使设计师在别处写了替代文本也看不到。始终弥合这一差距的团队使用了三种变通方法之一：每个图像变体上有插件管理的替代文本字段、将图层名称作为替代文本的有据可查的约定，或随文件一起交付的以图像文件名为索引的替代文本电子表格。

仅含图标的按钮是这个故障模式中的子故障。在50个文件中的41个里，图标按钮——搜索放大镜、汉堡菜单、关闭X、分享箭头——没有无障碍名称注释，工程师只能从视觉上下文写出aria-label=“Search”，而没有确认”Search”是否是品牌声音中的正确词（是”Find”？是”Lookup”？还是因为按钮在其他地方标注的面板而什么都不是？）。图标命名恰恰是那种受益于设计师之笔的微文案决策，也恰恰是交接会丢失的那种。

其余三个属性呈现出不同形态的失败。阅读顺序——屏幕阅读器叙述页面的顺序，在现代响应式布局中不再保证与视觉从上到下的顺序一致——在16%的文件中得到记录。记录存在时，通常是用插件在画布上添加的编号叠加层（1、2、3……）。其余84%让工程师从他们碰巧编写的DOM顺序映射阅读顺序，而在具有显式行列定位的CSS Grid布局上，这可能与视觉布局相差整整一列。

动效偏好最差。十分之一的文件提及了prefers-reduced-motion。其余90%指定了动画和过渡——模态框入场、手风琴展开、通知栏滑入、页面过渡——却没有指定当用户启用了减少动画时同一组件应该如何表现。工程师要么在实现时构建减少动画的情况（通常没有视觉参考），要么向所有人交付同样的动画，这是默认行为，而且对设置了该偏好的用户违反了2.3.3（交互动画）。

暗色模式对比度在同时发布两种主题的文件中，30%的组件有规格。另外70%指定了亮色主题对比度——通常在文件中有Stark或对比度检查器注释——然后用十六进制翻转调色板发布暗色主题，让工程师检查翻转后的颜色对是否在正文文字上仍然达到4.5:1、在UI组件上达到3:1。在31个双主题文件中，约五分之一至少有一个组件在暗色主题中低于对比度阈值，因为暗色表面和暗色文字都为亮色主题的对比度数学而调整，而非为暗色主题的。

在语料库中出现最频繁的两个插件是Stark和Able。两者都已成熟，都受到好评，都提供能够弥合上文记录的几个差距的功能。Stark添加了对比度检查器、焦点顺序叠加层、减少动画预览，以及图像图层上的替代文本注释字段。Able添加了颜色对比度检查器、视力模拟叠加层和触控目标检查器。任何一个插件，如果在文件中始终使用，都会将该文件从语料库的末尾四分之一中提升出来。

“始终使用”是关键词。在50个文件中，Stark在18个中被安装并可见地使用，Able在11个中。在使用了插件的文件中，它通常用于英雄组件和主要CTA——设计师打开插件时画布上最可能在视野内的组件——在其他地方则很少使用。六个文件对整个文件进行了Stark全局扫描；一个对整个文件进行了Able全局扫描。模式是：插件存在，设计师了解它们，它们被引入进行抽查，然后抽查在设计师打开插件时碰巧正在查看的组件处停止。

在插件使用方面结束审计的两个团队做了一件不同的事：他们在将文件分享给工程之前，将插件的审计功能作为发布关口步骤在文件的每一页上运行。审计在文件中运行，产生一份报告，在文件从”设计中”移至”工程就绪”之前，该报告必须为空（或其例外情况已记录）。这是”插件作为工作流程”而非”插件作为抽查”，这就是我们样本中80%覆盖率与20%覆盖率之间的差距。

审计产生了一份核查清单和一份契约。核查清单是设计师在将文件分享给工程之前应该能够逐项勾选的内容。契约是随文件一起传递的设计令牌的形态，使工程师将Figma变量映射到CSS自定义属性时无需发明中间值。两者都刻意保持简短：核查清单上的每一项都是审计测量的属性，契约中的每个令牌都是在语料库中弥合差距的值。

50个文件的审计以一个简单的发现收尾。交接之所以使无障碍性失败，不是因为设计师不关心，也不是因为工程师不关心，而是因为文件——Figma文件，每个参与方都阅读的单一产物——没有将无障碍决策作为一等属性承载。焦点状态、替代文本、阅读顺序、动效偏好、暗色模式对比度：每一项都是设计决策，每一项都属于文件，每一项目前都在其他地方。在便利贴里，在Slack消息里，在单独的电子表格里，在工程师周五下午四点的脑子里。

修复方法不是一位英雄设计师或一位英雄工程师。而是团队层面的工作流程变革：每个交互组件交付焦点变体，每张图像在一个插件管理的位置承载替代文本，阅读顺序叠加在任何非平凡页面上，动画指定其减少动画的对应版本，暗色模式对比度独立于亮色主题单独检查，文件随令牌契约一起交付，命名实现所绑定的每个变量。这些步骤没有一个是新的，没有一个需要我们还没有的工具，任何将它们作为发布关口步骤采纳的团队将在一个发布周期内弥合我们测量的大部分差距。

更深层的发现是，设计系统团队已经以约两倍于产品团队的比率做到了这一点。设计系统团队提供的提升，恰恰是构建系统这门学科所施加的提升：组件被命名，属性被枚举，变体是可见的，令牌是明确的。将同样的学科带到产品级文件中——即便没有完整设计系统作为底层——可以弥合大部分交接差距。这不再是工具问题，而是工作流程选择。