当谈到设计系统时，每个组织在可访问性旅程中往往处于不同的位置。有些组织在使其设计系统可访问方面付出了大量努力，而其他组织在达到这一目标之前还有很长的路要走。为了在这一旅程中提供帮助，许多组织依赖可访问性标注来确保设计准备构建时不存在访问障碍。

然而，一个常见的误解（特别是对于拥有成熟设计系统的组织）是：可访问的组件将产生可访问的设计。虽然设计系统在扩展标准和一致性方面非常出色，但它们无法防止我们设计或构建方式中的每个问题。访问障碍仍然可能悄悄进入生产环境。

这是我们的可访问性设计团队着手解决问题的根源。

在这个由两部分组成的系列中，我们将向您展示可访问的设计系统组件如何产生不可访问的设计。然后我们将演示我们的解决方案：将标注与我们的Primer组件集成。这使我们能够减少标注时间，增加设计系统采用率，并接触到可能没有可访问性支持的团队。在我们的下一篇文章中，我们将指导您如何为自己的组件做同样的事情。

让我们深入探讨。

什么是标注及其好处？

标注是设计项目中包含的注释，通过传达未在视觉上显示的设计意图，帮助使不可见的内容变得明确。它们通过为开发人员提供体验应如何运作的整体图景来改善数字体验的可用性。将标注集成到我们的设计过程中有助于我们的团队更好地合作，通过弥合沟通差距并防止质量问题、可访问性审计问题和昂贵的返工。

标注帮助我们回答的一些问题包括：

• 辅助技术如何从页面上的一个元素导航到另一个元素？
• 信息性图像和没有标签的按钮的替代文本是什么？
• 内容如何根据视口大小、屏幕方向或缩放级别而变化？
• 在移动设备上，表单输入应使用哪种虚拟键盘？
• 对于复杂的交互，应如何管理焦点？

我们对这类问题的回答——或者缺乏回答——可能成就或破坏许多人在网络上的体验，特别是残疾用户。一些标注工具专门为此提供帮助，通过指导设计师包含有关Web标准、平台功能和可访问性（a11y）的关键细节。

大多数公共标注套件非常适合创建新设计系统组件的团队、尚未使用设计系统的团队或没有专业可访问性知识的团队。它们通常帮助标注以下内容：

• 控件，如按钮和链接
• 结构元素，如标题和地标
• 装饰性图像和信息性描述
• 表单和其他需要标签和语义角色的元素
• 辅助技术和键盘导航的焦点顺序

GitHub的标注工具包

我们的首要任务之一是在同事所在的位置与他们见面。我们希望所有设计师都能开箱即用地使用标注，因为我们相信他们不需要成为认证的可访问性专家才能以可访问的方式构建东西。

为此，去年我们开始创建一个内部的Figma库——GitHub标注工具包（我们旨在尽快向公众发布）。我们的工具包建立在CVS Health前包容性设计团队的遗产之上。他们的两个开源标注套件有助于创建易于创建和使用的文档，并且是Figma社区中使用最广泛的标注库之一。

虽然标注增加了清晰度，但它们也可能增加开销。如果团队仅依赖专家为开发人员解释设计和技术规范，交接过程可能比需要的更长。为了创建我们的标注工具包，我们从头开始重建了其前身，以避免这种开销，进行了广泛的改进并添加了内联文档，使其对我们所有的设计师更加直观和有用——而不仅仅是可访问性专家。

设计系统也有助于减少这种开销。当您为可访问性审计设计系统时，每个产品功能对专家关注的需求减少，因为您使用标注将技术语义和专家知识添加到每个组件中。这意味着设计师和开发人员只需要一致地遵守使用指南，对吗？

标注和设计系统组件的问题

不幸的是，事情并不那么简单。

可访问性不是二元的

虽然设计系统有助于推动更大规模的可访问设计，但它们不断演变，工作从未完成。任何组件的可访问性都不是二元的。有些可能有几个严重的问题，造成访问障碍，例如无法用键盘操作或缺少替代文本。其他可能有一些琐碎的问题，例如通用控件标签。

大多数时候，声称您的设计系统"完全可访问"是一种误称。总有更多的工作要做——只是多少的问题。Web内容可访问性指南（WCAG）是一个很好的起点，但它们的"成功标准"并不针对您的网站或产品或受众的独特背景。

虽然WCAG应作为构建的基础，但重要的是要理解它无法捕捉残疾用户需求的每个细微差别，因为您的用户需求并非每个用户的需求。如果您从不超越WCAG与用户交谈，很容易相信您的设计系统是"完全可访问的"。如果Primer有可访问的组件，那是因为我们觉得日常辅助技术用户的直接参与和输入是我们工作中最重要的方面。与真实用户——有残疾和没有残疾的——测试计划是您真正发现最重要的事情的地方。

可访问的组件不能保证可访问的设计

在页面上排列一系列可访问的组件不会自动创建准确且信息丰富的标题层次结构。很有可能，没有额外的文档，标题结构在视觉上毫无意义——也不适合作为辅助技术导航的媒介。

当可访问的组件灵活且响应迅速时，这很好，但当它们放置在组件指南未考虑的布局中时呢？它们是否适应不同的缩放级别、视口大小和屏幕方向？当这些因素中的任何一个发生变化时，它们是否会失去任何功能或上下文？

组件使用是情境相关的。您可以在设计中添加图像或图标，但设计系统文档无法为您编写描述性文本。您可以在多个地方使用相同的图像，但图像描述可能需要根据上下文而变化。

类似地，使用相同输入组件构建的表单可能执行不同的操作并需要不同的错误验证消息。难怪采用设计系统组件并不能消除所有审计问题。

Figma中的设计系统组件不包含所有细节

标注套件不包含特定设计系统的组件，因为几乎每个组织都在使用自己的系统。当采用标注套件时，团队通常会添加标注其设计系统组件的方法。

这种标注让开发人员知道他们可以使用已经构建的东西，而不需要从头开始构建。它还有助于识别在Figma中"分离"的任何设计系统组件。并且它减少了需要标注的项目数量。

让我们看一个例子：

如果我们使用Primer Web Figma库中的这个Primer按钮组件，仅通过查看设计或组件属性，有几件重要的事情我们不会知道：

• 组件实现时的功能差异。这是一个只是视觉上看起来像按钮的链接吗？如果是，开发人员将使用<LinkButton> React组件而不是<Button>。
• 使用辅助技术的人的可访问标签。图标可能需要替代文本。在某些情况下，按钮文本可能需要一些视觉隐藏的文本来区分它与类似按钮。我们如何知道该文本是什么？没有标注，Figma组件没有地方显示这一点。
• 用户数据是否提交。当设计不包括具有输入字段的明显表单时，我们如何传达按钮需要特定属性来提交数据？

让这样的问题悬而未决，希望有人注意到并猜出正确答案，这是有风险的。

简化标注过程同时最小化风险的解决方案

在创建新组件时，一组详细的标注可能是它们健壮性和可访问性的重要因素。一旦组件构建完成，设计团队可以开始在其设计中添加该组件的实例。当这些设计准备标注时，这些新组件不应该需要再次标注。在大多数情况下，这将是冗余和不必要的——但并非在所有情况下。

许多Primer组件中有一些重要的细节可能从一个实例到另一个实例发生变化。如果我们开箱即用地使用CVS Health标注套件，我们应该能够捕捉这些变化，但我们将无法避免那些冗余和不必要的标注。在构建自己的标注工具包时，我们为每个Primer组件构建了一组标注，以同时完成这两件事。

这个手风琴组件已经进行了彻底标注，以便工程师在第一次构建时拥有所需的一切。这些包括标题级别、<detail>和<summary>元素的语义、地标和装饰性图标。所有这些都内置在组件中，因此当将手风琴添加到新设计时，我们不需要标注大部分内容。

但是，有两件重要的事情我们需要标注，因为它们可能从一个实例到另一个实例变化：

• 顶部的可选标题。
• 手风琴内每个项目的标题级别。

如果我们不指定这些内容，我们就是在碰运气，页面的标题结构可能会断裂，或者体验会让人们理解和导航页面时感到困惑。对于单个按钮或基本手风琴，风险可能很低，但随着模式复杂性、组件嵌套、交互状态、重复实例等的增加，风险也会增长。

与其标注已经内置到组件中的内容或将